| <!DOCTYPE html> |
| <html xmlns="http://www.w3.org/1999/xhtml" lang="" xml:lang=""> |
| <head> |
| <title>Android 4.1 Compatibility Definition</title> |
| <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/> |
| <meta name="generator" content="pdftohtml 0.36"/> |
| <meta name="date" content="2013-06-27T14:12:42+00:00"/> |
| <style type="text/css"> |
| <!-- |
| .xflip { |
| -moz-transform: scaleX(-1); |
| -webkit-transform: scaleX(-1); |
| -o-transform: scaleX(-1); |
| transform: scaleX(-1); |
| filter: fliph; |
| } |
| .yflip { |
| -moz-transform: scaleY(-1); |
| -webkit-transform: scaleY(-1); |
| -o-transform: scaleY(-1); |
| transform: scaleY(-1); |
| filter: flipv; |
| } |
| .xyflip { |
| -moz-transform: scaleX(-1) scaleY(-1); |
| -webkit-transform: scaleX(-1) scaleY(-1); |
| -o-transform: scaleX(-1) scaleY(-1); |
| transform: scaleX(-1) scaleY(-1); |
| filter: fliph + flipv; |
| } |
| --> |
| </style> |
| </head> |
| <a name=1></a><b>Android 4.1 Compatibility Definition<br/>Revision 3<br/></b>Last updated: June 24, 2013<br/> |
| Copyright © 2012, Google Inc. Al  rights reserved.<br/>compatibility@android.com<br/> |
| <b>Table of Contents</b><br/> |
| 1. Introduction<br/><a href="file:///usr/local/google/home/gurunagarajan/android_dev/master/vendor/android/compatibility/cdd/jb/cdd-jb.xhtml#section-1">2. Resources<br/></a><a href="file:///usr/local/google/home/gurunagarajan/android_dev/master/vendor/android/compatibility/cdd/jb/cdd-jb.xhtml#section-2">3. Software</a><br/> |
| <a href="file:///usr/local/google/home/gurunagarajan/android_dev/master/vendor/android/compatibility/cdd/jb/cdd-jb.xhtml#section-3">3.1. Man</a>aged API Compatibility<br/>3<a href="file:///usr/local/google/home/gurunagarajan/android_dev/master/vendor/android/compatibility/cdd/jb/cdd-jb.xhtml#section-3.1">.2. Soft API Compatibility</a><br/> |
| <a href="file:///usr/local/google/home/gurunagarajan/android_dev/master/vendor/android/compatibility/cdd/jb/cdd-jb.xhtml#section-3.2">3.2.1. Permissions<br/></a>3<a href="file:///usr/local/google/home/gurunagarajan/android_dev/master/vendor/android/compatibility/cdd/jb/cdd-jb.xhtml#section-3.2.1">.2.2. Build Paramete</a>rs<br/>3<a href="file:///usr/local/google/home/gurunagarajan/android_dev/master/vendor/android/compatibility/cdd/jb/cdd-jb.xhtml#section-3.2.2">.2.3. Intent Compatibility</a><br/> |
| <a href="file:///usr/local/google/home/gurunagarajan/android_dev/master/vendor/android/compatibility/cdd/jb/cdd-jb.xhtml#section-3.2.3">3.2.3.1. Core Applicatio</a>n Intents<br/>3<a href="file:///usr/local/google/home/gurunagarajan/android_dev/master/vendor/android/compatibility/cdd/jb/cdd-jb.xhtml#section-3.2.3.1">.2.3.2. Intent Overrides<br/></a>3<a href="file:///usr/local/google/home/gurunagarajan/android_dev/master/vendor/android/compatibility/cdd/jb/cdd-jb.xhtml#section-3.2.3.2">.2.3.3. Intent Namespaces<br/></a>3<a href="file:///usr/local/google/home/gurunagarajan/android_dev/master/vendor/android/compatibility/cdd/jb/cdd-jb.xhtml#section-3.2.3.3">.2.3.4. Broadcast Intents</a><br/> |
| 3.3. Native<a href="file:///usr/local/google/home/gurunagarajan/android_dev/master/vendor/android/compatibility/cdd/jb/cdd-jb.xhtml#section-3.2.3.4"> API Compatibility</a><br/> |
| <a href="file:///usr/local/google/home/gurunagarajan/android_dev/master/vendor/android/compatibility/cdd/jb/cdd-jb.xhtml#section-3.3">3.3.1 Application Binary Inte</a>rfaces<br/> |
| 3.4. <a href="file:///usr/local/google/home/gurunagarajan/android_dev/master/vendor/android/compatibility/cdd/jb/cdd-jb.xhtml#section-3.3.1">Web Compatibility</a><br/> |
| 3.4.1. WebView Compatibility<br/>3.4.2. Browser Compatibility<br/> |
| 3.5. API Behavioral Compatibility<br/>3.6. API Namespaces<br/>3.7. Virtual Machine Compatibility<br/>3<a href="file:///usr/local/google/home/gurunagarajan/android_dev/master/vendor/android/compatibility/cdd/jb/cdd-jb.xhtml#section-3.6">.8. User Interface Comp</a>atibility<br/> |
| <a href="file:///usr/local/google/home/gurunagarajan/android_dev/master/vendor/android/compatibility/cdd/jb/cdd-jb.xhtml#section-3.7">3.8.1. Widgets<br/></a><a href="file:///usr/local/google/home/gurunagarajan/android_dev/master/vendor/android/compatibility/cdd/jb/cdd-jb.xhtml#section-3.8">3.8.2. Notifications<br/></a>3<a href="file:///usr/local/google/home/gurunagarajan/android_dev/master/vendor/android/compatibility/cdd/jb/cdd-jb.xhtml#section-3.8.1">.8.3. Search<br/></a>3<a href="file:///usr/local/google/home/gurunagarajan/android_dev/master/vendor/android/compatibility/cdd/jb/cdd-jb.xhtml#section-3.8.2">.8.4. Toasts<br/></a>3<a href="file:///usr/local/google/home/gurunagarajan/android_dev/master/vendor/android/compatibility/cdd/jb/cdd-jb.xhtml#section-3.8.3">.8.5. Themes<br/></a>3<a href="file:///usr/local/google/home/gurunagarajan/android_dev/master/vendor/android/compatibility/cdd/jb/cdd-jb.xhtml#section-3.8.4">.8.6. Live Wal </a>papers<br/>3<a href="file:///usr/local/google/home/gurunagarajan/android_dev/master/vendor/android/compatibility/cdd/jb/cdd-jb.xhtml#section-3.8.5">.8.7. Recent Ap</a>plication Display<br/>3<a href="file:///usr/local/google/home/gurunagarajan/android_dev/master/vendor/android/compatibility/cdd/jb/cdd-jb.xhtml#section-3.8.6">.8.8. Input Management </a>Settings<br/>3<a href="file:///usr/local/google/home/gurunagarajan/android_dev/master/vendor/android/compatibility/cdd/jb/cdd-jb.xhtml#section-3.8.7">.8.9. Lock Screen Remote Control</a><br/> |
| 3.9 D<a href="file:///usr/local/google/home/gurunagarajan/android_dev/master/vendor/android/compatibility/cdd/jb/cdd-jb.xhtml#section-3.8.8">evice Administration<br/></a>3.10 <a href="file:///usr/local/google/home/gurunagarajan/android_dev/master/vendor/android/compatibility/cdd/jb/cdd-jb.xhtml#section-3.8.9">Accessibility<br/></a>3<a href="file:///usr/local/google/home/gurunagarajan/android_dev/master/vendor/android/compatibility/cdd/jb/cdd-jb.xhtml#section-3.9">.11 Text-to-Speech</a><br/> |
| 4. Ap<a href="file:///usr/local/google/home/gurunagarajan/android_dev/master/vendor/android/compatibility/cdd/jb/cdd-jb.xhtml#section-3.10">plication Packaging</a> Compatibility<br/>5. Multimedia Compatibility<br/> |
| 5.1. Media Codecs<br/>5.2. Video Encoding<br/>5.3. Audio Recording<br/>5.4. Audio Latency<br/>5<a href="file:///usr/local/google/home/gurunagarajan/android_dev/master/vendor/android/compatibility/cdd/jb/cdd-jb.xhtml#section-5.2">.5. Network Protocols</a><br/> |
| 6. De<a href="file:///usr/local/google/home/gurunagarajan/android_dev/master/vendor/android/compatibility/cdd/jb/cdd-jb.xhtml#section-5.3">veloper Tool Compatibi</a>lity<br/>7. Ha<a href="file:///usr/local/google/home/gurunagarajan/android_dev/master/vendor/android/compatibility/cdd/jb/cdd-jb.xhtml#section-5.4">rdware Compatibility</a><br/> |
| 7<a href="file:///usr/local/google/home/gurunagarajan/android_dev/master/vendor/android/compatibility/cdd/jb/cdd-jb.xhtml#section-5.5">.1. Display and Graphics</a><br/> |
| <a href="file:///usr/local/google/home/gurunagarajan/android_dev/master/vendor/android/compatibility/cdd/jb/cdd-jb.xhtml#section-6">7.1.1. Screen Configurati</a>on<br/><a href="file:///usr/local/google/home/gurunagarajan/android_dev/master/vendor/android/compatibility/cdd/jb/cdd-jb.xhtml#section-7">7.1.2. Display Metri</a>cs<br/><a href="file:///usr/local/google/home/gurunagarajan/android_dev/master/vendor/android/compatibility/cdd/jb/cdd-jb.xhtml#section-7.1">7.1.3. Screen Orientatio</a>n<br/>7<a href="file:///usr/local/google/home/gurunagarajan/android_dev/master/vendor/android/compatibility/cdd/jb/cdd-jb.xhtml#section-7.1.1">.1.4. 2D and 3D Graphics Acc</a>leration<br/>7<a href="file:///usr/local/google/home/gurunagarajan/android_dev/master/vendor/android/compatibility/cdd/jb/cdd-jb.xhtml#section-7.1.2">.1.5. Legacy Application</a> Compatibility Mode<br/>7<a href="file:///usr/local/google/home/gurunagarajan/android_dev/master/vendor/android/compatibility/cdd/jb/cdd-jb.xhtml#section-7.1.3">.1.6. Screen Types<br/></a>7<a href="file:///usr/local/google/home/gurunagarajan/android_dev/master/vendor/android/compatibility/cdd/jb/cdd-jb.xhtml#section-7.1.4">.1.7. Screen Technology</a><br/> |
| 7.2. In<a href="file:///usr/local/google/home/gurunagarajan/android_dev/master/vendor/android/compatibility/cdd/jb/cdd-jb.xhtml#section-7.1.5">put Devices</a><br/> |
| 7<a href="file:///usr/local/google/home/gurunagarajan/android_dev/master/vendor/android/compatibility/cdd/jb/cdd-jb.xhtml#section-7.1.6">.2.1. Keyboard<br/></a>7<a href="file:///usr/local/google/home/gurunagarajan/android_dev/master/vendor/android/compatibility/cdd/jb/cdd-jb.xhtml#section-7.1.7">.2.2. Non-touch Navigation<br/></a>7.2.3. Navigation keys<br/>7.2.4. Touchscreen input<br/>7.2.5. Fake touch input<br/>7.2.6. Microphone<br/> |
| 7.3. Sensors<br/> |
| 7<a href="file:///usr/local/google/home/gurunagarajan/android_dev/master/vendor/android/compatibility/cdd/jb/cdd-jb.xhtml#section-7.2.4">.3.1. Accelerometer</a><br/> |
| <hr/> |
| <a name=2></a>7.3.1. Accelerometer<br/>7<a href="file:///usr/local/google/home/gurunagarajan/android_dev/master/vendor/android/compatibility/cdd/jb/cdd-jb.xhtml#section-7.3.2">.3.2. Magnetometer<br/></a>7<a href="file:///usr/local/google/home/gurunagarajan/android_dev/master/vendor/android/compatibility/cdd/jb/cdd-jb.xhtml#section-7.3.3">.3.3. GPS<br/></a>7<a href="file:///usr/local/google/home/gurunagarajan/android_dev/master/vendor/android/compatibility/cdd/jb/cdd-jb.xhtml#section-7.3.4">.3.4. Gyroscope<br/></a>7<a href="file:///usr/local/google/home/gurunagarajan/android_dev/master/vendor/android/compatibility/cdd/jb/cdd-jb.xhtml#section-7.3.5">.3.5. Barometer<br/></a>7<a href="file:///usr/local/google/home/gurunagarajan/android_dev/master/vendor/android/compatibility/cdd/jb/cdd-jb.xhtml#section-7.3.6">.3.6. Thermometer<br/></a>7<a href="file:///usr/local/google/home/gurunagarajan/android_dev/master/vendor/android/compatibility/cdd/jb/cdd-jb.xhtml#section-7.3.7">.3.7. Photometer<br/></a>7<a href="file:///usr/local/google/home/gurunagarajan/android_dev/master/vendor/android/compatibility/cdd/jb/cdd-jb.xhtml#section-7.3.8">.3.8. Proximity Sensor</a><br/> |
| 7<a href="file:///usr/local/google/home/gurunagarajan/android_dev/master/vendor/android/compatibility/cdd/jb/cdd-jb.xhtml#section-7.4">.4. Data Connectivity</a><br/> |
| 7.4.1. Telephony<br/>7.4.2. IEEE 802.11 (WiFi)<br/> |
| 7.4.2.1. WiFi Direct<br/> |
| 7.4.3. Bluetooth<br/>7.4.4. Near-Field Communications<br/>7<a href="file:///usr/local/google/home/gurunagarajan/android_dev/master/vendor/android/compatibility/cdd/jb/cdd-jb.xhtml#section-7.4.4">.4.5. Minimum Network Capability</a><br/> |
| 7.5. C<a href="file:///usr/local/google/home/gurunagarajan/android_dev/master/vendor/android/compatibility/cdd/jb/cdd-jb.xhtml#section-7.4.5">ameras</a><br/> |
| <a href="file:///usr/local/google/home/gurunagarajan/android_dev/master/vendor/android/compatibility/cdd/jb/cdd-jb.xhtml#section-7.5">7.5.1. Rear</a>-Facing Camera<br/>7<a href="file:///usr/local/google/home/gurunagarajan/android_dev/master/vendor/android/compatibility/cdd/jb/cdd-jb.xhtml#section-7.5.1">.5.2. Front-Facing Camera<br/></a>7<a href="file:///usr/local/google/home/gurunagarajan/android_dev/master/vendor/android/compatibility/cdd/jb/cdd-jb.xhtml#section-7.5.2">.5.3. Camera API Behavior<br/></a>7<a href="file:///usr/local/google/home/gurunagarajan/android_dev/master/vendor/android/compatibility/cdd/jb/cdd-jb.xhtml#section-7.5.3">.5.4. Camera Orientation</a><br/> |
| 7.6. <a href="file:///usr/local/google/home/gurunagarajan/android_dev/master/vendor/android/compatibility/cdd/jb/cdd-jb.xhtml#section-7.5.4">Memory and Storage</a><br/> |
| <a href="file:///usr/local/google/home/gurunagarajan/android_dev/master/vendor/android/compatibility/cdd/jb/cdd-jb.xhtml#section-7.6">7.6.1. Minimum Memory</a> and Storage<br/>7<a href="file:///usr/local/google/home/gurunagarajan/android_dev/master/vendor/android/compatibility/cdd/jb/cdd-jb.xhtml#section-7.6.1">.6.2. Application Shared Storage</a><br/> |
| 7.7. U<a href="file:///usr/local/google/home/gurunagarajan/android_dev/master/vendor/android/compatibility/cdd/jb/cdd-jb.xhtml#section-7.6.2">SB</a><br/> |
| 8. Pe<a href="file:///usr/local/google/home/gurunagarajan/android_dev/master/vendor/android/compatibility/cdd/jb/cdd-jb.xhtml#section-7.7">rformance</a> Compatibility<br/><a href="file:///usr/local/google/home/gurunagarajan/android_dev/master/vendor/android/compatibility/cdd/jb/cdd-jb.xhtml#section-8">9. Security Model Compatibility</a><br/> |
| <a href="file:///usr/local/google/home/gurunagarajan/android_dev/master/vendor/android/compatibility/cdd/jb/cdd-jb.xhtml#section-9">9.1. Permissions<br/></a>9<a href="file:///usr/local/google/home/gurunagarajan/android_dev/master/vendor/android/compatibility/cdd/jb/cdd-jb.xhtml#section-9.1">.2. UID and Proce</a>ss Isolation<br/>9<a href="file:///usr/local/google/home/gurunagarajan/android_dev/master/vendor/android/compatibility/cdd/jb/cdd-jb.xhtml#section-9.2">.3. Filesystem Permissions<br/></a>9.4. Alternate Execution Environments<br/> |
| 10. Software Compatibility Testing<br/> |
| 10.1. Compatibility Test Suite<br/>10.2. CTS Verifier<br/>10.3. Reference Applications<br/> |
| 11. U<a href="file:///usr/local/google/home/gurunagarajan/android_dev/master/vendor/android/compatibility/cdd/jb/cdd-jb.xhtml#section-10.2">pdatable Software<br/></a>12. C<a href="file:///usr/local/google/home/gurunagarajan/android_dev/master/vendor/android/compatibility/cdd/jb/cdd-jb.xhtml#section-10.3">ontact Us<br/></a><a href="file:///usr/local/google/home/gurunagarajan/android_dev/master/vendor/android/compatibility/cdd/jb/cdd-jb.xhtml#section-11">Appendix A - Bluetooth Tes</a>t Procedure<br/> |
| <hr/> |
| <a name=3></a><b>1. Introduction</b><br/> |
| This document enumerates the requirements that must be met in order for devices to<br/>be compatible with Android 4.1.<br/> |
| The use of "must", "must not", "required", "shal ", "shal  not", "should", "should not",<br/>"recommended", "may" and "optional" is per the IETF standard defined in RFC2119<br/>[<a href="file:///usr/local/google/home/gurunagarajan/android_dev/master/vendor/android/compatibility/cdd/jb/cdd-jb.xhtml#resources01">Resources, 1].</a><br/> |
| As used in this document, a "device implementer" or "implementer" is a person or<br/>organization developing a hardware/software solution running Android 4.1. A "device<br/>implementation" or "implementation" is the hardware/software solution so developed.<br/> |
| To be considered compatible with Android 4.1, device implementations MUST meet<br/>the requirements presented in this Compatibility Definition, including any documents<br/>incorporated via reference.<br/> |
| Where this definition or the software tests described in Section 10 is silent,<br/>ambiguous, or incomplete, it is the responsibility of the dev<a href="file:///usr/local/google/home/gurunagarajan/android_dev/master/vendor/android/compatibility/cdd/jb/cdd-jb.xhtml#section-10">ice impleme</a>nter to ensure<br/>compatibility with existing implementations.<br/> |
| For this reason, the Android Open Source Project [Resources, 3] is both the reference<br/>and preferred implementation of Android. Device impl<a href="file:///usr/local/google/home/gurunagarajan/android_dev/master/vendor/android/compatibility/cdd/jb/cdd-jb.xhtml#resources03">ementers are s</a>trongly<br/>encouraged to base their implementations to the greatest extent possible on the<br/>"upstream" source code available from the Android Open Source Project. While some<br/>components can hypothetical y be replaced with alternate implementations this<br/>practice is strongly discouraged, as passing the software tests wil  become<br/>substantial y more difficult. It is the implementer's responsibility to ensure ful  behavioral<br/>compatibility with the standard Android implementation, including and beyond the<br/>Compatibility Test Suite. Final y, note that certain component substitutions and<br/>modifications are explicitly forbidden by this document.<br/> |
| <b>2. Resources</b><br/> |
| 1.  IETF RFC2119 Requirement Levels: http://www.ietf.org/rfc/rfc2119.txt<br/>2.  Android Compatibility Program Overview:<br/> |
| http://source.android.com/compatibility/i<a href="http://www.ietf.org/rfc/rfc2119.txt">ndex.html</a><br/> |
| 3.  Android Open Source Project: http://source.android.com/<br/>4.  <a href="http://source.android.com/compatibility/index.html">API definitions and documentation:</a><br/> |
| http://developer.android.com/refe<a href="http://source.android.com/">rence/packages.html</a><br/> |
| 5.  Android Permissions reference:<br/> |
| <a href="http://developer.android.com/reference/packages.html">http://developer.android.com/reference/android/Manifest.p</a>ermission.html<br/> |
| 6.  android.os.Build reference:<br/> |
| <a href="http://developer.android.com/reference/android/Manifest.permission.html">http://developer.android.com/reference/android/os/Build.html</a><br/> |
| 7.  Android 4.1 al owed version strings:<br/> |
| <a href="http://developer.android.com/reference/android/os/Build.html">http://source.android.com/compatibility/4.1/versions.html</a><br/> |
| 8.  Renderscript:<br/> |
| <a href="http://source.android.com/compatibility/4.1/versions.html">http://developer.android.com/guide/topics/graphics/rendersc</a>ript.html<br/> |
| 9.  Hardware Acceleration:<br/> |
| http://developer.android.com/guide/topics/graphics/hardware-accel.html<br/> |
| 10.  android.webkit.WebView class:<br/> |
| http://developer.android.com/reference/android/webkit/WebView.html<br/> |
| 11.  HTML5: http://www.whatwg.org/specs/web-apps/current-work/multipage/<br/> |
| 12.  HTML5 offline capabilities: http://dev.w3.org/html5/spec/Overview.html#offline<br/>13.  <a href="http://developer.android.com/reference/android/webkit/WebView.html">HTML5 video tag: http://dev.w3.org/html5/spec/Overview.html#video<br/></a>14.  HTML5/<a href="http://www.whatwg.org/specs/web-apps/current-work/multipage/">W3C geolocation API: http://www.w3.org/TR/geolocation-API/<br/></a>15.  HTML5/W3C webdatabase A<a href="http://dev.w3.org/html5/spec/Overview.html#offline">PI: http://www.w3.org/TR/webdatabase/<br/></a>16.  HTML5/W3C Indexe<a href="http://dev.w3.org/html5/spec/Overview.html#video">dDB API: http://www.w3.org/TR/IndexedDB/<br/></a>17.  Dalvik Virtual Machine specificati<a href="http://www.w3.org/TR/geolocation-API/">on: available in the Android source code,</a> at<br/> |
| dalvik/docs<br/> |
| 18.  AppWidgets:<br/> |
| http://developer.android.com/guide/practices/ui_guidelines/widget_design.html<br/> |
| 19.  Notifications:<br/> |
| http://developer.android.com/guide/topics/ui/notifiers/notifications.html<br/> |
| 20.  <a href="http://developer.android.com/guide/practices/ui_guidelines/widget_design.html">Application Resources: http://code.google.com/android/reference/available-</a><br/> |
| resources.html<br/> |
| 21.  <a href="http://developer.android.com/guide/topics/ui/notifiers/notifications.html">Status Bar icon style guide:</a><br/> |
| <a href="http://code.google.com/android/reference/available-resources.html">http://developer.android.com/guide/practices/ui_guidelines/icon_design_status_b</a>ar.html<br/> |
| 22.  <a href="http://code.google.com/android/reference/available-resources.html">Search Manager:</a><br/> |
| http://developer.android.com/reference/android/app/SearchManager.html<br/> |
| 23.  Toasts: http://developer.android.com/reference/android/widget/Toast.html<br/>24.  Themes: http://developer.android.com/guide/topics/ui/themes.html<br/> |
| <hr/> |
| <a name=4></a>25.  R.style class: h<a href="http://developer.android.com/reference/android/R.style.html">ttp://developer.android.com/reference/android/R.style.html<br/></a>26.  <a href="http://developer.android.com/resources/articles/live-wallpapers.html">Live Wal papers: http://developer.android.com/resources/articles/live-</a><br/> |
| <a href="http://developer.android.com/resources/articles/live-wallpapers.html">wal papers.html</a><br/> |
| 27.  Android Device Administration:<br/> |
| <a href="http://developer.android.com/guide/topics/admin/device-admin.html">http://developer.android.com/guide/topics/admin/device-admin.html</a><br/> |
| 28.  android.app.admin.DevicePolicyManager class:<br/> |
| <a href="http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html">http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html</a><br/> |
| 29.  Android Accessibility Service APIs:<br/> |
| http://developer.android.com/reference/android/accessibilityservice/package-<br/><a href="http://developer.android.com/reference/android/accessibilityservice/package-summary.html">summary.html</a><br/> |
| 30.  Android Accessibility APIs:<br/> |
| http://developer.android.com/reference/android/view/accessibility/package-<br/><a href="http://developer.android.com/reference/android/view/accessibility/package-summary.html">summary.html</a><br/> |
| 31.  <a href="http://developer.android.com/reference/android/view/accessibility/package-summary.html">Eyes Free project: http://code.google.com/p/eyes-free<br/></a>32.  Text-To-Speech APIs<a href="http://http//code.google.com/p/eyes-free">:</a><br/> |
| http://developer.android.com/reference/android/speech/tts/package-<br/><a href="http://developer.android.com/reference/android/speech/tts/package-summary.html">summary.html</a><br/> |
| 33.  <a href="http://developer.android.com/reference/android/speech/tts/package-summary.html">Reference tool documentation (for adb, aapt, ddms):</a><br/> |
| http://developer.android.com/guide/developing/tools/index.html<br/> |
| 34.  <a href="http://developer.android.com/guide/developing/tools/index.html">Android apk file description:</a><br/> |
| http://developer.android.com/guide/topics/fundamentals.html<br/> |
| 35.  <a href="http://developer.android.com/guide/topics/fundamentals.html">Manifest files: http://developer.android.com/guide/topics/manifes</a>t/manifest-<br/> |
| i<a href="http://developer.android.com/guide/topics/manifest/manifest-intro.html">ntro.html</a><br/> |
| 36.  <a href="http://developer.android.com/guide/topics/manifest/manifest-intro.html">Monkey testing tool:</a><br/> |
| http://developer.android.com/guide/developing/tools/monkey.html<br/> |
| 37.  <a href="http://developer.android.com/guide/developing/tools/monkey.html">Android android.content.pm.PackageManager class and Hardware F</a>eatures<br/> |
| List:<br/>http://developer.android.com/reference/android/content/pm/PackageManager.html<br/> |
| 38.  Supporting Multiple Screens:<br/> |
| http://developer.android.com/guide/practices/screens_support.html<br/> |
| 39.  android.util.DisplayMetrics:<br/> |
| http://developer.android.com/reference/android/util/DisplayMetrics.html<br/> |
| 40.  android.content.res.Configuration:<br/> |
| <a href="http://developer.android.com/reference/android/util/DisplayMetrics.html">http://developer.android.com/reference/android/content/res/Configuration.htm</a>l<br/> |
| 41.  android.hardware.SensorEvent:<br/> |
| <a href="http://developer.android.com/reference/android/content/res/Configuration.html">http://developer.android.com/reference/android/hardware/SensorEvent.html</a><br/> |
| 42.  Bluetooth API:<br/> |
| <a href="http://developer.android.com/reference/android/hardware/SensorEvent.html">http://developer.android.com/reference/android/bluetooth/package-summary.html</a><br/> |
| 43.  NDEF Push Protocol: http://source.android.com/compatibility/ndef-push-<br/> |
| <a href="http://developer.android.com/reference/android/bluetooth/package-summary.html">protocol.pdf</a><br/> |
| 44.  <a href="http://source.android.com/compatibility/ndef-push-protocol.pdf">MIFARE MF1S503X: http://www.nxp.com/documents/data_sheet/MF1S503x.p</a>df<br/>45.  <a href="http://source.android.com/compatibility/ndef-push-protocol.pdf">MIFARE MF1S703X: http://www.nxp.com/documents/data_sheet/MF1S703x.p</a>df<br/>46.  MIFARE MF0ICU1: http<a href="http://www.nxp.com/documents/data_sheet/MF1S503x.pdf">://www.nxp.com/documents/data_sheet/MF0ICU1.pdf<br/></a>47.  MIFARE MF0ICU2:<br/> |
| http://www.nxp.com/d<a href="http://www.nxp.com/documents/data_sheet/MF0ICU1.pdf">ocuments/short_data_sheet/MF0ICU2_SDS.pdf</a><br/> |
| 48.  MIFARE AN130511:<br/> |
| <a href="http://www.nxp.com/documents/short_data_sheet/MF0ICU2_SDS.pdf">http://www.nxp.com/documents/application_note/AN130511.pdf</a><br/> |
| 49.  MIFARE AN130411:<br/> |
| http://www.nxp.com/documents/application_note/AN130411.pdf<br/> |
| 50.  Camera orientation API:<br/> |
| http://developer.android.com/reference/android/hardware/Camera.html#setDisplayOrientation(int)<br/> |
| 51.  android.hardware.Camera:<br/> |
| http://developer.android.com/reference/android/hardware/Camera.html<br/> |
| 52.  <a href="http://developer.android.com/reference/android/hardware/Camera.html#setDisplayOrientation(int)">Android Open Accessories:</a><br/> |
| http://developer.android.com/guide/topics/usb/accessory.html<br/> |
| 53.  <a href="http://developer.android.com/reference/android/hardware/Camera.html">USB Host API: http://developer.android.com/guide/topics/usb/host.html<br/></a>54.  Android Security and Permissions reference:<br/> |
| <a href="http://developer.android.com/guide/topics/usb/accessory.html">http://developer.android.com/guide/topics/security/security.html</a><br/> |
| 55.  Apps for Android<a href="http://developer.android.com/guide/topics/usb/host.html">: http://code.google.com/p/apps-for-android<br/></a>56.  android.app.DownloadManager class:<br/> |
| <a href="http://developer.android.com/guide/topics/security/security.html">http://developer.android.com/reference/android/app/DownloadMana</a>ger.html<br/> |
| 57.  Android File Transfe<a href="http://code.google.com/p/apps-for-android">r: http://www.android.com/filetransfer<br/></a>58.  Android Media Formats: http://developer.android.com/guide/appendix/media-<br/> |
| f<a href="http://developer.android.com/reference/android/app/DownloadManager.html">ormats.html</a><br/> |
| 59.  HTTP Live Streaming D<a href="http://www.android.com/filetransfer">raft Protocol: http://tools.ietf.org/html/d</a>raft-pantos-http-<br/> |
| li<a href="http://developer.android.com/guide/appendix/media-formats.html">ve-streaming-03</a><br/> |
| 60.  <a href="http://developer.android.com/guide/appendix/media-formats.html">NFC Connection Handover: http://www.nfc-</a><br/> |
| forum.org/specs/spec_list/#conn_handover<br/> |
| 61.  <a href="http://tools.ietf.org/html/draft-pantos-http-live-streaming-03">Bluetooth Secure Simple Pairing Using NFC: http://www.nfc-</a><br/> |
| forum.org/resources/AppDocs/NFCForum_AD_BTSSP_1_0.pdf<br/> |
| 62.  <a href="http://www.nfc-forum.org/specs/spec_list/#conn_handover/">Wifi Multicast API:</a><br/> |
| http://developer.android.com/reference/android/net/wifi/WifiManager.MulticastLock.html<br/> |
| <hr/> |
| <a name=5></a>63.  Action Assist:<br/> |
| <a href="http://developer.android.com/reference/android/content/Intent.html#ACTION_ASSIST">http://developer.android.com/reference/android/content/Intent.html#ACTION_ASSIST</a><br/> |
| 64.  USB Charging Specification:<br/> |
| <a href="http://www.usb.org/developers/devclass_docs/USB_Battery_Charging_1.2.pdf">http://www.usb.org/developers/devclass_docs/USB_Battery_Charging_1.2.pdf</a><br/> |
| 65.  Android Beam: h<a href="http://developer.android.com/guide/topics/nfc/nfc.html">ttp://developer.android.com/guide/topics/nfc/nfc.html<br/></a>66.  Android USB Audio:<br/> |
| <a href="http://developer.android.com/reference/android/hardware/usb/UsbConstants.html#USB_CLASS_AUDIO">http://developer.android.com/reference/android/hardware/usb/UsbConstants.html#USB_CLASS_AUDIO</a><br/> |
| 67.  Android NFC Sharing Settings:<br/> |
| http://developer.android.com/reference/android/provider/Settings.html#ACTION_NFCSHARING_SETTINGS<br/> |
| 68.  Wifi Direct (Wifi P2P):<br/> |
| http://developer.android.com/reference/android/net/wifi/p2p/WifiP2pManager.html<br/> |
| 69.  Media Remote Control Client:<br/> |
| http://developer.android.com/reference/android/media/RemoteControlClient.html<br/> |
| 70.  <a href="http://developer.android.com/reference/android/media/RemoteControlClient.html">Motion Event API:</a><br/> |
| http://developer.android.com/reference/android/view/MotionEvent.html<br/> |
| 71.  <a href="http://developer.android.com/reference/android/view/MotionEvent.html">Touch Input Configuration: http://source.android.com/tech/input/touch-</a><br/> |
| <a href="http://source.android.com/tech/input/touch-devices.html">devices.html</a><br/> |
| Many of these resources are derived directly or indirectly from the Android 4.1 SDK,<br/>and wil  be functional y identical to the information in that SDK's documentation. In any<br/>cases where this Compatibility Definition or the Compatibility Test Suite disagrees with<br/>the SDK documentation, the SDK documentation is considered authoritative. Any<br/>technical details provided in the references included above are considered by<br/>inclusion to be part of this Compatibility Definition.<br/> |
| <b>3. Software</b><br/> |
| <b>3.1. Managed API Compatibility</b><br/> |
| The managed (Dalvik-based) execution environment is the primary vehicle for Android<br/>applications. The Android application programming interface (API) is the set of<br/>Android platform interfaces exposed to applications running in the managed VM<br/>environment. Device implementations MUST provide complete implementations,<br/>including al  documented behaviors, of any documented API exposed by the Android<br/>4.1 SDK [Resources, 4].<br/> |
| Device im<a href="file:///usr/local/google/home/gurunagarajan/android_dev/master/vendor/android/compatibility/cdd/jb/cdd-jb.xhtml#resources04">plementations M</a>UST NOT omit any managed APIs, alter API interfaces or<br/>signatures, deviate from the documented behavior, or include no-ops, except where<br/>specifical y al owed by this Compatibility Definition.<br/> |
| This Compatibility Definition permits some types of hardware for which Android<br/>includes APIs to be omitted by device implementations. In such cases, the APIs MUST<br/>stil  be present and behave in a reasonable way. See Section 7 for specific<br/>requirements for this scenario.<br/> |
| <b>3.2. Soft API Compatibility</b><br/> |
| In addition to the managed APIs from Section 3.1, Android also includes a significant<br/>runtime-only "soft" API, in the form of such things such as Intents, permissions, and<br/>similar aspects of Android applications that cannot be enforced at application compile<br/>time.<br/> |
| <b>3.2.1. Permissions</b><br/> |
| Device implementers MUST support and enforce al  permission constants as<br/>documented by the Permission reference page [Resources, 5]. Note that Section 10<br/>lists additional requirements related to the Android security model.<br/> |
| <b>3.2.2. Build Parameters</b><br/> |
| The Android APIs include a number of constants on the  android.os.Build class<br/>[Resources, 6] that are intended to describe the current device. To provide consistent,<br/>meaningful values across device implementations, the table below includes additional<br/>restrictions on the formats of these values to which device implementations MUST<br/>c<a href="file:///usr/local/google/home/gurunagarajan/android_dev/master/vendor/android/compatibility/cdd/jb/cdd-jb.xhtml#resources06">onform.</a><br/> |
| <b>Parameter</b><br/> |
| <b>Comments</b><br/> |
| The version of the currently-executing Android system, in human-readable format. This field MUST have one<br/> |
| android.os.Build.VERSION.RELEASE<br/> |
| of the string values defined in [Resources, 7].<br/> |
| The version of the currently-executing Android system, in a format accessible to third-party application code.<br/> |
| android.os.Build.VERSION.SDK<br/> |
| For Android 4.1, this field MUST have the integer value 16.<br/> |
| <hr/> |
| <a name=6></a>The version of the currently-executing Android system, in a format accessible to third-party application code.<br/> |
| android.os.Build.VERSION.SDK_INT<br/> |
| For Android 4.1, this field MUST have the integer value 16.<br/> |
| A value chosen by the device implementer designating the specific build of the currently-executing Android<br/>system, in human-readable format. This value MUST NOT be re-used for different builds made available to<br/> |
| android.os.Build.VERSION.INCREMENTAL<br/> |
| end users. A typical use of this field is to indicate which build number or source-control change identifier was<br/>used to generate the build. There are no requirements on the specific format of this field, except that it MUST<br/>NOT be nul  or the empty string ("").<br/> |
| A value chosen by the device implementer identifying the specific internal hardware used by the device, in<br/>human-readable format. A possible use of this field is to indicate the specific revision of the board powering<br/> |
| android.os.Build.BOARD<br/> |
| the device. The value of this field MUST be encodable as 7-bit ASCI and match the regular expression<br/> |
| "^[a-zA-Z0-9.,_-]+$".<br/> |
| A value chosen by the device implementer identifying the name of the company, organization, individual, etc.<br/>who produced the device, in human-readable format. A possible use of this field is to indicate the OEM<br/> |
| android.os.Build.BRAND<br/> |
| and/or carrier who sold the device. The value of this field MUST be encodable as 7-bit ASCI and match the<br/>regular expression "^[a-zA-Z0-9.,_-]+$".<br/> |
| The name of the instruction set (CPU type + ABI convention) of native code. See  Section 3.3: Native API<br/> |
| android.os.Build.CPU_ABI<br/> |
| Co<a href="file:///usr/local/google/home/gurunagarajan/android_dev/master/vendor/android/compatibility/cdd/jb/cdd-jb.xhtml#section-3.3">mpatibility.</a><br/> |
| The name of the second instruction set (CPU type + ABI convention) of native code. See  Section 3.3: Native<br/> |
| android.os.Build.CPU_ABI2<br/> |
| AP<a href="file:///usr/local/google/home/gurunagarajan/android_dev/master/vendor/android/compatibility/cdd/jb/cdd-jb.xhtml#section-3.3">I Compatibility.</a><br/> |
| A v<a href="file:///usr/local/google/home/gurunagarajan/android_dev/master/vendor/android/compatibility/cdd/jb/cdd-jb.xhtml#section-3.3">alue chosen by the device implementer identifying the specific configuration or revision of the body</a><br/> |
| android.os.Build.DEVICE<br/> |
| (sometimes cal ed "industrial design") of the device. The value of this field MUST be encodable as 7-bit<br/>ASCI and match the regular expression "^[a-zA-Z0-9.,_-]+$".<br/> |
| A string that uniquely identifies this build. It SHOULD be reasonably human-readable. It MUST fol ow this<br/>template: <br/> |
| $(BRAND)/$(PRODUCT)/$(DEVICE):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS)<br/> |
| For example: <br/> |
| android.os.Build.FINGERPRINT<br/> |
| acme/mydevice/generic:4.1/JRN53/3359:userdebug/test-keys<br/> |
| The fingerprint MUST NOT include whitespace characters. If other fields included in the template above have<br/>whitespace characters, they MUST be replaced in the build fingerprint with another character, such as the<br/>underscore ("_") character. The value of this field MUST be encodable as 7-bit ASCI.<br/> |
| The name of the hardware (from the kernel command line or /proc). It SHOULD be reasonably human-<br/> |
| android.os.Build.HARDWARE<br/> |
| readable. The value of this field MUST be encodable as 7-bit ASCI and match the regular expression "^[a-<br/> |
| zA-Z0-9.,_-]+$".<br/> |
| A string that uniquely identifies the host the build was built on, in human readable format. There are no<br/> |
| android.os.Build.HOST<br/> |
| requirements on the specific format of this field, except that it MUST NOT be nul  or the empty string ("").<br/> |
| An identifier chosen by the device implementer to refer to a specific release, in human readable format. This<br/>field can be the same as android.os.Build.VERSION.INCREMENTAL, but SHOULD be a value sufficiently<br/> |
| android.os.Build.ID<br/> |
| meaningful for end users to distinguish between software builds. The value of this field MUST be encodable<br/>as 7-bit ASCI and match the regular expression "^[a-zA-Z0-9.,_-]+$".<br/> |
| The trade name of the Original Equipment Manufacturer (OEM) of the product. There are no requirements on<br/> |
| android.os.Build.MANUFACTURER<br/> |
| the specific format of this field, except that it MUST NOT be nul  or the empty string ("").<br/> |
| A value chosen by the device implementer containing the name of the device as known to the end user. This<br/> |
| android.os.Build.MODEL<br/> |
| SHOULD be the same name under which the device is marketed and sold to end users. There are no<br/>requirements on the specific format of this field, except that it MUST NOT be nul  or the empty string ("").<br/> |
| A value chosen by the device implementer containing the development name or code name of the product<br/> |
| android.os.Build.PRODUCT<br/> |
| (SKU). MUST be human-readable, but is not necessarily intended for view by end users. The value of this<br/>field MUST be encodable as 7-bit ASCI and match the regular expression "^[a-zA-Z0-9.,_-]+$".<br/> |
| A hardware serial number, if available. The value of this field MUST be encodable as 7-bit ASCI and match<br/> |
| android.os.Build.SERIAL<br/> |
| the regular expression "^([a-zA-Z0-9]{0,20})$".<br/> |
| A comma-separated list of tags chosen by the device implementer that further distinguish the build. For<br/> |
| android.os.Build.TAGS<br/> |
| example, "unsigned,debug". The value of this field MUST be encodable as 7-bit ASCI and match the regular<br/>expression "^[a-zA-Z0-9.,_-]+$".<br/> |
| android.os.Build.TIME<br/> |
| A value representing the timestamp of when the build occurred.<br/> |
| A value chosen by the device implementer specifying the runtime configuration of the build. This field<br/>SHOULD have one of the values corresponding to the three typical Android runtime configurations: "user",<br/> |
| android.os.Build.TYPE<br/> |
| "userdebug", or "eng". The value of this field MUST be encodable as 7-bit ASCI and match the regular<br/>expression "^[a-zA-Z0-9.,_-]+$".<br/> |
| A name or user ID of the user (or automated user) that generated the build. There are no requirements on<br/> |
| android.os.Build.USER<br/> |
| the specific format of this field, except that it MUST NOT be nul  or the empty string ("").<br/> |
| <b>3.2.3. Intent Compatibility</b><br/> |
| Device implementations MUST honor Android's loose-coupling Intent system, as<br/> |
| <hr/> |
| <a name=7></a>described in the sections below. By "honored", it is meant that the device implementer<br/>MUST provide an Android Activity or Service that specifies a matching Intent filter and<br/>binds to and implements correct behavior for each specified Intent pattern.<br/> |
| <b>3.2.3.1. Core Application Intents</b><br/> |
| The Android upstream project defines a number of core applications, such as contacts,<br/>calendar, photo gal ery, music player, and so on. Device implementers MAY replace<br/>these applications with alternative versions.<br/> |
| However, any such alternative versions MUST honor the same Intent patterns provided<br/>by the upstream project. For example, if a device contains an alternative music player,<br/>it must stil  honor the Intent pattern issued by third-party applications to pick a song.<br/> |
| The fol owing applications are considered core Android system applications:<br/> |
| Desk Clock<br/>Browser<br/>Calendar<br/>Contacts<br/>Gal ery<br/>GlobalSearch<br/>Launcher<br/>Music<br/>Settings<br/> |
| The core Android system applications include various Activity, or Service components<br/>that are considered "public". That is, the attribute "android:exported" may be absent, or<br/>may have the value "true".<br/> |
| For every Activity or Service defined in one of the core Android system apps that is not<br/>marked as non-public via an android:exported attribute with the value "false", device<br/>implementations MUST include a compontent of the same type implementing the<br/>same Intent filter patterns as the core Android system app.<br/> |
| In other words, a device implementation MAY replace core Android system apps;<br/>however, if it does, the device implementation MUST support al  Intent patterns defined<br/>by each core Android system app being replaced.<br/> |
| <b>3.2.3.2. Intent Overrides</b><br/> |
| As Android is an extensible platform, device implementations MUST al ow each Intent<br/>pattern referenced in Section 3.2.3.2 to be overridden by third-party applications. The<br/>upstream Android open source implementation al ows this by default; device<br/>implementers MUST NOT attach special privileges to system applications' use of<br/>these Intent patterns, or prevent third-party applications from binding to and assuming<br/>control of these patterns. This prohibition specifical y includes but is not limited to<br/>disabling the "Chooser" user interface which al ows the user to select between multiple<br/>applications which al  handle the same Intent pattern.<br/> |
| However, device implementations MAY provide default activities for specific URI<br/>patterns (eg. http://play.google.com) if the default activity provides a more specific filter<br/>for the data URI. For example, an intent filter specifying the data URI<br/>"http://www.android.com" is more specific than the browser filter for "http://". Device<br/>implementations MUST provide a user interface for users to modify the default activity<br/>for intents.<br/> |
| <b>3.2.3.3. Intent Namespaces</b><br/> |
| Device implementations MUST NOT include any Android component that honors any<br/>new Intent or Broadcast Intent patterns using an ACTION, CATEGORY, or other key<br/>string in the android.* or com.android.* namespace. Device implementers MUST NOT<br/>include any Android components that honor any new Intent or Broadcast Intent patterns<br/>using an ACTION, CATEGORY, or other key string in a package space belonging to<br/>another organization. Device implementers MUST NOT alter or extend any of the Intent<br/>patterns used by the core apps listed in Section 3.2.3.1. Device implementations MAY<br/>include Intent patterns using namespaces clearly and obviously associated with their<br/>own organization.<br/> |
| This prohibition is analogous to that specified for Java language classes in Section<br/>3.6.<br/> |
| <b>3.2.3.4. Broadcast Intents</b><br/> |
| Third-party applications rely on the platform to broadcast certain Intents to notify them<br/> |
| <hr/> |
| <a name=8></a>of changes in the hardware or software environment. Android-compatible devices<br/>MUST broadcast the public broadcast Intents in response to appropriate system<br/>events. Broadcast Intents are described in the SDK documentation.<br/> |
| <b>3.3. Native API Compatibility</b><br/> |
| <b>3.3.1 Application Binary Interfaces</b><br/> |
| Managed code running in Dalvik can cal  into native code provided in the application<br/>.apk file as an ELF .so file compiled for the appropriate device hardware architecture.<br/>As native code is highly dependent on the underlying processor technology, Android<br/>defines a number of Application Binary Interfaces (ABIs) in the Android NDK, in the file<br/> |
| docs/CPU-ARCH-ABIS.html. If a device implementation is compatible with one or more<br/> |
| defined ABIs, it SHOULD implement compatibility with the Android NDK, as below.<br/> |
| If a device implementation includes support for an Android ABI, it:<br/> |
| MUST include support for code running in the managed environment to cal  into<br/>native code, using the standard Java Native Interface (JNI) semantics.<br/>MUST be source-compatible (i.e. header compatible) and binary-compatible (for<br/>the ABI) with each required library in the list below<br/>MUST accurately report the native Application Binary Interface (ABI) supported<br/>by the device, via the android.os.Build.CPU_ABI API<br/>MUST report only those ABIs documented in the latest version of the Android<br/>NDK, in the file docs/CPU-ARCH-ABIS.txt<br/>SHOULD be built using the source code and header files available in the<br/>upstream Android open source project<br/> |
| The fol owing native code APIs MUST be available to apps that include native code:<br/> |
| libc (C library)<br/>libm (math library)<br/>Minimal support for C++<br/>JNI interface<br/>liblog (Android logging)<br/>libz (Zlib compression)<br/>libdl (dynamic linker)<br/>libGLESv1_CM.so (OpenGL ES 1.0)<br/>libGLESv2.so (OpenGL ES 2.0)<br/>libEGL.so (native OpenGL surface management)<br/>libjnigraphics.so<br/>libOpenSLES.so (OpenSL ES 1.0.1 audio support)<br/>libOpenMAXAL.so (OpenMAX AL 1.0.1 support)<br/>libandroid.so (native Android activity support)<br/>Support for OpenGL, as described below<br/> |
| Note that future releases of the Android NDK may introduce support for additional<br/>ABIs. If a device implementation is not compatible with an existing predefined ABI, it<br/>MUST NOT report support for any ABI at al .<br/> |
| Native code compatibility is chal enging. For this reason, it should be repeated that<br/>device implementers are VERY strongly encouraged to use the upstream<br/>implementations of the libraries listed above to help ensure compatibility.<br/> |
| <b>3.4. Web Compatibility</b><br/> |
| <b>3.4.1. WebView Compatibility</b><br/> |
| The Android Open Source implementation uses the WebKit rendering engine to<br/>implement the android.webkit.WebView. Because it is not feasible to develop a<br/>comprehensive test suite for a web rendering system, device implementers MUST use<br/>the specific upstream build of WebKit in the WebView implementation. Specifical y:<br/> |
| Device implementations' android.webkit.WebView implementations MUST be<br/>based on the 534.30 WebKit build from the upstream Android Open Source tree<br/>for Android 4.1. This build includes a specific set of functionality and security<br/>fixes for the WebView. Device implementers MAY include customizations to the<br/>WebKit implementation; however, any such customizations MUST NOT alter the<br/>behavior of the WebView, including rendering behavior.<br/>The user agent string reported by the WebView MUST be in this format:<br/> |
| Mozilla/5.0 (Linux; U; Android $(VERSION); $(LOCALE); $(MODEL)<br/> |
| Build/$(BUILD)) AppleWebKit/534.30 (KHTML, like Gecko) Version/4.1<br/> |
| Mobile Safari/534.30<br/> |
| The value of the $(VERSION) string MUST be the same as the value for<br/> |
| <hr/> |
| <a name=9></a>The value of the $(VERSION) string MUST be the same as the value for<br/> |
| android.os.Build.VERSION.RELEASE<br/> |
| The value of the $(LOCALE) string SHOULD fol ow the ISO conventions for<br/>country code and language, and SHOULD refer to the current configured<br/>locale of the device<br/>The value of the $(MODEL) string MUST be the same as the value for<br/> |
| android.os.Build.MODEL<br/> |
| The value of the $(BUILD) string MUST be the same as the value for<br/> |
| android.os.Build.ID<br/> |
| Device implementations MAY omit Mobile in the user agent string<br/> |
| The WebView component SHOULD include support for as much of HTML5<br/>[Resources, 11] as possible. Minimal y, device implementations MUST support each of<br/>these APIs associated with HTML5 in the WebView:<br/> |
| application cache/offline operation [Resources, 12]<br/>the <video> tag [Resources, 13]<br/>geolocation [Reso<a href="file:///usr/local/google/home/gurunagarajan/android_dev/master/vendor/android/compatibility/cdd/jb/cdd-jb.xhtml#resources13">urces, 14]</a><br/> |
| Additional y, device implementations MUST support the HTML5/W3C webstorage API<br/>[Resources, 15], and SHOULD support the HTML5/W3C IndexedDB API [Resources,<br/><a href="file:///usr/local/google/home/gurunagarajan/android_dev/master/vendor/android/compatibility/cdd/jb/cdd-jb.xhtml#resources15">16]. <i>Note that as</i></a><a href="file:///usr/local/google/home/gurunagarajan/android_dev/master/vendor/android/compatibility/cdd/jb/cdd-jb.xhtml#resources16"><i> the web development standards bodies are transitioning to favor<br/></i></a><i>I<a href="file:///usr/local/google/home/gurunagarajan/android_dev/master/vendor/android/compatibility/cdd/jb/cdd-jb.xhtml#resources16">ndexedDB over webstorage, IndexedDB is expected to become a required<br/></a></i><i>component in a future version of Android.</i><br/> |
| HTML5 APIs, like al  JavaScript APIs, MUST be disabled by default in a WebView,<br/>unless the developer explicitly enables them via the usual Android APIs.<br/> |
| <b>3.4.2. Browser Compatibility</b><br/> |
| Device implementations MUST include a standalone Browser application for general<br/>user web browsing. The standalone Browser MAY be based on a browser technology<br/>other than WebKit. However, even if an alternate Browser application is used, the<br/> |
| android.webkit.WebView component provided to third-party applications MUST be<br/> |
| based on WebKit, as described in Section 3.4.1.<br/> |
| Implementations MAY ship a custom user agent string in the standalone Browser<br/>application.<br/> |
| The standalone Browser application (whether based on the upstream WebKit Browser<br/>application or a third-party replacement) SHOULD include support for as much of<br/>HTML5 [Resources, 11] as possible. Minimal y, device implementations MUST support<br/>each of these APIs associated with HTML5:<br/> |
| application cache/offline operation [Resources, 12]<br/>the <video> tag [Resources, 13]<br/>geolocation [Resources, 14]<br/> |
| Additional y, device implementations MUST support the HTML5/W3C webstorage API<br/>[Resources, 15], an<a href="file:///usr/local/google/home/gurunagarajan/android_dev/master/vendor/android/compatibility/cdd/jb/cdd-jb.xhtml#resources14">d SHOULD supp</a>ort the HTML5/W3C IndexedDB API [Resources,<br/>16]. <i>Note that as the web development standards bodies are transitioning to favor<br/>IndexedDB over webstorage, IndexedDB is expected to become a required<br/><a href="file:///usr/local/google/home/gurunagarajan/android_dev/master/vendor/android/compatibility/cdd/jb/cdd-jb.xhtml#resources16">component in a future version of Android.</a></i><br/> |
| <b>3.5. API Behavioral Compatibility</b><br/> |
| The behaviors of each of the API types (managed, soft, native, and web) must be<br/>consistent with the preferred implementation of the upstream Android open source<br/>project [Resources, 3]. Some specific areas of compatibility are:<br/> |
| Devices MUST NOT change the behavior or semantics of a standard Intent<br/>De<a href="file:///usr/local/google/home/gurunagarajan/android_dev/master/vendor/android/compatibility/cdd/jb/cdd-jb.xhtml#resources03">vices MUST N</a>OT alter the lifecycle or lifecycle semantics of a particular type<br/>of system component (such as Service, Activity, ContentProvider, etc.)<br/>Devices MUST NOT change the semantics of a standard permission<br/> |
| The above list is not comprehensive. The Compatibility Test Suite (CTS) tests<br/>significant portions of the platform for behavioral compatibility, but not al . It is the<br/>responsibility of the implementer to ensure behavioral compatibility with the Android<br/>Open Source Project. For this reason, device implementers SHOULD use the source<br/>code available via the Android Open Source Project where possible, rather than re-<br/>implement significant parts of the system.<br/> |
| <b>3.6. API Namespaces</b><br/> |
| Android fol ows the package and class namespace conventions defined by the Java<br/> |
| <hr/> |
| <a name=10></a>programming language. To ensure compatibility with third-party applications, device<br/>implementers MUST NOT make any prohibited modifications (see below) to these<br/>package namespaces:<br/> |
| java.*<br/>javax.*<br/>sun.*<br/>android.*<br/>com.android.*<br/> |
| Prohibited modifications include:<br/> |
| Device implementations MUST NOT modify the publicly exposed APIs on the<br/>Android platform by changing any method or class signatures, or by removing<br/>classes or class fields.<br/>Device implementers MAY modify the underlying implementation of the APIs, but<br/>such modifications MUST NOT impact the stated behavior and Java-language<br/>signature of any publicly exposed APIs.<br/>Device implementers MUST NOT add any publicly exposed elements (such as<br/>classes or interfaces, or fields or methods to existing classes or interfaces) to the<br/>APIs above.<br/> |
| A "publicly exposed element" is any construct which is not decorated with the "@hide"<br/>marker as used in the upstream Android source code. In other words, device<br/>implementers MUST NOT expose new APIs or alter existing APIs in the namespaces<br/>noted above. Device implementers MAY make internal-only modifications, but those<br/>modifications MUST NOT be advertised or otherwise exposed to developers.<br/> |
| Device implementers MAY add custom APIs, but any such APIs MUST NOT be in a<br/>namespace owned by or referring to another organization. For instance, device<br/>implementers MUST NOT add APIs to the com.google.* or similar namespace; only<br/>Google may do so. Similarly, Google MUST NOT add APIs to other companies'<br/>namespaces. Additional y, if a device implementation includes custom APIs outside<br/>the standard Android namespace, those APIs MUST be packaged in an Android<br/>shared library so that only apps that explicitly use them (via the <uses-library><br/>mechanism) are affected by the increased memory usage of such APIs.<br/> |
| If a device implementer proposes to improve one of the package namespaces above<br/>(such as by adding useful new functionality to an existing API, or adding a new API), the<br/>implementer SHOULD visit source.android.com and begin the process for contributing<br/>changes and code, according to the information on that site.<br/> |
| Note that the restrictions above correspond to standard conventions for naming APIs in<br/>the Java programming language; this section simply aims to reinforce those<br/>conventions and make them binding through inclusion in this compatibility definition.<br/> |
| <b>3.7. Virtual Machine Compatibility</b><br/> |
| Device implementations MUST support the ful  Dalvik Executable (DEX) bytecode<br/>specification and Dalvik Virtual Machine semantics [Resources, 17].<br/> |
| Device implementations MUST configure Dalvik to al ocate memory in accordance<br/>with the upstream Android platform, and as specified b<a href="file:///usr/local/google/home/gurunagarajan/android_dev/master/vendor/android/compatibility/cdd/jb/cdd-jb.xhtml#resources17">y the fol owing ta</a>ble. (See<br/>Section 7.1.1 for screen size and screen density definitions.)<br/> |
| Note that memory values specified below are considered minimum values, and device<br/>i<a href="file:///usr/local/google/home/gurunagarajan/android_dev/master/vendor/android/compatibility/cdd/jb/cdd-jb.xhtml#section-7.1.1">mplementation</a>s MAY al ocate more memory per application.<br/> |
| <b>Screen Size</b><br/> |
| <b>Screen Density</b><br/> |
| <b>Application Memory</b><br/> |
| smal  / normal / large<br/> |
| ldpi / mdpi<br/> |
| 16MB<br/> |
| smal  / normal / large<br/> |
| tvdpi / hdpi<br/> |
| 32MB<br/> |
| smal  / normal / large<br/> |
| xhdpi<br/> |
| 64MB<br/> |
| xlarge<br/> |
| mdpi<br/> |
| 32MB<br/> |
| xlarge<br/> |
| tvdpi / hdpi<br/> |
| 64MB<br/> |
| xlarge<br/> |
| xhdpi<br/> |
| 128MB<br/> |
| <b>3.8. User Interface Compatibility</b><br/> |
| <b>3.8.1. Widgets</b><br/> |
| Android defines a component type and corresponding API and lifecycle that al ows<br/> |
| <hr/> |
| <a name=11></a>applications to expose an "AppWidget" to the end user [Re<a href="file:///usr/local/google/home/gurunagarajan/android_dev/master/vendor/android/compatibility/cdd/jb/cdd-jb.xhtml#resources18">sources, 18]. The</a> Android<br/>Open Source reference release includes a Launcher application that includes user<br/>interface affordances al owing the user to add, view, and remove AppWidgets from the<br/>home screen.<br/> |
| Device implementations MAY substitute an alternative to the reference Launcher (i.e.<br/>home screen). Alternative Launchers SHOULD include built-in support for AppWidgets,<br/>and expose user interface affordances to add, configure, view, and remove<br/>AppWidgets directly within the Launcher. Alternative Launchers MAY omit these user<br/>interface elements; however, if they are omitted, the device implementation MUST<br/>provide a separate application accessible from the Launcher that al ows users to add,<br/>configure, view, and remove AppWidgets.<br/> |
| Device implementations MUST be capable of rendering widgets that are 4 x 4 in the<br/>standard grid size. (See the App Widget Design Guidelines in the Android SDK<br/>documentation [Resources, 18] for details.<br/> |
| <b>3.8.2. Notifications</b><br/> |
| Android includes APIs that al ow developers to notify users of notable events<br/>[Resources, 19], using hardware and software features of the device.<br/> |
| Some APIs al ow applications to perform notifications or attract attention using<br/>hardware, specifical y sound, vibration, and light. Device implementations MUST<br/>support notifications that use hardware features, as described in the SDK<br/>documentation, and to the extent possible with the device implementation hardware.<br/>For instance, if a device implementation includes a vibrator, it MUST correctly<br/>implement the vibration APIs. If a device implementation lacks hardware, the<br/>corresponding APIs MUST be implemented as no-ops. Note that this behavior is<br/>further detailed in Section 7.<br/> |
| Additional y, the im<a href="file:///usr/local/google/home/gurunagarajan/android_dev/master/vendor/android/compatibility/cdd/jb/cdd-jb.xhtml#section-7">plementatio</a>n MUST correctly render al  resources (icons, sound<br/>files, etc.) provided for in the APIs [Resources, 20], or in the Status/System Bar icon<br/>style guide [Resources, 21]. Device implementers MAY provide an alternative user<br/>experience for notifications than that <a href="file:///usr/local/google/home/gurunagarajan/android_dev/master/vendor/android/compatibility/cdd/jb/cdd-jb.xhtml#resources20">provided by the </a>reference Android Open Source<br/>implementati<a href="file:///usr/local/google/home/gurunagarajan/android_dev/master/vendor/android/compatibility/cdd/jb/cdd-jb.xhtml#resources21">on; however, suc</a>h alternative notification systems MUST support existing<br/>notification resources, as above.<br/> |
| Android 4.1 includes support for rich notifications, such as interactive Views for<br/>ongoing notifications. Device implementations MUST properly display and execute rich<br/>notifications, as documented in the Android APIs.<br/> |
| <b>3.8.3. Search</b><br/> |
| Android includes APIs [Resources, 22] that al ow developers to incorporate search into<br/>their applications, and expose their application's data into the global system search.<br/>General y speaking, this f<a href="file:///usr/local/google/home/gurunagarajan/android_dev/master/vendor/android/compatibility/cdd/jb/cdd-jb.xhtml#resources22">unctionality cons</a>ists of a single, system-wide user interface<br/>that al ows users to enter queries, displays suggestions as users type, and displays<br/>results. The Android APIs al ow developers to reuse this interface to provide search<br/>within their own apps, and al ow developers to supply results to the common global<br/>search user interface.<br/> |
| Device implementations MUST include a single, shared, system-wide search user<br/>interface capable of real-time suggestions in response to user input. Device<br/>implementations MUST implement the APIs that al ow developers to reuse this user<br/>interface to provide search within their own applications. Device implementations<br/>MUST implement the APIs that al ow third-party applications to add suggestions to the<br/>search box when it is run in global search mode. If no third-party applications are<br/>instal ed that make use of this functionality, the default behavior SHOULD be to display<br/>web search engine results and suggestions.<br/> |
| <b>3.8.4. Toasts</b><br/> |
| Applications can use the "Toast" API (defined in [Resources, 23]) to display short non-<br/>modal strings to the end user, that disappear after a brief period of time. Device<br/>implementations MUST display Toasts from applications to end users in some high-<br/>visibility manner.<br/> |
| <b>3.8.5. Themes</b><br/> |
| Android provides "themes" as a mechanism for applications to apply styles across an<br/>entire Activity or application. Android 3.0 introduced a new "Holo" or "holographic"<br/>theme as a set of defined styles for application developers to use if they want to match<br/>the Holo theme look and feel as defined by the Android SDK [Resources, 24]. Device<br/>implementations MUST NOT alter any of the Holo theme attributes exposed to<br/> |
| <hr/> |
| <a name=12></a>applications [<a href="file:///usr/local/google/home/gurunagarajan/android_dev/master/vendor/android/compatibility/cdd/jb/cdd-jb.xhtml#resources25">Resources, 25].</a><br/> |
| Android 4.0 introduced a new "Device Default" theme as a set of defined styles for<br/>application developers to use if they want to match the look and feel of the device<br/>theme as defined by the device implementer. Device implementations MAY modify the<br/>DeviceDefault theme attributes exposed to applications [Re<a href="file:///usr/local/google/home/gurunagarajan/android_dev/master/vendor/android/compatibility/cdd/jb/cdd-jb.xhtml#resources25">sources, 25].</a><br/> |
| <b>3.8.6. Live Wallpapers</b><br/> |
| Android defines a component type and corresponding API and lifecycle that al ows<br/>applications to expose one or more "Live Wal papers" to the end user [Resources, 26].<br/>Live Wal papers are animations, patterns, or similar images with limited input<br/>capabilities that display as a wal paper, behind other applications.<br/> |
| Hardware is considered capable of reliably running live wal papers if it can run al  live<br/>wal papers, with no limitations on functionality, at a reasonable framerate with no<br/>adverse affects on other applications. If limitations in the hardware cause wal papers<br/>and/or applications to crash, malfunction, consume excessive CPU or battery power, or<br/>run at unacceptably low frame rates, the hardware is considered incapable of running<br/>live wal paper. As an example, some live wal papers may use an Open GL 1.0 or 2.0<br/>context to render their content. Live wal paper wil  not run reliably on hardware that<br/>does not support multiple OpenGL contexts because the live wal paper use of an<br/>OpenGL context may conflict with other applications that also use an OpenGL context.<br/> |
| Device implementations capable of running live wal papers reliably as described<br/>above SHOULD implement live wal papers. Device implementations determined to not<br/>run live wal papers reliably as described above MUST NOT implement live wal papers.<br/> |
| <b>3.8.7. Recent Application Display</b><br/> |
| The upstream Android 4.1 source code includes a user interface for displaying recent<br/>applications using a thumbnail image of the application's graphical state at the<br/>moment the user last left the application. Device implementations MAY alter or<br/>eliminate this user interface; however, a future version of Android is planned to make<br/>more extensive use of this functionality. Device implementations are strongly<br/>encouraged to use the upstream Android 4.1 user interface (or a similar thumbnail-<br/>based interface) for recent applications, or else they may not be compatible with a<br/>future version of Android.<br/> |
| <b>3.8.8. Input Management Settings</b><br/> |
| Android 4.1 includes support for Input Management Engines. The Android 4.1 APIs<br/>al ow custom app IMEs to specify user-tunable settings. Device implementations<br/>MUST include a way for the user to access IME settings at al  times when an IME that<br/>provides such user settings is displayed.<br/> |
| <b>3.8.9. Lock Screen Remote Control</b><br/> |
| Android 4.0 introduced support for Remote Control API that lets media applications<br/>integrate with playback controls that are displayed in a remote view like the device<br/>lock screen [Resources, 69]. Device implementations SHOULD include support for<br/>embedding remote controls in the device lock screen.<br/> |
| <b>3.9 Device Administration</b><br/> |
| Android 4.1 includes features that al ow security-aware applications to perform device<br/>administration functions at the system level, such as enforcing password policies or<br/>performing remote wipe, through the Android Device Administration API [Resources,<br/>27]. Device implementations MUST provide an implementation of the<br/> |
| DevicePolicyManager class [Resources, 28], and SHOULD support the ful  range of<br/> |
| <a href="file:///usr/local/google/home/gurunagarajan/android_dev/master/vendor/android/compatibility/cdd/jb/cdd-jb.xhtml#resources27">device administration policies defined in the Android SDK documentation [Resources,<br/>27].</a><br/> |
| <b>Note:</b> while some of the requirements outlined above are stated as "SHOULD" for<br/><a href="file:///usr/local/google/home/gurunagarajan/android_dev/master/vendor/android/compatibility/cdd/jb/cdd-jb.xhtml#resources27">Android 4.1, the Compatibility Definition for a future version is planned to change these<br/></a>to "MUST". That is, these requirements are optional in Android 4.1 but <b>will be<br/>required</b> by a future version. Existing and new devices that run Android 4.1 are <b>very<br/>strongly encouraged to meet these requirements in Android 4.1</b>, or they wil  not<br/>be able to attain Android compatibility when upgraded to the future version.<br/> |
| <b>3.10 Accessibility</b><br/> |
| Android 4.1 provides an accessibility layer that helps users with disabilities to navigate<br/>their devices more easily. In addition, Android 4.1 provides platform APIs that enable<br/> |
| <hr/> |
| <a name=13></a>accessibility service implementations to receive cal backs for user and system events<br/>and generate alternate feedback mechanisms, such as text-to-speech, haptic<br/>feedback, and trackbal /d-pad navigation [R<a href="file:///usr/local/google/home/gurunagarajan/android_dev/master/vendor/android/compatibility/cdd/jb/cdd-jb.xhtml#resources29">esources, 29]. D</a>evice implementations<br/>MUST provide an implementation of the Android accessibility framework consistent<br/>with the default Android implementation. Specifical y, device implementations MUST<br/>meet the fol owing requirements.<br/> |
| Device implementations MUST support third party accessibility service<br/>i<a href="file:///usr/local/google/home/gurunagarajan/android_dev/master/vendor/android/compatibility/cdd/jb/cdd-jb.xhtml#resources30">mplementations through the android.accessibilityservice APIs [Resources,<br/>30].<br/></a>Device implementations MUST generate AccessibilityEvents and deliver<br/>these events to al  registered AccessibilityService implementations in a<br/>manner consistent with the default Android implementation.<br/>Device implementations MUST provide a user-accessible mechanism to enable<br/>and disable accessibility services, and MUST display this interface in response<br/>to the android.provider.Settings.ACTION_ACCESSIBILITY_SETTINGS intent.<br/> |
| Additional y, device implementations SHOULD provide an implementation of an<br/>accessibility service on the device, and SHOULD provide a mechanism for users to<br/>enable the accessibility service during device setup. An open source implementation<br/>of an accessibility service is available from the Eyes Free project [Resources, 31].<br/> |
| <b>3.11 Text-to-Speech</b><br/> |
| Android 4.1 includes APIs that al ow applications to make use of text-to-speech (TTS)<br/>services, and al ows service providers to provide implementations of TTS services<br/>[Resources, 32]. Device implementations MUST meet these requirements related to<br/>t<a href="file:///usr/local/google/home/gurunagarajan/android_dev/master/vendor/android/compatibility/cdd/jb/cdd-jb.xhtml#resources32">he Android TTS </a>framework:<br/> |
| Device implementations MUST support the Android TTS framework APIs and<br/>SHOULD include a TTS engine supporting the languages available on the<br/>device. Note that the upstream Android open source software includes a ful -<br/>featured TTS engine implementation.<br/>Device implementations MUST support instal ation of third-party TTS engines.<br/>Device implementations MUST provide a user-accessible interface that al ows<br/>users to select a TTS engine for use at the system level.<br/> |
| <b>4. Application Packaging Compatibility</b><br/> |
| Device implementations MUST instal  and run Android ".apk" files as generated by the<br/>"aapt" tool included in the official Android SDK [Resources, 33].<br/> |
| Devices implementations MUST NOT extend eithe<a href="file:///usr/local/google/home/gurunagarajan/android_dev/master/vendor/android/compatibility/cdd/jb/cdd-jb.xhtml#resources33">r the .apk [Reso</a>urces, 34], Android<br/>Manifest [Resources, 35], Dalvik bytecode [Resources, 17], or renderscript bytecode<br/>formats in such a way that would prevent those files from instal in<a href="file:///usr/local/google/home/gurunagarajan/android_dev/master/vendor/android/compatibility/cdd/jb/cdd-jb.xhtml#resources34">g and running co</a>rrectly<br/>on other c<a href="file:///usr/local/google/home/gurunagarajan/android_dev/master/vendor/android/compatibility/cdd/jb/cdd-jb.xhtml#resources35">ompatible device</a>s. Device impleme<a href="file:///usr/local/google/home/gurunagarajan/android_dev/master/vendor/android/compatibility/cdd/jb/cdd-jb.xhtml#resources17">nters SHOULD u</a>se the reference<br/>upstream implementation of Dalvik, and the reference implementation's package<br/>management system.<br/> |
| <b>5. Multimedia Compatibility</b><br/> |
| Device implementations MUST include at least one form of audio output, such as<br/>speakers, headphone jack, external speaker connection, etc.<br/> |
| <b>5.1. Media Codecs</b><br/> |
| Device implementations MUST support the core media formats specified in the<br/>Android SDK documentation [Resources, 58] except where explicitly permitted in this<br/>document. Specifical y, device implementations MUST support the media formats,<br/>encoders, decoders, file types and container formats defined in the tables below. Al  of<br/>these codecs are provided as s<a href="file:///usr/local/google/home/gurunagarajan/android_dev/master/vendor/android/compatibility/cdd/jb/cdd-jb.xhtml#resources58">oftware impleme</a>ntations in the preferred Android<br/>implementation from the Android Open Source Project.<br/> |
| <b>Please note that neither Google nor the Open Handset Alliance make any<br/>representation that these codecs are unencumbered by third-party patents.<br/>Those intending to use this source code in hardware or software products are<br/>advised that implementations of this code, including in open source software<br/>or shareware, may require patent licenses from the relevant patent holders.</b><br/> |
| Note that these tables do not list specific bitrate requirements for most video codecs<br/>because current device hardware does not necessarily support bitrates that map<br/>exactly to the required bitrates specified by the relevant standards. Instead, device<br/>implementations SHOULD support the highest bitrate practical on the hardware, up to<br/> |
| <hr/> |
| <a name=14></a>the limits defined by the specifications.<br/> |
| <hr/> |
| <a name=15></a><b>File Type(s) /</b><br/> |
| <b>Format /</b><br/> |
| <b>Type</b><br/> |
| <b>Encoder</b><br/> |
| <b>Decoder</b><br/> |
| <b>Details</b><br/> |
| <b>Container</b><br/> |
| <b>Codec</b><br/> |
| <b>Formats</b><br/> |
| Support for<br/> |
| REQUIRED<br/> |
| mono/stereo/5.0/5.1*<br/> |
| MPEG-4<br/> |
| Required for device implementations<br/> |
| content with<br/> |
| AAC Profile<br/> |
| that include microphone hardware<br/> |
| REQUIRED<br/> |
| standard sampling<br/> |
| (AAC LC)<br/> |
| and define<br/> |
| 3GPP<br/> |
| rates from 8 to 48<br/> |
| android.hardware.microphone.<br/> |
| (.3gp)<br/> |
| kHz.<br/> |
| MPEG-4<br/> |
| Support for<br/> |
| (.mp4,<br/> |
| MPEG-4<br/> |
| mono/stereo/5.0/5.1*<br/> |
| .m4a)<br/> |
| HE AAC<br/> |
| content with<br/> |
| ADTS raw<br/> |
|  <br/> |
| REQUIRED<br/> |
| Profile<br/> |
| standard sampling<br/> |
| AAC (.aac,<br/> |
| (AAC+)<br/> |
| rates from 16 to 48<br/> |
| decode in<br/> |
| kHz.<br/> |
| Android<br/>3.1+,<br/> |
| Support for<br/> |
| MPEG-4<br/> |
| REQUIRED for device<br/> |
| encode in<br/> |
| mono/stereo/5.0/5.1*<br/> |
| HE AAC v2<br/> |
| implementations that include<br/> |
| Android<br/> |
| content with<br/> |
| Profile<br/> |
| microphone hardware and<br/> |
|  <br/> |
| 4.0+, ADIF<br/> |
| standard sampling<br/> |
| (enhanced<br/> |
| define<br/> |
| not<br/> |
| rates from 16 to 48<br/> |
| AAC+)<br/> |
| android.hardware.microphone<br/> |
| supported)<br/> |
| kHz.<br/> |
| MPEG-TS<br/> |
| MPEG-4<br/> |
| (.ts, not<br/> |
| Audio<br/> |
| REQUIRED for device<br/> |
| Support for<br/> |
| seekable,<br/> |
| Object Type<br/> |
| implementations that include<br/> |
| mono/stereo content<br/> |
| Android<br/> |
| ER AAC<br/> |
| microphone hardware and<br/> |
| REQUIRED<br/> |
| with standard<br/> |
| 3.0+)<br/> |
| ELD<br/> |
| define<br/> |
| sampling rates from<br/> |
| (Enhanced<br/> |
| android.hardware.microphone<br/> |
| 16 to 48 kHz.<br/> |
| Low Delay<br/>AAC)<br/> |
| REQUIRED<br/> |
| Required for device implementations<br/> |
| 4.75 to 12.2 kbps<br/> |
| AMR-NB<br/> |
| that include microphone hardware<br/> |
| REQUIRED<br/> |
| 3GPP (.3gp)<br/> |
| sampled @ 8kHz<br/> |
| and define<br/> |
| android.hardware.microphone.<br/> |
| REQUIRED<br/> |
| Required for device implementations<br/> |
| 9 rates from 6.60<br/> |
| AMR-WB<br/> |
| that include microphone hardware<br/> |
| REQUIRED<br/> |
| kbit/s to 23.85 kbit/s<br/> |
| 3GPP (.3gp)<br/> |
| and define<br/> |
| sampled @ 16kHz<br/> |
| android.hardware.microphone.<br/> |
| Mono/Stereo (no<br/>multichannel).<br/> |
| Audio<br/> |
| Sample rates up to<br/>48 kHz (but up to<br/>44.1 kHz is<br/>recommended on<br/>devices with 44.1<br/> |
| REQUIRED<br/> |
| FLAC<br/> |
|  <br/> |
| kHz output, as the 48<br/> |
| FLAC (.flac) only<br/> |
| (Android 3.1+)<br/> |
| to 44.1 kHz<br/>downsampler does<br/>not include a low-<br/>pass filter). 16-bit<br/>recommended; no<br/>dither applied for 24-<br/>bit.<br/> |
| Mono/Stereo 8-<br/>320Kbps constant<br/> |
| MP3<br/> |
|  <br/> |
| REQUIRED<br/> |
| MP3 (.mp3)<br/> |
| (CBR) or variable<br/>bit-rate (VBR)<br/> |
| Type 0 and<br/> |
| MIDI Type 0 and 1.<br/> |
| 1 (.mid,<br/> |
| DLS Version 1 and<br/> |
| .xmf, .mxmf)<br/> |
| 2. XMF and Mobile<br/> |
| RTTTL/RTX<br/> |
| MIDI<br/> |
|  <br/> |
| REQUIRED<br/> |
| XMF. Support for<br/> |
| (.rtttl, .rtx)<br/> |
| ringtone formats<br/> |
| OTA (.ota)<br/> |
| RTTTL/RTX, OTA,<br/> |
| iMelody<br/> |
| and iMelody<br/> |
| (.imy)<br/> |
| <hr/> |
| <a name=16></a>Ogg (.ogg)<br/> |
| Vorbis<br/> |
|  <br/> |
| REQUIRED<br/> |
|  <br/> |
| Matroska<br/>(.mkv)<br/> |
| 8-bit and 16-bit<br/>linear PCM** (rates<br/>up to limit of<br/>hardware).Devices<br/>MUST support<br/> |
| PCM/WAVE<br/> |
| REQUIRED<br/> |
| REQUIRED<br/> |
| WAVE (.wav)<br/> |
| sampling rates for<br/>raw PCM recording<br/>at 8000,16000 and<br/>44100 Hz<br/>frequencies<br/> |
| JPEG<br/> |
| REQUIRED<br/> |
| REQUIRED<br/> |
| Base+progressive<br/> |
| JPEG (.jpg)<br/> |
| GIF<br/> |
|  <br/> |
| REQUIRED<br/> |
|  <br/> |
| GIF (.gif)<br/> |
| Image<br/> |
| PNG<br/> |
| REQUIRED<br/> |
| REQUIRED<br/> |
|  <br/> |
| PNG (.png)<br/> |
| BMP<br/> |
|  <br/> |
| REQUIRED<br/> |
|  <br/> |
| BMP (.bmp)<br/> |
| WEBP<br/> |
| REQUIRED<br/> |
| REQUIRED<br/> |
|  <br/> |
| WebP (.webp)<br/> |
| REQUIRED<br/> |
| Required for device implementations<br/> |
| 3GPP<br/> |
| that include camera hardware and<br/> |
| (.3gp)<br/> |
| H.263<br/> |
| REQUIRED<br/> |
|  <br/> |
| define android.hardware.camera<br/> |
| MPEG-4<br/> |
| or<br/> |
| (.mp4)<br/> |
| android.hardware.camera.front.<br/> |
| 3GPP<br/>(.3gp)<br/> |
| REQUIRED<br/> |
| MPEG-4<br/>(.mp4)<br/> |
| Required for device implementations<br/> |
| MPEG-TS<br/> |
| that include camera hardware and<br/> |
| Baseline Profile<br/> |
| Video<br/> |
| H.264 AVC<br/> |
| REQUIRED<br/> |
| (.ts, AAC<br/> |
| define android.hardware.camera<br/> |
| (BP)<br/> |
| audio only,<br/> |
| or<br/> |
| not<br/> |
| android.hardware.camera.front.<br/> |
| seekable,<br/>Android<br/>3.0+)<br/> |
| MPEG-4<br/> |
|  <br/> |
| REQUIRED<br/> |
|  <br/> |
| 3GPP (.3gp)<br/> |
| SP<br/> |
| WebM (.webm)<br/> |
| REQUIRED<br/> |
| and Matroska<br/> |
| VP8<br/> |
|  <br/> |
| (Android<br/> |
|  <br/> |
| (.mkv, Android<br/> |
| 2.3.3+)<br/> |
| 4.0+)<br/> |
| *Note: Only downmix of 5.0/5.1 content is required; recording or rendering more than 2<br/>channels is optional. **Note: 16-bit linear PCM capture is mandatory. 8-bit linear PCM<br/>capture is not mandatory.<br/> |
| <b>5.2 Video Encoding</b><br/> |
| Android device implementations that include a rear-facing camera and declare<br/> |
| android.hardware.camera SHOULD support the fol owing video encoding profiles.<br/> |
| <b>HD (When supported by</b><br/> |
| <b> </b><br/> |
| <b>SD (Low quality) SD (High quality)</b><br/> |
| <b>hardware)</b><br/> |
| H.264 Baseline<br/> |
| H.264 Baseline<br/> |
| <b>Video codec</b><br/> |
| H.264 Baseline Profile<br/> |
| Profile<br/> |
| Profile<br/> |
| <b>Video</b><br/> |
| 176 x 144 px<br/> |
| 480 x 360 px<br/> |
| 1280 x 720 px<br/> |
| <b>resolution</b><br/> |
| <b>Video frame </b>12 fps<br/> |
| 30 fps<br/> |
| 30 fps<br/> |
| <b>rate</b><br/> |
| 500 Kbps or<br/> |
| <b>Video bitrate </b>56 Kbps<br/> |
| 2 Mbps or higher<br/> |
| higher<br/> |
| <b>Audio codec </b>AAC-LC<br/> |
| AAC-LC<br/> |
| AAC-LC<br/> |
| <hr/> |
| <a name=17></a><b>Audio</b><br/> |
| 1 (mono)<br/> |
| 2 (stereo)<br/> |
| 2 (stereo)<br/> |
| <b>channels</b><br/> |
| <b>Audio bitrate </b>24 Kbps<br/> |
| 128 Kbps<br/> |
| 192 Kbps<br/> |
| <b>5.3. Audio Recording</b><br/> |
| When an application has used the android.media.AudioRecord API to start recording<br/>an audio stream, device implementations that include microphone hardware and<br/>declare android.hardware.microphone MUST sample and record audio with each of<br/>these behaviors:<br/> |
| The device SHOULD exhibit approximately flat amplitude versus frequency<br/>characteristics; specifical y, ±3 dB, from 100 Hz to 4000 Hz<br/>Audio input sensitivity SHOULD be set such that a 90 dB sound power level<br/>(SPL) source at 1000 Hz yields RMS of 2500 for 16-bit samples.<br/>PCM amplitude levels SHOULD linearly track input SPL changes over at least a<br/>30 dB range from -18 dB to +12 dB re 90 dB SPL at the microphone.<br/>Total harmonic distortion SHOULD be less than 1% for 1Khz at 90 dB SPL input<br/>level.<br/> |
| In addition to the above recording specifications, when an application has started<br/>recording an audio stream using the<br/> |
| android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION audio source:<br/> |
| Noise reduction processing, if present, MUST be disabled.<br/>Automatic gain control, if present, MUST be disabled.<br/> |
| <b>Note:</b> while some of the requirements outlined above are stated as "SHOULD" for<br/>Android 4.1, the Compatibility Definition for a future version is planned to change these<br/>to "MUST". That is, these requirements are optional in Android 4.1 but <b>will be<br/>required</b> by a future version. Existing and new devices that run Android 4.1 are <b>very<br/>strongly encouraged to meet these requirements in Android 4.1</b>, or they wil  not<br/>be able to attain Android compatibility when upgraded to the future version.<br/> |
| <b>5.4. Audio Latency</b><br/> |
| Audio latency is broadly defined as the interval between when an application requests<br/>an audio playback or record operation, and when the device implementation actual y<br/>begins the operation. Many classes of applications rely on short latencies, to achieve<br/>real-time effects such sound effects or VOIP communication. Device implementations<br/>that include microphone hardware and declare android.hardware.microphone<br/>SHOULD meet al  audio latency requirements outlined in this section. See Section 7<br/>for details on the conditions under which microphone hardware may be omitted by<br/>device implementations.<br/> |
| For the purposes of this section:<br/> |
| "cold output latency" is defined to be the interval between when an application<br/>requests audio playback and when sound begins playing, when the audio system<br/>has been idle and powered down prior to the request<br/>"warm output latency" is defined to be the interval between when an application<br/>requests audio playback and when sound begins playing, when the audio system<br/>has been recently used but is currently idle (that is, silent)<br/>"continuous output latency" is defined to be the interval between when an<br/>application issues a sample to be played and when the speaker physical y plays<br/>the corresponding sound, while the device is currently playing back audio<br/>"cold input latency" is defined to be the interval between when an application<br/>requests audio recording and when the first sample is delivered to the<br/>application via its cal back, when the audio system and microphone has been<br/>idle and powered down prior to the request<br/>"continuous input latency" is defined to be when an ambient sound occurs and<br/>when the sample corresponding to that sound is delivered to a recording<br/>application via its cal back, while the device is in recording mode<br/> |
| Using the above definitions, device implementations SHOULD exhibit each of these<br/>properties:<br/> |
| cold output latency of 100 mil iseconds or less<br/>warm output latency of 10 mil iseconds or less<br/>continuous output latency of 45 mil iseconds or less<br/>cold input latency of 100 mil iseconds or less<br/>continuous input latency of 50 mil iseconds or less<br/> |
| <b>Note:</b> while the requirements outlined above are stated as "SHOULD" for Android 4.1,<br/> |
| <hr/> |
| <a name=18></a>the Compatibility Definition for a future version is planned to change these to "MUST".<br/>That is, these requirements are optional in Android 4.1 but <b>will be required</b> by a future<br/>version. Existing and new devices that run Android 4.1 are <b>very strongly<br/>encouraged to meet these requirements in Android 4.1</b>, or they wil  not be able to<br/>attain Android compatibility when upgraded to the future version.<br/> |
| If a device implementation meets the requirements of this section, it MAY report<br/>support for low-latency audio, by reporting the feature "android.hardware.audio.low-<br/>latency" via the android.content.pm.PackageManager class. [Re<a href="file:///usr/local/google/home/gurunagarajan/android_dev/master/vendor/android/compatibility/cdd/jb/cdd-jb.xhtml#resources37">sources, 37]<br/></a>Conversely, if the device implementation does not meet these requirements it MUST<br/>NOT report support for low-latency audio.<br/> |
| <b>5.5. Network Protocols</b><br/> |
| Devices MUST support the media network protocols for audio and video playback as<br/>specified in the Android SDK documentation [Resources, 58]. Specifical y, devices<br/>MUST support the fol owing media network proto<a href="file:///usr/local/google/home/gurunagarajan/android_dev/master/vendor/android/compatibility/cdd/jb/cdd-jb.xhtml#resources58">cols:</a><br/> |
| RTSP (RTP, SDP)<br/>HTTP(S) progressive streaming<br/>HTTP(S) Live Streaming draft protocol, Version 3 [Resources, 59]<br/> |
| <b>6. Developer Tool Compatibility</b><br/> |
| Device implementations MUST support the Android Developer Tools provided in the<br/>Android SDK. Specifical y, Android-compatible devices MUST be compatible with:<br/> |
| <b>Android Debug Bridge (known as adb)</b> [Resources, 33]<br/>Device implementations MUST support al  adb <a href="file:///usr/local/google/home/gurunagarajan/android_dev/master/vendor/android/compatibility/cdd/jb/cdd-jb.xhtml#resources33">functions as doc</a>umented in the<br/>Android SDK. The device-side adb daemon MUST be inactive by default, and<br/>there MUST be a user-accessible mechanism to turn on the Android Debug<br/>Bridge.<br/><b>Dalvik Debug Monitor Service (known as ddms)</b> [Resources, 33]<br/>Device implementations MUST support al  ddms features as documented in the<br/>Android SDK. As ddms uses adb, support for ddms SHOULD be inactive by<br/>default, but MUST be supported whenever the user has activated the Android<br/>Debug Bridge, as above.<br/><b>Monkey</b> [Resources, 36]<br/>Device implementations MUST include the Monkey framework, and make it<br/>available f<a href="file:///usr/local/google/home/gurunagarajan/android_dev/master/vendor/android/compatibility/cdd/jb/cdd-jb.xhtml#resources36">or applications to</a> use.<br/> |
| Most Linux-based systems and Apple Macintosh systems recognize Android devices<br/>using the standard Android SDK tools, without additional support; however Microsoft<br/>Windows systems typical y require a driver for new Android devices. (For instance,<br/>new vendor IDs and sometimes new device IDs require custom USB drivers for<br/>Windows systems.) If a device implementation is unrecognized by the adb tool as<br/>provided in the standard Android SDK, device implementers MUST provide Windows<br/>drivers al owing developers to connect to the device using the adb protocol. These<br/>drivers MUST be provided for Windows XP, Windows Vista, and Windows 7, in both<br/>32-bit and 64-bit versions.<br/> |
| <b>7. Hardware Compatibility</b><br/> |
| If a device includes a particular hardware component that has a corresponding API for<br/>third-party developers, the device implementation MUST implement that API as<br/>described in the Android SDK documentation. If an API in the SDK interacts with a<br/>hardware component that is stated to be optional and the device implementation does<br/>not possess that component:<br/> |
| complete class definitions (as documented by the SDK) for the component's<br/>APIs MUST stil  be present<br/>the API's behaviors MUST be implemented as no-ops in some reasonable<br/>fashion<br/>API methods MUST return nul  values where permitted by the SDK<br/>documentation<br/>API methods MUST return no-op implementations of classes where nul  values<br/>are not permitted by the SDK documentation<br/>API methods MUST NOT throw exceptions not documented by the SDK<br/>documentation<br/> |
| A typical example of a scenario where these requirements apply is the telephony API:<br/>even on non-phone devices, these APIs must be implemented as reasonable no-ops.<br/> |
| <hr/> |
| <a name=19></a>Device implementations MUST accurately report accurate hardware configuration<br/>information via the getSystemAvailableFeatures() and hasSystemFeature(String)<br/>methods on the android.content.pm.PackageManager class. [Re<a href="file:///usr/local/google/home/gurunagarajan/android_dev/master/vendor/android/compatibility/cdd/jb/cdd-jb.xhtml#resources37">sources, 37]</a><br/> |
| <b>7.1. Display and Graphics</b><br/> |
| Android 4.1 includes facilities that automatical y adjust application assets and UI<br/>layouts appropriately for the device, to ensure that third-party applications run wel  on a<br/>variety of hardware configurations [Resources, 38]. Devices MUST properly implement<br/>these APIs and behaviors, as detailed in this section.<br/> |
| The units referenced by the requirements in this section are defined as fol ows:<br/> |
| "Physical diagonal size" is the distance in inches between two opposing corners<br/>of the il uminated portion of the display.<br/>"dpi" (meaning "dots per inch") is the number of pixels encompassed by a linear<br/>horizontal or vertical span of 1". Where dpi values are listed, both horizontal and<br/>vertical dpi must fal  within the range.<br/>"Aspect ratio" is the ratio of the longer dimension of the screen to the shorter<br/>dimension. For example, a display of 480x854 pixels would be 854 / 480 =<br/>1.779, or roughly "16:9".<br/>A "density-independent pixel" or ("dp") is the virtual pixel unit normalized to a 160<br/>dpi screen, calculated as: pixels = dps * (density / 160).<br/> |
| <b>7.1.1. Screen Configuration</b><br/> |
| <b>Screen Size</b><br/> |
| The Android UI framework supports a variety of different screen sizes, and al ows<br/>applications to query the device screen size (aka "screen layout") via<br/> |
| android.content.res.Configuration.screenLayout with the<br/> |
| SCREENLAYOUT_SIZE_MASK. Device implementations MUST report the correct screen<br/> |
| size as defined in the Android SDK documentation [Resources, 38] and determined by<br/>the upstream Android platform. Specifical y, device implementations must report the<br/>correct screen size according to the fol owing logical d<a href="file:///usr/local/google/home/gurunagarajan/android_dev/master/vendor/android/compatibility/cdd/jb/cdd-jb.xhtml#resources38">ensity-independe</a>nt pixel (dp)<br/>screen dimensions.<br/> |
| Devices MUST have screen sizes of at least 426 dp x 320 dp ('smal ')<br/>Devices that report screen size 'normal' MUST have screen sizes of at least 480<br/>dp x 320 dp<br/>Devices that report screen size 'large' MUST have screen sizes of at least 640<br/>dp x 480 dp<br/>Devices that report screen size 'xlarge' MUST have screen sizes of at least 960<br/>dp x 720 dp<br/> |
| In addition, devices MUST have screen sizes of at least 2.5 inches in physical diagonal<br/>size.<br/> |
| Devices MUST NOT change their reported screen size at any time.<br/> |
| Applications optional y indicate which screen sizes they support via the <supports-<br/> |
| screens> attribute in the AndroidManifest.xml file. Device implementations MUST<br/> |
| correctly honor applications' stated support for smal , normal, large, and xlarge<br/>screens, as described in the Android SDK documentation.<br/> |
| <b>Screen Aspect Ratio</b><br/> |
| The aspect ratio MUST be between 1.3333 (4:3) and 1.85 (16:9).<br/> |
| <b>Screen Density</b><br/> |
| The Android UI framework defines a set of standard logical densities to help<br/>application developers target application resources. Device implementations MUST<br/>report one of the fol owing logical Android framework densities through the<br/> |
| android.util.DisplayMetrics APIs, and MUST execute applications at this standard<br/> |
| density.<br/> |
| 120 dpi, known as 'ldpi'<br/>160 dpi, known as 'mdpi'<br/>213 dpi, known as 'tvdpi'<br/>240 dpi, known as 'hdpi'<br/>320 dpi, known as 'xhdpi'<br/>480 dpi, known as 'xxhdpi'<br/> |
| Device implementations SHOULD define the standard Android framework density that<br/>is numerical y closest to the physical density of the screen, unless that logical density<br/> |
| <hr/> |
| <a name=20></a>is numerical y closest to the physical density of the screen, unless that logical density<br/>pushes the reported screen size below the minimum supported. If the standard Android<br/>framework density that is numerical y closest to the physical density results in a screen<br/>size that is smal er than the smal est supported compatible screen size (320 dp width),<br/>device implementations SHOULD report the next lowest standard Android framework<br/>density.<br/> |
| <b>7.1.2. Display Metrics</b><br/> |
| Device implementations MUST report correct values for al  display metrics defined in<br/> |
| android.util.DisplayMetrics [Resources, 39].<br/> |
| <b>7.1.3. Screen Orientation</b><br/> |
| Devices MUST support dynamic orientation by applications to either portrait or<br/>landscape screen orientation. That is, the device must respect the application's<br/>request for a specific screen orientation. Device implementations MAY select either<br/>portrait or landscape orientation as the default.<br/> |
| Devices MUST report the correct value for the device's current orientation, whenever<br/>queried via the android.content.res.Configuration.orientation,<br/>android.view.Display.getOrientation(), or other APIs.<br/> |
| Devices MUST NOT change the reported screen size or density when changing<br/>orientation.<br/> |
| Devices MUST report which screen orientations they support (<br/> |
| android.hardware.screen.portrait and/or android.hardware.screen.landscape)<br/> |
| and MUST report at least one supported orientation. For example, a device with a<br/>fixed-orientation landscape screen, such as a television or laptop, MUST only report<br/> |
| android.hardware.screen.landscape.<br/> |
| <b>7.1.4. 2D and 3D Graphics Acceleration</b><br/> |
| Device implementations MUST support both OpenGL ES 1.0 and 2.0, as embodied<br/>and detailed in the Android SDK documentations. Device implementations MUST also<br/>support Android Renderscript, as detailed in the Android SDK documentation<br/>[Resources, 8].<br/> |
| <a href="file:///usr/local/google/home/gurunagarajan/android_dev/master/vendor/android/compatibility/cdd/jb/cdd-jb.xhtml#resources08">Device impleme</a>ntations MUST also correctly identify themselves as supporting<br/>OpenGL ES 1.0 and 2.0. That is:<br/> |
| The managed APIs (such as via the GLES10.getString() method) MUST report<br/>support for OpenGL ES 1.0 and 2.0<br/>The native C/C++ OpenGL APIs (that is, those available to apps via<br/>libGLES_v1CM.so, libGLES_v2.so, or libEGL.so) MUST report support for<br/>OpenGL ES 1.0 and 2.0.<br/> |
| Device implementations MAY implement any desired OpenGL ES extensions.<br/>However, device implementations MUST report via the OpenGL ES managed and<br/>native APIs al  extension strings that they do support, and conversely MUST NOT report<br/>extension strings that they do not support.<br/> |
| Note that Android 4.1 includes support for applications to optional y specify that they<br/>require specific OpenGL texture compression formats. These formats are typical y<br/>vendor-specific. Device implementations are not required by Android 4.1 to implement<br/>any specific texture compression format. However, they SHOULD accurately report any<br/>texture compression formats that they do support, via the getString() method in the<br/>OpenGL API.<br/> |
| Android 4.1 includes a mechanism for applications to declare that they wanted to<br/>enable hardware acceleration for 2D graphics at the Application, Activity, Window or<br/>View level through the use of a manifest tag android:hardwareAccelerated or direct<br/>API cal s [Resources, 9].<br/> |
| In Android 4.1, device implementations MUST enable hardware acceleration by<br/>default, and MUST disable hardware acceleration if the developer so requests by<br/>setting android:hardwareAccelerated="false" or disabling hardware acceleration<br/>directly through the Android View APIs.<br/> |
| In addition, device implementations MUST exhibit behavior consistent with the Android<br/>SDK documentation on hardware acceleration [Resources, 9].<br/> |
| Android 4.1 includes a TextureView object that lets developers directly integrate<br/>hardware-accelerated OpenGL ES textures as rendering targets in a UI hierarchy.<br/>Device implementations MUST support the Textur<a href="file:///usr/local/google/home/gurunagarajan/android_dev/master/vendor/android/compatibility/cdd/jb/cdd-jb.xhtml#resources09">eView API, and</a> MUST exhibit<br/> |
| <hr/> |
| <a name=21></a>consistent behavior with the upstream Android implementation.<br/> |
| <b>7.1.5. Legacy Application Compatibility Mode</b><br/> |
| Android 4.1 specifies a "compatibility mode" in which the framework operates in an<br/>'normal' screen size equivalent (320dp width) mode for the benefit of legacy<br/>applications not developed for old versions of Android that pre-date screen-size<br/>independence. Device implementations MUST include support for legacy application<br/>compatibility mode as implemented by the upstream Android open source code. That<br/>is, device implementations MUST NOT alter the triggers or thresholds at which<br/>compatibility mode is activated, and MUST NOT alter the behavior of the compatibility<br/>mode itself.<br/> |
| <b>7.1.6. Screen Types</b><br/> |
| Device implementation screens are classified as one of two types:<br/> |
| Fixed-pixel display implementations: the screen is a single panel that supports<br/>only a single pixel width and height. Typical y the screen is physical y integrated<br/>with the device. Examples include mobile phones, tablets, and so on.<br/>Variable-pixel display implementations: the device implementation either has no<br/>embedded screen and includes a video output port such as VGA, HDMI or a<br/>wireless port for display, or has an embedded screen that can change pixel<br/>dimensions. Examples include televisions, set-top boxes, and so on.<br/> |
| <b>Fixed-Pixel Device Implementations</b><br/> |
| Fixed-pixel device implementations MAY use screens of any pixel dimensions,<br/>provided that they meet the requirements defined this Compatibility Definition.<br/> |
| Fixed-pixel implementations MAY include a video output port for use with an external<br/>display. However, if that display is ever used for running apps, the device MUST meet<br/>the fol owing requirements:<br/> |
| The device MUST report the same screen configuration and display metrics, as<br/>detailed in Sections 7.1.1 and 7.1.2, as the fixed-pixel display.<br/>The device MUST report the same logical density as the fixed-pixel display.<br/>The device MUST report screen dimensions that are the same as, or very close<br/>to, the fixed-pixel display.<br/> |
| For example, a tablet that is 7" diagonal size with a 1024x600 pixel resolution is<br/>considered a fixed-pixel large mdpi display implementation. If it contains a video<br/>output port that displays at 720p or 1080p, the device implementation MUST scale the<br/>output so that applications are only executed in a large mdpi window, regardless of<br/>whether the fixed-pixel display or video output port is in use.<br/> |
| <b>Variable-Pixel Device Implementations</b><br/> |
| Variable-pixel device implementations MUST support one or both of 1280x720, or<br/>1920x1080 (that is, 720p or 1080p). Device implementations with variable-pixel<br/>displays MUST NOT support any other screen configuration or mode. Device<br/>implementations with variable-pixel screens MAY change screen configuration or<br/>mode at runtime or boot-time. For example, a user of a set-top box may replace a<br/>720p display with a 1080p display, and the device implementation may adjust<br/>accordingly.<br/> |
| Additional y, variable-pixel device implementations MUST report the fol owing<br/>configuration buckets for these pixel dimensions:<br/> |
| 1280x720 (also known as 720p): 'large' screen size, 'tvdpi' (213 dpi) density<br/>1920x1080 (also known as 1080p): 'large' screen size, 'xhdpi' (320 dpi) density<br/> |
| For clarity, device implementations with variable pixel dimensions are restricted to<br/>720p or 1080p in Android 4.1, and MUST be configured to report screen size and<br/>density buckets as noted above.<br/> |
| <b>7.1.7. Screen Technology</b><br/> |
| The Android platform includes APIs that al ow applications to render rich graphics to<br/>the display. Devices MUST support al  of these APIs as defined by the Android SDK<br/>unless specifical y al owed in this document. Specifical y:<br/> |
| Devices MUST support displays capable of rendering 16-bit color graphics and<br/>SHOULD support displays capable of 24-bit color graphics.<br/>Devices MUST support displays capable of rendering animations.<br/>The display technology used MUST have a pixel aspect ratio (PAR) between 0.9<br/> |
| <hr/> |
| <a name=22></a>and 1.1. That is, the pixel aspect ratio MUST be near square (1.0) with a 10%<br/>tolerance.<br/> |
| <b>7.2. Input Devices</b><br/> |
| <b>7.2.1. Keyboard</b><br/> |
| Device implementations:<br/> |
| MUST include support for the Input Management Framework (which al ows third<br/>party developers to create Input Management Engines - i.e. soft keyboard) as<br/>detailed at http://developer.android.com<br/>MUST provide at least one soft keyboard implementation (regardless of whether<br/>a hard keyboard is present)<br/>MAY include additional soft keyboard implementations<br/>MAY include a hardware keyboard<br/>MUST NOT include a hardware keyboard that does not match one of the formats<br/>specified in android.content.res.Configuration.keyboard [Resources, 40]<br/>(that is, QWERTY, or 12-key)<br/> |
| <b>7.2.2. Non-touch Navigation</b><br/> |
| Device implementations:<br/> |
| MAY omit a non-touch navigation option (that is, may omit a trackbal , d-pad, or<br/>wheel)<br/>MUST report the correct value for<br/> |
| android.content.res.Configuration.navigation [Resources, 40]<br/> |
| MUST provide a reasonable alternative user interface m<a href="file:///usr/local/google/home/gurunagarajan/android_dev/master/vendor/android/compatibility/cdd/jb/cdd-jb.xhtml#resources40">echanism for the<br/></a>selection and editing of text, compatible with Input Management Engines. The<br/>upstream Android open source software includes a selection mechanism<br/>suitable for use with devices that lack non-touch navigation inputs.<br/> |
| <b>7.2.3. Navigation keys</b><br/> |
| The Home, Menu and Back functions are essential to the Android navigation<br/>paradigm. Device implementations MUST make these functions available to the user<br/>at al  times when running applications. These functions MAY be implemented via<br/>dedicated physical buttons (such as mechanical or capacitive touch buttons), or MAY<br/>be implemented using dedicated software keys, gestures, touch panel, etc. Android<br/>4.1 supports both implementations.<br/> |
| Android 4.1 introduces support for assist action [Resources, 63]. Device<br/>implementations MUST make the assist action available to the user at al  times when<br/>running applications. This function MAY be impleme<a href="file:///usr/local/google/home/gurunagarajan/android_dev/master/vendor/android/compatibility/cdd/jb/cdd-jb.xhtml#resources63">nted via hardwa</a>re or software<br/>keys.<br/> |
| Device implementations MAY use a distinct portion of the screen to display the<br/>navigation keys, but if so, MUST meet these requirements:<br/> |
| Device implementation navigation keys MUST use a distinct portion of the<br/>screen, not available to applications, and MUST NOT obscure or otherwise<br/>interfere with the portion of the screen available to applications.<br/>Device implementations MUST make available a portion of the display to<br/>applications that meets the requirements defined in Section 7.1.1.<br/>Device implementations MUST display the navigation keys when applications do<br/>not specify a system UI mode, or specify SYSTEM_UI_FLAG_VISIBLE.<br/>Device implementations MUST present the navigation <a href="file:///usr/local/google/home/gurunagarajan/android_dev/master/vendor/android/compatibility/cdd/jb/section-7.1.1">keys in an unob</a>trusive<br/>"low profile" (eg. dimmed) mode when applications specify<br/> |
| SYSTEM_UI_FLAG_LOW_PROFILE.<br/> |
| Device implementations MUST hide the navigation keys when applications<br/>specify SYSTEM_UI_FLAG_HIDE_NAVIGATION.<br/>Device implementation MUST present a Menu key to applications when<br/>targetSdkVersion <= 10 and SHOULD NOT present a Menu key when the<br/>targetSdkVersion > 10.<br/>Device implementations MUST make available a portion of the display to<br/>applications that meets the requirements defined in Section 7.1.1.<br/> |
| <b>7.2.4. Touchscreen input</b><br/> |
| Device implementations SHOULD have a pointer input syste<a href="file:///usr/local/google/home/gurunagarajan/android_dev/master/vendor/android/compatibility/cdd/jb/section-7.1.1">m of some kind</a> (either<br/>mouse-like, or touch). However, if a device implementation does not support a pointer<br/>input system, it MUST NOT report the android.hardware.touchscreen or<br/> |
| android.hardware.faketouch feature constant. Device implementations that do<br/> |
| <hr/> |
| <a name=23></a>include a pointer input system:<br/> |
| SHOULD support ful y independently tracked pointers, if the device input system<br/>supports multiple pointers<br/>MUST report the value of android.content.res.Configuration.touchscreen<br/>[<a href="file:///usr/local/google/home/gurunagarajan/android_dev/master/vendor/android/compatibility/cdd/jb/cdd-jb.xhtml#resources40">Resources, 40] c</a>orresponding to the type of the specific touchscreen on the<br/>device<br/> |
| Android 4.0 includes support for a variety of touch screens, touch pads, and fake touch<br/>input devices. Touch screen based device implementations are associated with a<br/>display [Resources, 71] such that the user has the impression of directly manipulating<br/>items on screen. Since the user is directly touching the screen, the system does not<br/>require any additional affordances to indicate the objects being manipulated. In<br/>contrast, a fake touch interface provides a user input system that approximates a<br/>subset of touchscreen capabilities. For example, a mouse or remote control that drives<br/>an on-screen cursor approximates touch, but requires the user to first point or focus<br/>then click. Numerous input devices like the mouse, trackpad, gyro-based air mouse,<br/>gyro-pointer, joystick, and multi-touch trackpad can support fake touch interactions.<br/>Android 4.0 includes the feature constant android.hardware.faketouch, which<br/>corresponds to a high-fidelity non-touch (that is, pointer-based) input device such as a<br/>mouse or trackpad that can adequately emulate touch-based input (including basic<br/>gesture support), and indicates that the device supports an emulated subset of<br/>touchscreen functionality. Device implementations that declare the fake touch feature<br/>MUST meet the fake touch requirements in Section 7.2.5.<br/> |
| Device implementations MUST report the correct feature corresponding to the type of<br/>input used. Device implementations that include a touchscreen (single-touch or better)<br/>MUST report the platform feature constant android.hardware.touchscreen. Device<br/>implementations that report the platform feature constant<br/> |
| android.hardware.touchscreen MUST also report the platform feature constant<br/> |
| android.hardware.faketouch. Device implementations that do not include a<br/> |
| touchscreen (and rely on a pointer device only) MUST NOT report any touchscreen<br/>feature, and MUST report only android.hardware.faketouch if they meet the fake<br/>touch requirements in Section 7.2.5.<br/> |
| <b>7.2.5. Fake touch inp<a href="file:///usr/local/google/home/gurunagarajan/android_dev/master/vendor/android/compatibility/cdd/jb/section 7.2.5">ut</a></b><br/> |
| Device implementations that declare support for android.hardware.faketouch<br/> |
| MUST report the absolute X and Y screen positions of the pointer location and<br/>display a visual pointer on the screen[Resources, 70]<br/>MUST report touch event with the action code [Resources, 70] that specifies the<br/>state change that occurs on the pointer g<a href="file:///usr/local/google/home/gurunagarajan/android_dev/master/vendor/android/compatibility/cdd/jb/cdd-jb.xhtml#resources70">oing down or up </a>on the screen<br/>[Resources, 70]<br/>MUST support pointer down and up on an object on the screen, which al ows<br/>u<a href="file:///usr/local/google/home/gurunagarajan/android_dev/master/vendor/android/compatibility/cdd/jb/cdd-jb.xhtml#resources70">sers to emulate </a>tap on an object on the screen<br/>MUST support pointer down, pointer up, pointer down then pointer up in the same<br/>place on an object on the screen within a time threshold, which al ows users to<br/>emulate double tap on an object on the screen [Resources, 70]<br/>MUST support pointer down on an arbitrary point on the screen, pointer move to<br/>any other arbitrary point on the screen, fol owed by a pointer <a href="file:///usr/local/google/home/gurunagarajan/android_dev/master/vendor/android/compatibility/cdd/jb/cdd-jb.xhtml#resources70">up</a>, which al ows<br/>users to emulate a touch drag<br/>MUST support pointer down then al ow users to quickly move the object to a<br/>different position on the screen and then pointer up on the screen, which al ows<br/>users to fling an object on the screen<br/> |
| Devices that declare support for android.hardware.faketouch.multitouch.distinct<br/>MUST meet the requirements for faketouch above, and MUST also support distinct<br/>tracking of two or more independent pointer inputs.<br/> |
| <b>7.2.6. Microphone</b><br/> |
| Device implementations MAY omit a microphone. However, if a device implementation<br/>omits a microphone, it MUST NOT report the android.hardware.microphone feature<br/>constant, and must implement the audio recording API as no-ops, per Section 7.<br/>Conversely, device implementations that do possess a microphone:<br/> |
| MUST report the android.hardware.microphone feature constant<br/>SHOULD meet the audio quality requirements in Section 5.4<br/>SHOULD meet the audio latency requirements in Section 5.5<br/> |
| <b>7.3. Sensors</b><br/> |
| <hr/> |
| <a name=24></a>Android 4.1 includes APIs for accessing a variety of sensor types. Devices<br/>implementations general y MAY omit these sensors, as provided for in the fol owing<br/>subsections. If a device includes a particular sensor type that has a corresponding API<br/>for third-party developers, the device implementation MUST implement that API as<br/>described in the Android SDK documentation. For example, device implementations:<br/> |
| MUST accurately report the presence or absence of sensors per the<br/> |
| android.content.pm.PackageManager class. [Re<a href="file:///usr/local/google/home/gurunagarajan/android_dev/master/vendor/android/compatibility/cdd/jb/cdd-jb.xhtml#resources37">sources, 37]</a><br/> |
| MUST return an accurate list of supported sensors via the<br/> |
| SensorManager.getSensorList() and similar methods<br/> |
| MUST behave reasonably for al  other sensor APIs (for example, by returning true<br/>or false as appropriate when applications attempt to register listeners, not cal ing<br/>sensor listeners when the corresponding sensors are not present; etc.)<br/>MUST report al  sensor measurements using the relevant International System of<br/>Units (i.e. metric) values for each sensor type as defined in the Android SDK<br/>documentation [Resources, 41]<br/> |
| The list above is not comprehensive; the documented behavior of the Android SDK is<br/>to be considered authoritative.<br/> |
| Some sensor types are synthetic, meaning they can be derived from data provided by<br/>one or more other sensors. (Examples include the orientation sensor, and the linear<br/>acceleration sensor.) Device implementations SHOULD implement these sensor<br/>types, when they include the prerequisite physical sensors.<br/> |
| The Android 4.1 APIs introduce a notion of a "streaming" sensor, which is one that<br/>returns data continuously, rather than only when the data changes. Device<br/>implementations MUST continuously provide periodic data samples for any API<br/>indicated by the Android 4.1 SDK documentation to be a streaming sensor.<br/> |
| <b>7.3.1. Accelerometer</b><br/> |
| Device implementations SHOULD include a 3-axis accelerometer. If a device<br/>implementation does include a 3-axis accelerometer, it:<br/> |
| SHOULD be able to deliver events at 120 Hz or greater. Note that while the<br/>accelerometer frequency above is stated as "SHOULD" for Android 4.1, the<br/>Compatibility Definition for a future version is planned to change these to<br/>"MUST". That is, these standards are optional in Android 4.1 but <b>will be<br/>required</b> in future versions. Existing and new devices that run Android 4.1 are<br/><b>very strongly encouraged to meet these requirements in Android 4.1 </b> so<br/>they wil  be able to upgrade to the future platform releases<br/>MUST comply with the Android sensor coordinate system as detailed in the<br/>Android APIs (see [Resources, 41])<br/>MUST be capable of measuring from freefal  up to twice gravity (2g) or more on<br/>any three-dimension<a href="file:///usr/local/google/home/gurunagarajan/android_dev/master/vendor/android/compatibility/cdd/jb/cdd-jb.xhtml#resources41">al vector<br/></a>MUST have 8-bits of accuracy or more<br/>MUST have a standard deviation no greater than 0.05 m/s^2<br/> |
| <b>7.3.2. Magnetometer</b><br/> |
| Device implementations SHOULD include a 3-axis magnetometer (i.e. compass.) If a<br/>device does include a 3-axis magnetometer, it:<br/> |
| MUST be able to deliver events at 10 Hz or greater<br/>MUST comply with the Android sensor coordinate system as detailed in the<br/>Android APIs (see [Resources, 41]).<br/>MUST be capable of sampling a range of field strengths adequate to cover the<br/>geomagnetic field<br/>MUST have 8-bits of <a href="file:///usr/local/google/home/gurunagarajan/android_dev/master/vendor/android/compatibility/cdd/jb/cdd-jb.xhtml#resources41">accuracy or mor</a>e<br/>MUST have a standard deviation no greater than 0.5 µT<br/> |
| <b>7.3.3. GPS</b><br/> |
| Device implementations SHOULD include a GPS receiver. If a device implementation<br/>does include a GPS receiver, it SHOULD include some form of "assisted GPS"<br/>technique to minimize GPS lock-on time.<br/> |
| <b>7.3.4. Gyroscope</b><br/> |
| Device implementations SHOULD include a gyroscope (i.e. angular change sensor.)<br/>Devices SHOULD NOT include a gyroscope sensor unless a 3-axis accelerometer is<br/>also included. If a device implementation includes a gyroscope, it:<br/> |
| <hr/> |
| <a name=25></a>MUST be temperature compensated<br/>MUST be capable of measuring orientation changes up to 5.5*Pi<br/>radians/second (that is, approximately 1,000 degrees per second)<br/>SHOULD be able to deliver events at 200 Hz or greater. Note that while the<br/>gyroscope frequency above is stated as "SHOULD" for Android 4.1, the<br/>Compatibility Definition for a future version is planned to change these to<br/>"MUST". That is, these standards are optional in Android 4.1 but <b>will be<br/>required</b> in future versions. Existing and new devices that run Android 4.1 are<br/><b>very strongly encouraged to meet these requirements in Android 4.1 </b> so<br/>they wil  be able to upgrade to the future platform releases<br/>MUST have 12-bits of accuracy or more<br/>MUST have a variance no greater than 1e-7 rad^2 / s^2 per Hz (variance per Hz,<br/>or rad^2 / s). The variance is al owed to vary with the sampling rate, but must be<br/>constrained by this value. In other words, if you measure the variance of the gyro<br/>at 1 Hz sampling rate it should be no greater than 1e-7 rad^2/s^2.<br/>MUST have timestamps as close to when the hardware event happened as<br/>possible. The constant latency must be removed.<br/> |
| <b>7.3.5. Barometer</b><br/> |
| Device implementations MAY include a barometer (i.e. ambient air pressure sensor.) If<br/>a device implementation includes a barometer, it:<br/> |
| MUST be able to deliver events at 5 Hz or greater<br/>MUST have adequate precision to enable estimating altitude<br/>MUST be temperature compensated<br/> |
| <b>7.3.7. Thermometer</b><br/> |
| Device implementations MAY but SHOULD NOT include a thermometer (i.e.<br/>temperature sensor.) If a device implementation does include a thermometer, it MUST<br/>measure the temperature of the device CPU. It MUST NOT measure any other<br/>temperature. (Note that this sensor type is deprecated in the Android 4.1 APIs.)<br/> |
| <b>7.3.7. Photometer</b><br/> |
| Device implementations MAY include a photometer (i.e. ambient light sensor.)<br/> |
| <b>7.3.8. Proximity Sensor</b><br/> |
| Device implementations MAY include a proximity sensor. If a device implementation<br/>does include a proximity sensor, it MUST measure the proximity of an object in the<br/>same direction as the screen. That is, the proximity sensor MUST be oriented to detect<br/>objects close to the screen, as the primary intent of this sensor type is to detect a<br/>phone in use by the user. If a device implementation includes a proximity sensor with<br/>any other orientation, it MUST NOT be accessible through this API. If a device<br/>implementation has a proximity sensor, it MUST be have 1-bit of accuracy or more.<br/> |
| <b>7.4. Data Connectivity</b><br/> |
| <b>7.4.1. Telephony</b><br/> |
| "Telephony" as used by the Android 4.1 APIs and this document refers specifical y to<br/>hardware related to placing voice cal s and sending SMS messages via a GSM or<br/>CDMA network. While these voice cal s may or may not be packet-switched, they are<br/>for the purposes of Android 4.1 considered independent of any data connectivity that<br/>may be implemented using the same network. In other words, the Android "telephony"<br/>functionality and APIs refer specifical y to voice cal s and SMS; for instance, device<br/>implementations that cannot place cal s or send/receive SMS messages MUST NOT<br/>report the "android.hardware.telephony" feature or any sub-features, regardless of<br/>whether they use a cel ular network for data connectivity.<br/> |
| Android 4.1 MAY be used on devices that do not include telephony hardware. That is,<br/>Android 4.1 is compatible with devices that are not phones. However, if a device<br/>implementation does include GSM or CDMA telephony, it MUST implement ful  support<br/>for the API for that technology. Device implementations that do not include telephony<br/>hardware MUST implement the ful  APIs as no-ops.<br/> |
| <b>7.4.2. IEEE 802.11 (WiFi)</b><br/> |
| Android 4.1 device implementations SHOULD include support for one or more forms<br/>of 802.11 (b/g/a/n, etc.) If a device implementation does include support for 802.11, it<br/>MUST implement the corresponding Android API.<br/> |
| <hr/> |
| <a name=26></a>Device implementations MUST implement the multicast API as described in the SDK<br/>documentation [<a href="file:///usr/local/google/home/gurunagarajan/android_dev/master/vendor/android/compatibility/cdd/jb/cdd-jb.xhtml#resources62">Resources, 62]. D</a>evice implementations that do include Wifi support<br/>MUST support multicast DNS (mDNS). Device implementations MUST not filter mDNS<br/>packets (224.0.0.251) at any time of operation including when the screen is not in an<br/>active state.<br/> |
| <b>7.4.2.1. WiFi Direct</b><br/> |
| Device implementations SHOULD include support for Wifi direct (Wifi peer-to-peer). If<br/>a device implementation does include support for Wifi direct, it MUST implement the<br/>corresponding Android API as described in the SDK documentation [Resources, 68]. If<br/>a device implementation includes support for Wifi direct, then it:<br/> |
| MUST support regular Wifi operation<br/>SHOULD support concurrent wifi and wifi Direct operation<br/> |
| <b>7.4.3. Bluetooth</b><br/> |
| Device implementations SHOULD include a Bluetooth transceiver. Device<br/>implementations that do include a Bluetooth transceiver MUST enable the RFCOMM-<br/>based Bluetooth API as described in the SDK documentation [Resources, 42]. Device<br/>implementations SHOULD implement relevant Bluetooth profiles, <a href="file:///usr/local/google/home/gurunagarajan/android_dev/master/vendor/android/compatibility/cdd/jb/cdd-jb.xhtml#resources42">such as A2DP,<br/></a>AVRCP, OBEX, etc. as appropriate for the device.<br/> |
| The Compatibility Test Suite includes cases that cover basic operation of the Android<br/>RFCOMM Bluetooth API. However, since Bluetooth is a communications protocol<br/>between devices, it cannot be ful y tested by unit tests running on a single device.<br/>Consequently, device implementations MUST also pass the human-driven Bluetooth<br/>test procedure described in Appendix A.<br/> |
| <b>7.4.4. Near-Field Communications</b><br/> |
| Device implementations SHOULD include a transceiver and related hardware for<br/>Near-Field Communications (NFC). If a device implementation does include NFC<br/>hardware, then it:<br/> |
| MUST report the android.hardware.nfc feature from the<br/> |
| android.content.pm.PackageManager.hasSystemFeature() method.<br/> |
| [Resources, 37]<br/>MUST be capable of reading and writing NDEF messages via the fol owing NFC<br/>s<a href="file:///usr/local/google/home/gurunagarajan/android_dev/master/vendor/android/compatibility/cdd/jb/cdd-jb.xhtml#resources37">tandards:</a><br/> |
| MUST be capable of acting as an NFC Forum reader/writer (as defined by<br/>the NFC Forum technical specification NFCForum-TS-DigitalProtocol-1.0)<br/>via the fol owing NFC standards:<br/> |
| NfcA (ISO14443-3A)<br/>NfcB (ISO14443-3B)<br/>NfcF (JIS 6319-4)<br/>IsoDep (ISO 14443-4)<br/>NFC Forum Tag Types 1, 2, 3, 4 (defined by the NFC Forum)<br/> |
| SHOULD be capable of reading and writing NDEF messages via the fol owing<br/>NFC standards. Note that while the NFC standards below are stated as<br/>"SHOULD" for Android 4.1, the Compatibility Definition for a future version is<br/>planned to change these to "MUST". That is, these standards are optional in<br/>Android 4.1 but <b>will be required</b> in future versions. Existing and new devices<br/>that run Android 4.1 are <b>very strongly encouraged to meet these<br/>requirements in Android 4.1</b> so they wil  be able to upgrade to the future<br/>platform releases.<br/> |
| NfcV (ISO 15693)<br/> |
| MUST be capable of transmitting and receiving data via the fol owing peer-to-<br/>peer standards and protocols:<br/> |
| ISO 18092<br/>LLCP 1.0 (defined by the NFC Forum)<br/>SDP 1.0 (defined by the NFC Forum)<br/>NDEF Push Protocol [Resources, 43]<br/>SNEP 1.0 (defined by the NFC Forum)<br/> |
| MUST include support for Android Beam [Resources, 65]:<br/> |
| MUST implement the S<a href="file:///usr/local/google/home/gurunagarajan/android_dev/master/vendor/android/compatibility/cdd/jb/cdd-jb.xhtml#resources43">NEP default serv</a>er. Valid NDEF messages<br/>received by the default SNEP server MUST be dispatched to applications<br/>using the android.nfc.ACTION_NDEF_DISCOVERED intent. Disabling<br/>Android Beam in settings MUST NOT disable dispatch of incoming NDEF<br/>message.<br/>Device implementations MUST honor the<br/>android.settings.NFCSHARING_SETTINGS intent to show NFC sharing<br/> |
| <hr/> |
| <a name=27></a>settings [R<a href="file:///usr/local/google/home/gurunagarajan/android_dev/master/vendor/android/compatibility/cdd/jb/cdd-jb.xhtml#resources67">esources, 67].<br/></a>MUST implement the NPP server. Messages received by the NPP server<br/>MUST be processed the same way as the SNEP default server.<br/>MUST implement a SNEP client and attempt to send outbound P2P NDEF<br/>to the default SNEP server when Android Beam is enabled. If no default<br/>SNEP server is found then the client MUST attempt to send to an NPP<br/>server.<br/>MUST al ow foreground activities to set the outbound P2P NDEF message<br/>using android.nfc.NfcAdapter.setNdefPushMessage, and<br/>android.nfc.NfcAdapter.setNdefPushMessageCal back, and<br/>android.nfc.NfcAdapter.enableForegroundNdefPush.<br/>SHOULD use a gesture or on-screen confirmation, such as 'Touch to<br/>Beam', before sending outbound P2P NDEF messages.<br/>SHOULD enable Android Beam by default<br/>MUST support NFC Connection handover to Bluetooth when the device<br/>supports Bluetooth Object Push Profile. Device implementations must<br/>support connection handover to Bluetooth when using<br/>android.nfc.NfcAdapter.setBeamPushUris, by implementing the<br/>"Connection Handover version 1.2" [Resources, 60] and "Bluetooth Secure<br/>Simple Pairing Using NFC version 1.0"<a href="file:///usr/local/google/home/gurunagarajan/android_dev/master/vendor/android/compatibility/cdd/jb/cdd-jb.xhtml#resources60"> [Resources, 61</a>] specs from the<br/>NFC Forum. Such an implementation SHO<a href="file:///usr/local/google/home/gurunagarajan/android_dev/master/vendor/android/compatibility/cdd/jb/cdd-jb.xhtml#resources61">ULD use SNEP G</a>ET requests<br/>for exchanging the handover request / select records over NFC, and it<br/>MUST use the Bluetooth Object Push Profile for the actual Bluetooth data<br/>transfer.<br/> |
| MUST pol  for al  supported technologies while in NFC discovery mode.<br/>SHOULD be in NFC discovery mode while the device is awake with the screen<br/>active and the lock-screen unlocked.<br/> |
| (Note that publicly available links are not available for the JIS, ISO, and NFC Forum<br/>specifications cited above.)<br/> |
| Additional y, device implementations MAY include reader/writer support for the<br/>fol owing MIFARE technologies.<br/> |
| MIFARE Classic (NXP MF1S503x [Resources, 44], MF1S703x [Resources, 44])<br/>MIFARE Ultralight (NXP MF0ICU1 [Resources, 46], MF0ICU2 [Resources, 46])<br/>NDEF on MIFARE Classic (NXP AN1<a href="file:///usr/local/google/home/gurunagarajan/android_dev/master/vendor/android/compatibility/cdd/jb/cdd-jb.xhtml#resources44">30511 [Resourc</a>es, 48], AN13<a href="file:///usr/local/google/home/gurunagarajan/android_dev/master/vendor/android/compatibility/cdd/jb/cdd-jb.xhtml#resources44">0411<br/></a>[Resources, 49])<br/> |
| Note th<a href="file:///usr/local/google/home/gurunagarajan/android_dev/master/vendor/android/compatibility/cdd/jb/cdd-jb.xhtml#resources49">at Android 4.1 in</a>cludes APIs for these MIFARE types. If a device<br/>implementation supports MIFARE in the reader/writer role, it:<br/> |
| MUST implement the corresponding Android APIs as documented by the<br/>Android SDK<br/>MUST report the feature com.nxp.mifare from the<br/> |
| android.content.pm.PackageManager.hasSystemFeature() method.<br/> |
| [Resources, 37] Note that this is not a standard Android feature, and as such<br/>does not appear as a constant on the PackageManager class.<br/><a href="file:///usr/local/google/home/gurunagarajan/android_dev/master/vendor/android/compatibility/cdd/jb/cdd-jb.xhtml#resources37">MUST NOT imple</a>ment the corresponding Android APIs nor report the<br/>com.nxp.mifare feature unless it also implements general NFC support as<br/>described in this section<br/> |
| If a device implementation does not include NFC hardware, it MUST NOT declare the<br/>android.hardware.nfc feature from the<br/> |
| android.content.pm.PackageManager.hasSystemFeature() method [Resources, 37],<br/> |
| and MUST implement the Android 4.1 NFC API as a no-op.<br/> |
| As the classes android.nfc.NdefMessage and android.nfc.NdefRecord r<a href="file:///usr/local/google/home/gurunagarajan/android_dev/master/vendor/android/compatibility/cdd/jb/cdd-jb.xhtml#resources37">epresent a<br/></a>protocol-independent data representation format, device implementations MUST<br/>implement these APIs even if they do not include support for NFC or declare the<br/>android.hardware.nfc feature.<br/> |
| <b>7.4.5. Minimum Network Capability</b><br/> |
| Device implementations MUST include support for one or more forms of data<br/>networking. Specifical y, device implementations MUST include support for at least one<br/>data standard capable of 200Kbit/sec or greater. Examples of technologies that<br/>satisfy this requirement include EDGE, HSPA, EV-DO, 802.11g, Ethernet, etc.<br/> |
| Device implementations where a physical networking standard (such as Ethernet) is<br/>the primary data connection SHOULD also include support for at least one common<br/>wireless data standard, such as 802.11 (WiFi).<br/> |
| Devices MAY implement more than one form of data connectivity.<br/> |
| <hr/> |
| <a name=28></a><b>7.5. Cameras</b><br/> |
| Device implementations SHOULD include a rear-facing camera, and MAY include a<br/>front-facing camera. A rear-facing camera is a camera located on the side of the<br/>device opposite the display; that is, it images scenes on the far side of the device, like<br/>a traditional camera. A front-facing camera is a camera located on the same side of<br/>the device as the display; that is, a camera typical y used to image the user, such as for<br/>video conferencing and similar applications.<br/> |
| <b>7.5.1. Rear-Facing Camera</b><br/> |
| Device implementations SHOULD include a rear-facing camera. If a device<br/>implementation includes a rear-facing camera, it:<br/> |
| MUST have a resolution of at least 2 megapixels<br/>SHOULD have either hardware auto-focus, or software auto-focus implemented<br/>in the camera driver (transparent to application software)<br/>MAY have fixed-focus or EDOF (extended depth of field) hardware<br/>MAY include a flash. If the Camera includes a flash, the flash lamp MUST NOT be<br/>lit while an android.hardware.Camera.PreviewCal back instance has been<br/>registered on a Camera preview surface, unless the application has explicitly<br/>enabled the flash by enabling the FLASH_MODE_AUTO or FLASH_MODE_ON attributes<br/>of a Camera.Parameters object. Note that this constraint does not apply to the<br/>device's built-in system camera application, but only to third-party applications<br/>using Camera.PreviewCallback.<br/> |
| <b>7.5.2. Front-Facing Camera</b><br/> |
| Device implementations MAY include a front-facing camera. If a device implementation<br/>includes a front-facing camera, it:<br/> |
| MUST have a resolution of at least VGA (that is, 640x480 pixels)<br/>MUST NOT use a front-facing camera as the default for the Camera API. That is,<br/>the camera API in Android 4.1 has specific support for front-facing cameras, and<br/>device implementations MUST NOT configure the API to to treat a front-facing<br/>camera as the default rear-facing camera, even if it is the only camera on the<br/>device.<br/>MAY include features (such as auto-focus, flash, etc.) available to rear-facing<br/>cameras as described in Section 7.5.1.<br/>MUST horizontal y reflect (i.e. mirror) the stream displayed by an app in a<br/>CameraPreview, as fol ows:<br/> |
| If the device implementation is capable of being rotated by user (such as<br/>automatical y via an accelerometer or manual y via user input), the camera<br/>preview MUST be mirrored horizontal y relative to the device's current<br/>orientation.<br/>If the current application has explicitly requested that the Camera display<br/>be rotated via a cal  to the<br/> |
| android.hardware.Camera.setDisplayOrientation() [Resources, 50]<br/> |
| method, the camera preview MUST be mirrored horizontal y relative to the<br/>orientation specified by the application.<br/>Otherwise, the preview MUST be mirrored along the device's default<br/>horizontal axis.<br/> |
| MUST mirror the image displayed by the postview in the same manner as the<br/>camera preview image stream. (If the device implementation does not support<br/>postview, this requirement obviously does not apply.)<br/>MUST NOT mirror the final captured stil  image or video streams returned to<br/>application cal backs or committed to media storage<br/> |
| <b>7.5.3. Camera API Behavior</b><br/> |
| Device implementations MUST implement the fol owing behaviors for the camera-<br/>related APIs, for both front- and rear-facing cameras:<br/> |
| 1.  If an application has never cal ed<br/> |
| android.hardware.Camera.Parameters.setPreviewFormat(int), then the<br/> |
| device MUST use android.hardware.PixelFormat.YCbCr_420_SP for preview<br/>data provided to application cal backs.<br/> |
| 2.  If an application registers an android.hardware.Camera.PreviewCallback<br/> |
| instance and the system cal s the onPreviewFrame() method when the preview<br/>format is YCbCr_420_SP, the data in the byte[] passed into onPreviewFrame()<br/>must further be in the NV21 encoding format. That is, NV21 MUST be the default.<br/> |
| 3.  Device implementations MUST support the YV12 format (as denoted by the<br/> |
| <hr/> |
| <a name=29></a>android.graphics.ImageFormat.YV12 constant) for camera previews for both<br/> |
| front- and rear-facing cameras. (The hardware video decoder and camera may<br/>use any native pixel format, but the device implementation MUST support<br/>conversion to YV12.)<br/> |
| Device implementations MUST implement the ful  Camera API included in the Android<br/>4.1 SDK documentation [R<a href="file:///usr/local/google/home/gurunagarajan/android_dev/master/vendor/android/compatibility/cdd/jb/cdd-jb.xhtml#resources51">esources, 51]), r</a>egardless of whether the device includes<br/>hardware autofocus or other capabilities. For instance, cameras that lack autofocus<br/>MUST stil  cal  any registered android.hardware.Camera.AutoFocusCallback<br/>instances (even though this has no relevance to a non-autofocus camera.) Note that<br/>this does apply to front-facing cameras; for instance, even though most front-facing<br/>cameras do not support autofocus, the API cal backs must stil  be "faked" as<br/>described.<br/> |
| Device implementations MUST recognize and honor each parameter name defined as<br/>a constant on the android.hardware.Camera.Parameters class, if the underlying<br/>hardware supports the feature. If the device hardware does not support a feature, the<br/>API must behave as documented. Conversely, Device implementations MUST NOT<br/>honor or recognize string constants passed to the<br/> |
| android.hardware.Camera.setParameters() method other than those documented as<br/> |
| constants on the android.hardware.Camera.Parameters. That is, device<br/>implementations MUST support al  standard Camera parameters if the hardware<br/>al ows, and MUST NOT support custom Camera parameter types.<br/> |
| Device implementations MUST broadcast the Camera.ACTION_NEW_PICTURE intent<br/>whenever a new picture is taken by the camera and the entry of the picture has been<br/>added to the media store.<br/> |
| Device implementations MUST broadcast the Camera.ACTION_NEW_VIDEO intent<br/>whenever a new video is recorded by the camera and the entry of the picture has been<br/>added to the media store.<br/> |
| <b>7.5.4. Camera Orientation</b><br/> |
| Both front- and rear-facing cameras, if present, MUST be oriented so that the long<br/>dimension of the camera aligns with the screen's long dimention. That is, when the<br/>device is held in the landscape orientation, cameras MUST capture images in the<br/>landscape orientation. This applies regardless of the device's natural orientation; that<br/>is, it applies to landscape-primary devices as wel  as portrait-primary devices.<br/> |
| <b>7.6. Memory and Storage</b><br/> |
| <b>7.6.1. Minimum Memory and Storage</b><br/> |
| Device implementations MUST have at least 340MB of memory available to the kernel<br/>and userspace. The 340MB MUST be in addition to any memory dedicated to<br/>hardware components such as radio, video, and so on that is not under the kernel's<br/>control.<br/> |
| Device implementations MUST have at least 350MB of non-volatile storage available<br/>for application private data. That is, the /data partition MUST be at least 350MB.<br/> |
| The Android APIs include a Download Manager that applications may use to download<br/>data files [Resources, 56]. The device implementation of the Download Manager<br/>MUST be capable of downloading individual files of at least 100MB in size to the<br/>default "cache" location.<br/> |
| <b>7.6.2. Application Shared Storage</b><br/> |
| Device implementations MUST offer shared storage for applications. The shared<br/>storage provided MUST be at least 1GB in size.<br/> |
| Device implementations MUST be configured with shared storage mounted by default,<br/>"out of the box". If the shared storage is not mounted on the Linux path /sdcard, then<br/>the device MUST include a Linux symbolic link from /sdcard to the actual mount point.<br/> |
| Device implementations MUST enforce as documented the<br/> |
| android.permission.WRITE_EXTERNAL_STORAGE permission on this shared storage.<br/> |
| Shared storage MUST otherwise be writable by any application that obtains that<br/>permission.<br/> |
| Device implementations MAY have hardware for user-accessible removable storage,<br/>such as a Secure Digital card. Alternatively, device implementations MAY al ocate<br/>internal (non-removable) storage as shared storage for apps.<br/> |
| <hr/> |
| <a name=30></a>Regardless of the form of shared storage used, device implementations MUST<br/>provide some mechanism to access the contents of shared storage from a host<br/>computer, such as USB mass storage (UMS) or Media Transfer Protocol (MTP).<br/>Device implementations MAY use USB mass storage, but SHOULD use Media<br/>Transfer Protocol. If the device implementation supports Media Transfer Protocol:<br/> |
| The device implementation SHOULD be compatible with the reference Android<br/>MTP host, Android File Transfer [R<a href="file:///usr/local/google/home/gurunagarajan/android_dev/master/vendor/android/compatibility/cdd/jb/cdd-jb.xhtml#resources57">esources, 57].<br/></a>The device implementation SHOULD report a USB device class of 0x00.<br/>The device implementation SHOULD report a USB interface name of 'MTP'.<br/> |
| If the device implementation lacks USB ports, it MUST provide a host computer with<br/>access to the contents of shared storage by some other means, such as a network file<br/>system.<br/> |
| It is il ustrative to consider two common examples. If a device implementation includes<br/>an SD card slot to satisfy the shared storage requirement, a FAT-formatted SD card<br/>1GB in size or larger MUST be included with the device as sold to users, and MUST<br/>be mounted by default. Alternatively, if a device implementation uses internal fixed<br/>storage to satisfy this requirement, that storage MUST be 1GB in size or larger and<br/>mounted on /sdcard (or /sdcard MUST be a symbolic link to the physical location if it<br/>is mounted elsewhere.)<br/> |
| Device implementations that include multiple shared storage paths (such as both an<br/>SD card slot and shared internal storage) SHOULD modify the core applications such<br/>as the media scanner and ContentProvider to transparently support files placed in both<br/>locations.<br/> |
| <b>7.7. USB</b><br/> |
| Device implementations SHOULD include a USB client port, and SHOULD include a<br/>USB host port.<br/> |
| If a device implementation includes a USB client port:<br/> |
| the port MUST be connectable to a USB host with a standard USB-A port<br/>the port SHOULD use the micro USB form factor on the device side. Existing<br/>and new devices that run Android 4.1 are <b>very strongly encouraged to meet<br/>these requirements in Android 4.1</b> so they wil  be able to upgrade to the future<br/>platform releases<br/>the port SHOULD be centered in the middle of an edge. Device implementations<br/>SHOULD either locate the port on the bottom of the device (according to natural<br/>orientation) or enable software screen rotation for al  apps (including home<br/>screen), so that the display draws correctly when the device is oriented with the<br/>port at bottom. Existing and new devices that run Android 4.1 are <b>very strongly<br/>encouraged to meet these requirements in Android 4.1</b> so they wil  be able<br/>to upgrade to future platform releases.<br/>if the device has other ports (such as a non-USB charging port) it SHOULD be<br/>on the same edge as the micro-USB port<br/>it MUST al ow a host connected to the device to access the contents of the<br/>shared storage volume using either USB mass storage or Media Transfer<br/>Protocol<br/>it MUST implement the Android Open Accessory API and specification as<br/>documented in the Android SDK documentation, and MUST declare support for<br/>the hardware feature android.hardware.usb.accessory [Resources, 52]<br/>it MUST implement the USB audio class as documented in the Android SDK<br/>documentation [Resources, 66]<br/>it SHOULD implement support for USB battery charging spec<a href="file:///usr/local/google/home/gurunagarajan/android_dev/master/vendor/android/compatibility/cdd/jb/cdd-jb.xhtml#resources52">ification<br/></a>[Resources, 64] Existing and new devices that run Android 4.1 are <b>very<br/>strongly encour<a href="file:///usr/local/google/home/gurunagarajan/android_dev/master/vendor/android/compatibility/cdd/jb/cdd-jb.xhtml#resources66">aged to meet th</a></b><b>ese requirements in Android 4.1</b> so they<br/>wil  be able to upgrade to the future platform releases<br/> |
| If a device implementation includes a USB host port:<br/> |
| it MAY use a non-standard port form factor, but if so MUST ship with a cable or<br/>cables adapting the port to standard USB-A<br/>it MUST implement the Android USB host API as documented in the Android<br/>SDK, and MUST declare support for the hardware feature<br/> |
| android.hardware.usb.host [Resources, 53]<br/> |
| Device implementations MUST implement the Android Debug Bridge. If a device<br/>implementation omits a USB client port, it MUST implement the Android Debug Bridge<br/>via local-area network (such as Ethern<a href="file:///usr/local/google/home/gurunagarajan/android_dev/master/vendor/android/compatibility/cdd/jb/cdd-jb.xhtml#resources53">et or 802.11)</a><br/> |
| <hr/> |
| <a name=31></a><b>8. Performance Compatibility</b><br/> |
| Device implementations MUST meet the key performance metrics of an Android 4.1<br/>compatible device defined in the table below:<br/> |
| <b>Metric</b><br/> |
| <b>Performance Threshold</b><br/> |
| <b>Comments</b><br/> |
| The fol owing applications<br/>should launch within the<br/>specified time.<br/> |
| The launch time is measured as the<br/>total time to complete loading the<br/> |
| Browser: less than<br/> |
| default activity for the application,<br/> |
| Application<br/> |
| 1300ms<br/> |
| including the time it takes to start the<br/> |
| Launch Time<br/> |
| Contacts: less than<br/> |
| Linux process, load the Android<br/> |
| 700ms<br/> |
| package into the Dalvik VM, and cal<br/> |
| Settings: less than<br/> |
| onCreate.<br/> |
| 700ms<br/> |
| When multiple applications<br/>have been launched, re-<br/>launching an already-<br/> |
| Simultaneous<br/> |
| running application after it<br/> |
|  <br/> |
| Applications<br/> |
| has been launched must<br/>take less than the original<br/>launch time.<br/> |
| <b>9. Security Model Compatibility</b><br/> |
| Device implementations MUST implement a security model consistent with the Android<br/>platform security model as defined in Security and Permissions reference document in<br/>the APIs [Resources, 54] in the Android developer documentation. Device<br/>implementations MUST support instal ation of self-signed applications without<br/>requiring any additional permissions/certificates from any third parties/authorities.<br/>Specifical y, compatible devices MUST support the security mechanisms described in<br/>the fol ow sub-sections.<br/> |
| <b>9.1. Permissions</b><br/> |
| Device implementations MUST support the Android permissions model as defined in<br/>the Android developer documentation [Resources, 54]. Specifical y, implementations<br/>MUST enforce each permission defined as described in the SDK documentation; no<br/>permissions may be omitted, altered, or i<a href="file:///usr/local/google/home/gurunagarajan/android_dev/master/vendor/android/compatibility/cdd/jb/cdd-jb.xhtml#resources54">gnored. Impleme</a>ntations MAY add additional<br/>permissions, provided the new permission ID strings are not in the android.*<br/>namespace.<br/> |
| <b>9.2. UID and Process Isolation</b><br/> |
| Device implementations MUST support the Android application sandbox model, in<br/>which each application runs as a unique Unix-style UID and in a separate process.<br/>Device implementations MUST support running multiple applications as the same<br/>Linux user ID, provided that the applications are properly signed and constructed, as<br/>defined in the Security and Permissions reference [Resources, 54].<br/> |
| <b>9.3. Filesystem Permissions</b><br/> |
| Device implementations MUST support the Android file access permissions model as<br/>defined in as defined in the Security and Permissions reference [Resources, 54].<br/> |
| <b>9.4. Alternate Execution Environments</b><br/> |
| Device implementations MAY include runtime environments that execute applications<br/>using some other software or technology than the Dalvik virtual machine or native<br/>code. However, such alternate execution environments MUST NOT compromise the<br/>Android security model or the security of instal ed Android applications, as described<br/>in this section.<br/> |
| Alternate runtimes MUST themselves be Android applications, and abide by the<br/>standard Android security model, as described elsewhere in Section 9.<br/> |
| Alternate runtimes MUST NOT be granted access to resources protected by<br/>permissions not requested in the runtime's AndroidManifest.xml file via the <uses-<br/> |
| permission> mechanism.<br/> |
| <hr/> |
| <a name=32></a>Alternate runtimes MUST NOT permit applications to make use of features protected<br/>by Android permissions restricted to system applications.<br/> |
| Alternate runtimes MUST abide by the Android sandbox model. Specifical y:<br/> |
| Alternate runtimes SHOULD instal  apps via the PackageManager into separate<br/>Android sandboxes (that is, Linux user IDs, etc.)<br/>Alternate runtimes MAY provide a single Android sandbox shared by al<br/>applications using the alternate runtime<br/>Alternate runtimes and instal ed applications using an alternate runtime MUST<br/>NOT reuse the sandbox of any other app instal ed on the device, except through<br/>the standard Android mechanisms of shared user ID and signing certificate<br/>Alternate runtimes MUST NOT launch with, grant, or be granted access to the<br/>sandboxes corresponding to other Android applications<br/> |
| Alternate runtimes MUST NOT be launched with, be granted, or grant to other<br/>applications any privileges of the superuser (root), or of any other user ID.<br/> |
| The .apk files of alternate runtimes MAY be included in the system image of a device<br/>implementation, but MUST be signed with a key distinct from the key used to sign other<br/>applications included with the device implementation.<br/> |
| When instal ing applications, alternate runtimes MUST obtain user consent for the<br/>Android permissions used by the application. That is, if an application needs to make<br/>use of a device resource for which there is a corresponding Android permission (such<br/>as Camera, GPS, etc.), the alternate runtime MUST inform the user that the application<br/>wil  be able to access that resource. If the runtime environment does not record<br/>application capabilities in this manner, the runtime environment MUST list al<br/>permissions held by the runtime itself when instal ing any application using that runtime.<br/> |
| <b>10. Software Compatibility Testing</b><br/> |
| Device implementations MUST pass al  tests described in this section.<br/> |
| However, note that no software test package is ful y comprehensive. For this reason,<br/>device implementers are very strongly encouraged to make the minimum number of<br/>changes as possible to the reference and preferred implementation of Android 4.1<br/>available from the Android Open Source Project. This wil  minimize the risk of<br/>introducing bugs that create incompatibilities requiring rework and potential device<br/>updates.<br/> |
| <b>10.1. Compatibility Test Suite</b><br/> |
| Device implementations MUST pass the Android Compatibility Test Suite (CTS)<br/>[Resources, 2] available from the Android Open Source Project, using the final<br/>shipping software on the device. Additional y, device implementers SHOULD use the<br/>r<a href="file:///usr/local/google/home/gurunagarajan/android_dev/master/vendor/android/compatibility/cdd/jb/cdd-jb.xhtml#resources02">eference imple</a>mentation in the Android Open Source tree as much as possible, and<br/>MUST ensure compatibility in cases of ambiguity in CTS and for any<br/>reimplementations of parts of the reference source code.<br/> |
| The CTS is designed to be run on an actual device. Like any software, the CTS may<br/>itself contain bugs. The CTS wil  be versioned independently of this Compatibility<br/>Definition, and multiple revisions of the CTS may be released for Android 4.1. Device<br/>implementations MUST pass the latest CTS version available at the time the device<br/>software is completed.<br/> |
| <b>10.2. CTS Verifier</b><br/> |
| Device implementations MUST correctly execute al  applicable cases in the CTS<br/>Verifier. The CTS Verifier is included with the Compatibility Test Suite, and is intended<br/>to be run by a human operator to test functionality that cannot be tested by an<br/>automated system, such as correct functioning of a camera and sensors.<br/> |
| The CTS Verifier has tests for many kinds of hardware, including some hardware that<br/>is optional. Device implementations MUST pass al  tests for hardware which they<br/>possess; for instance, if a device possesses an accelerometer, it MUST correctly<br/>execute the Accelerometer test case in the CTS Verifier. Test cases for features noted<br/>as optional by this Compatibility Definition Document MAY be skipped or omitted.<br/> |
| Every device and every build MUST correctly run the CTS Verifier, as noted above.<br/>However, since many builds are very similar, device implementers are not expected to<br/>explicitly run the CTS Verifier on builds that differ only in trivial ways. Specifical y,<br/>device implementations that differ from an implementation that has passed the CTS<br/>Verfier only by the set of included locales, branding, etc. MAY omit the CTS Verifier<br/> |
| <hr/> |
| <a name=33></a>test.<br/> |
| <b>10.3. Reference Applications</b><br/> |
| Device implementers MUST test implementation compatibility using the fol owing open<br/>source applications:<br/> |
| The "Apps for Android" applications [Re<a href="file:///usr/local/google/home/gurunagarajan/android_dev/master/vendor/android/compatibility/cdd/jb/cdd-jb.xhtml#resources55">sources, 55]<br/></a>Replica Island (available in Android Market)<br/> |
| Each app above MUST launch and behave correctly on the implementation, for the<br/>implementation to be considered compatible.<br/> |
| <b>11. Updatable Software</b><br/> |
| Device implementations MUST include a mechanism to replace the entirety of the<br/>system software. The mechanism need not perform "live" upgrades - that is, a device<br/>restart MAY be required.<br/> |
| Any method can be used, provided that it can replace the entirety of the software<br/>preinstal ed on the device. For instance, any of the fol owing approaches wil  satisfy<br/>this requirement:<br/> |
| Over-the-air (OTA) downloads with offline update via reboot<br/>"Tethered" updates over USB from a host PC<br/>"Offline" updates via a reboot and update from a file on removable storage<br/> |
| The update mechanism used MUST support updates without wiping user data. That is,<br/>the update mechanism MUST preserve application private data and application<br/>shared data. Note that the upstream Android software includes an update mechanism<br/>that satisfies this requirement.<br/> |
| If an error is found in a device implementation after it has been released but within its<br/>reasonable product lifetime that is determined in consultation with the Android<br/>Compatibility Team to affect the compatibility of third-party applications, the device<br/>implementer MUST correct the error via a software update available that can be<br/>applied per the mechanism just described.<br/> |
| <b>12. Contact Us</b><br/> |
| You can contact the document authors at compatibility@android.com for clarifications<br/>and to bring up any issues that you think the document does not cover.<br/> |
| <hr/> |
| <a name=34></a><b>Appendix A - Bluetooth Test Procedure</b><br/> |
| The Compatibility Test Suite includes cases that cover basic operation of the Android<br/>RFCOMM Bluetooth API. However, since Bluetooth is a communications protocol<br/>between devices, it cannot be ful y tested by unit tests running on a single device.<br/>Consequently, device implementations MUST also pass the human-operated Bluetooth<br/>test procedure described below.<br/> |
| The test procedure is based on the BluetoothChat sample app included in the Android<br/>open source project tree. The procedure requires two devices:<br/> |
| a candidate device implementation running the software build to be tested<br/>a separate device implementation already known to be compatible, and of a<br/>model from the device implementation being tested - that is, a "known good"<br/>device implementation<br/> |
| The test procedure below refers to these devices as the "candidate" and "known<br/>good" devices, respectively.<br/> |
| <b>Setup and Installation</b><br/> |
| 1.  Build BluetoothChat.apk via 'make samples' from an Android source code tree<br/>2.  Instal  BluetoothChat.apk on the known-good device<br/>3.  Instal  BluetoothChat.apk on the candidate device<br/> |
| <b>Test Bluetooth Control by Apps</b><br/> |
| 1.  Launch BluetoothChat on the candidate device, while Bluetooth is disabled<br/>2.  Verify that the candidate device either turns on Bluetooth, or prompts the user<br/> |
| with a dialog to turn on Bluetooth<br/> |
| <b>Test Pairing and Communication</b><br/> |
| 1.  Launch the Bluetooth Chat app on both devices<br/>2.  Make the known-good device discoverable from within BluetoothChat (using the<br/> |
| Menu)<br/> |
| 3.  On the candidate device, scan for Bluetooth devices from within BluetoothChat<br/> |
| (using the Menu) and pair with the known-good device<br/> |
| 4.  Send 10 or more messages from each device, and verify that the other device<br/> |
| receives them correctly<br/> |
| 5.  Close the BluetoothChat app on both devices by pressing <b>Home<br/></b>6.  Unpair each device from the other, using the device Settings app<br/> |
| <b>Test Pairing and Communication in the Reverse</b><br/> |
| <b>Direction</b><br/> |
| 1.  Launch the Bluetooth Chat app on both devices.<br/>2.  Make the candidate device discoverable from within BluetoothChat (using the<br/> |
| Menu).<br/> |
| 3.  On the known-good device, scan for Bluetooth devices from within BluetoothChat<br/> |
| (using the Menu) and pair with the candidate device.<br/> |
| 4.  Send 10 or messages from each device, and verify that the other device<br/> |
| receives them correctly.<br/> |
| 5.  Close the Bluetooth Chat app on both devices by pressing Back repeatedly to<br/> |
| get to the Launcher.<br/> |
| <b>Test Re-Launches</b><br/> |
| 1.  Re-launch the Bluetooth Chat app on both devices.<br/>2.  Send 10 or messages from each device, and verify that the other device<br/> |
| receives them correctly.<br/> |
| Note: the above tests have some cases which end a test section by using Home, and<br/>some using Back. These tests are not redundant and are not optional: the objective is<br/>to verify that the Bluetooth API and stack works correctly both when Activities are<br/>explicitly terminated (via the user pressing Back, which cal s finish()), and implicitly sent<br/>to background (via the user pressing Home.) Each test sequence MUST be performed<br/>as described.<br/> |
| <hr/> |
| </body> |
| </html> |
