Google Android Compatibility Definition: Android 1.6 - Manual (Page 10)

◦ The "" string MUST be the same as the value for
android.os.Build.MODEL
◦ The "" string MUST be the same as the value for android.os.Build.ID.
◦ The "" and "" strings SHOULD follow the usual conventions for
country code and language, and SHOULD refer to the curent locale of the device at the
time of the request.
Implementations MAY ship a custom user agent string in the standalone Browser application. What's
more, the standalone Browser MAY be based on an alternate browser technology (such as Firefox,
Opera, etc.) However, even if an alternate Browser application is shipped, the WebView component
provided to third-party applications MUST be based on WebKit, as above.
The standalone Browser application SHOULD include support for Gears [ Resources , 12] and MAY
include support for some or all of HTML5.
3.5. API Behavioral Compatibility
The behaviors of each of the API types (managed, soft, native, and web) must be consistent with the
preferred implementation of Android available from the Android Open Source Project.
Some specific areas of compatibility are:
• Devices MUST NOT change the behavior or meaning of a standard Intent
• Devices MUST NOT alter the lifecycle or lifecycle semantics of a particular type of system
component (such as Service, Activity, ContentProvider, etc.)
• Devices MUST NOT change the semantics of a particular permission
The above list is not comprehensive, and the onus is on device implementers to ensure behavioral
compatibility. For this reason, device implementers SHOULD use the source code available via the
Android Open Source Project where possible, rather than re-implement significant parts of the system.
The Compatibility Test Suite (CTS) tests significant portions of the platform for behavioral compatibility,
but not all. It is the responsibility of the implementer to ensure behavioral compatibility with the Android
Open Source Project.
3.6. API Namespaces
Android follows the package and class namespace conventions defined by the Java programming
language. To ensure compatibility with third-party applications, device implementers MUST NOT make
any prohibited modifications (see below) to these package namespaces:
• java.*
• javax.*
• sun.*
• android.*
• com.android.*
Prohibited modifications include:
• Device implementations MUST NOT modify the publicly exposed APIs on the Android platform
by changing any method or class signatures, or by removing classes or class fields.