Google Android Gadget And Aplications For Cell Phone

The Android platform includes a set of managed APIs, a set of native APIs, and a body of so-called "soft" APIs such as the Intent system and web-application APIs. This section details the hard and soft APIs that are integral to compatibility, as well as certain other relevant technical and user interface behaviors. Device implementations MUST comply with all the requirements in this section.

Managed API Compatibility
The managed (Dalvik-based) execution environment is the primary vehicle for Android applications. The Android application programming interface (API) is the set of Android platform interfaces exposed to applications running in the managed VM environment. Device implementations MUST provide complete implementations, including all documented behaviors, of any documented API exposed by the Android 2.1 SDK. Device implementations MUST NOT omit any managed APIs, alter API interfaces or signatures, deviate from the documented behavior, or include no-ops, except where specifically allowed by this Compatibility Definition.

Soft API Compatibility

In addition to the managed APIs from Section 3.1, Android also includes a significant runtime-only "soft" API, in the form of such things such as Intents, permissions, and similar aspects of Android applications that cannot be enforced at application compile time. This section details the "soft" APIs and system behaviors required for
compatibility with Android 2.1. Device implementations MUST meet all the requirements presented in this section.

Device implementers MUST support and enforce all permission constants as documented by the Permission reference. Note that Section 10 lists addtional requirements related to the Android security model.

Intent Compatibility
Android uses Intents to achieve loosely-coupled integration between applications. This section describes requirements related to the Intent patterns that MUST be honored by device implementations. By "honored", it is meant that the device implementer MUST provide an Android Activity or Service that specifies a matching Intent filter and binds to and implements correct behavior for each specified Intent
pattern.

Core Application Intents
The Android upstream project defines a number of core applications, such as a phone dialer, calendar, contacts book, music player, and so on. Device implementers MAY replace these applications with alternative versions. However, any such alternative versions MUST honor the same Intent patterns provided by the upstream project. For example, if a device contains an alternative music player, it must still honor the Intent pattern issued by third-party applications to pick a song.
The following applications are considered core Android system applications:
- Desk Clock
- Browser
- Calendar
- Calculator
- Camera
- Contacts
- Email
- Gallery
- GlobalSearch
- Launcher
- LivePicker (that is, the Live Wallpaper picker application; MAY be omitted if the
- device does not support Live Wallpapers, per Section 3.8.5.)
- Messaging (AKA "Mms")
- Music
- Phone
- Settings
- SoundRecorder

The core Android system applications include various Activity, or Service components that are considered "public". That is, the attribute "android:exported" may be absent, or may have the value "true". For every Activity or Service defined in one of the core Android system apps that is not marked as non-public via an android:exported attribute with the value "false", device implementations MUST include a compontent of the same type implementing the same Intent filter patterns as the core Android system app. In other words, a device implementation MAY replace core Android system apps; however, if it does, the device implementation MUST support all Intent patterns defined by each core Android system app being replaced.

Intent Overrides
As Android is an extensible platform, device implementers MUST allow each Intent pattern defined in core system apps to be overridden by third-party applications. The upstream Android open source project allows this by default; device implementers MUST NOT attach special privileges to system applications' use of
these Intent patterns, or prevent third-party applications from binding to and assuming control of these patterns. This prohibition specifically includes but is not limited to disabling the "Chooser" user interface which allows the user to select between multiple applications which all handle the same Intent pattern.

Intent Namespaces
Device implementers MUST NOT include any Android component that honors any new Intent or Broadcast Intent patterns using an ACTION, CATEGORY, or other key string in the android.* namespace. Device implementers MUST NOT include any Android components that honor any new Intent or Broadcast Intent patterns using an ACTION, CATEGORY, or other key string in a package space belonging to another
organization. Device implementers MUST NOT alter or extend any of the Intent patterns used by the core apps listed in Section 3.2.3.1.

Broadcast Intents
Third-party applications rely on the platform to broadcast certain Intents to notify them of changes in the hardware or software environment. Android-compatible devices MUST broadcast the public broadcast Intents in response to appropriate system events. Broadcast Intents are described in the SDK documentation.