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

• Device implementers MAY modify the underlying implementation of the APIs, but such
modifications MUST NOT impact the stated behavior and Java-language signature of any
publicly exposed APIs.
• Device implementers MUST NOT add any publicly exposed elements (such as classes or
interfaces, or fields or methods to existing classes or interfaces) to the APIs above.
A "publicly exposed element" is any construct which is not decorated with the "@hide" marker in the
upstream Android source code. In other words, device implementers MUST NOT expose new APIs or
alter existing APIs in the namespaces noted above. Device implementers MAY make internal-only
modifications, but those modifications MUST NOT be advertised or otherwise exposed to developers.
Device implementers MAY add custom APIs, but any such APIs MUST NOT be in a namespace owned
by or referring to another organization. For instance, device implementers MUST NOT add APIs to the
com.google.* or similar namespace; only Google may do so. Similarly, Google MUST NOT add APIs to
other companies' namespaces.
If a device implementer proposes to improve one of the package namespaces above (such as by adding
useful new functionality to an existing API, or adding a new API), the implementer SHOULD visit
source.android.com and begin the process for contributing changes and code, according to the
information on that site.
Note that the restrictions above correspond to standard conventions for naming APIs in the Java
programming language; this section simply aims to reinforce those conventions and make them binding
through inclusion in this compatibility definition.
3.7. Virtual Machine Compatibility
A compatible Android device must support the full Dalvik Executable (DEX) bytecode specification and
Dalvik Virtual Machine semantics [
Resources , 13].
3.8. User Interface Compatibility
The Android platform includes some developer APIs that allow developers to hook into the system user
interface. Device implementations MUST incorporate these standard UI APIs into custom user interfaces
they develop, as explained below.
3.8.1. Widgets
Android defines a component type and corresponding API and lifecycle that allows applications to expose
an "AppWidget" to the end user [
Resources , 14]. The Android Open Source reference release includes a
Launcher application that includes user interface elements allowing the user to add, view, and remove
AppWidgets from the home screen.
Device implementers MAY substitute an alternative to the reference Launcher (i.e. home screen).
Alternative Launchers SHOULD include built-in support for AppWidgets, and expose user interface
elements to add, view, and remove AppWidgets directly within the Launcher. Alternative Launchers MAY
omit these user interface elements; however, if they are omitted, the device implementer MUST provide a
separate application accessible from the Launcher that allows users to add, view, and remove
AppWidgets.