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 as intents, permissions, and similar aspects of Android applications that cannot be enforced at application compile time.
The Android APIs include a number of constants on the android.os.Build class that are intended to describe the current device.
Android intents allow application components to request functionality from other Android components. The Android upstream project includes a list of applications considered core Android applications, which implements several intent patterns to perform common actions.
[C-0-1] Device implementations MUST preload one or more applications or service components with an intent handler, for all the public intent filter patterns defined by the following core android applications in AOSP:
Desk Clock
Browser
Calendar
Contacts
Gallery
GlobalSearch
Launcher
Music
Settings
[C-0-1] As Android is an extensible platform, device implementations MUST allow each intent pattern referenced in section 3.2.3.1 to be overridden by third-party applications. The upstream Android open source implementation allows this by default.
[C-0-2] Dvice 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 that allows the user to select between multiple applications that all handle the same intent pattern.
[C-0-3] Device implementations MUST provide a user interface for users to modify the default activity for intents.
However, device implementations MAY provide default activities for specific URI patterns (e.g. http://play.google.com) when the default activity provides a more specific attribute for the data URI. For example, an intent filter pattern specifying the data URI “http://www.android.com” is more specific than the browser's core intent pattern for “http://”.
Android also includes a mechanism for third-party apps to declare an authoritative default app linking behavior for certain types of web URI intents. When such authoritative declarations are defined in an app's intent filter patterns, device implementations:
Third-party applications rely on the platform to broadcast certain intents to notify them of changes in the hardware or software environment.
Device implementations:
Android includes settings that provide users an easy way to select their default applications, for example for Home screen or SMS.
Where it makes sense, device implementations MUST provide a similar settings menu and be compatible with the intent filter pattern and API methods described in the SDK documentation as below.
If device implementations report android.software.home_screen
, they:
android.settings.HOME_SETTINGS
intent to show a default app settings menu for Home Screen.If device implementations report android.hardware.telephony
, they:
[C-2-1] MUST provide a settings menu that will call the android.provider.Telephony.ACTION_CHANGE_DEFAULT
intent to show a dialog to change the default SMS application.
[C-2-2] MUST honor the android.telecom.action.CHANGE_DEFAULT_DIALER
intent to show a dialog to allow the user to change the default Phone application.
[C-2-3] MUST honor the android.telecom.action.CHANGE_PHONE_ACCOUNTS intent to provide user affordance to configure the ConnectionServices
associated with the PhoneAccounts
, as well as a default PhoneAccount that the telecommunications service provider will use to place outgoing calls. The AOSP implementation meets this requirement by including a "Calling Accounts option" menu within the "Calls" settings menu.
If device implementations report android.hardware.nfc.hce
, they:
If device implementations support the VoiceInteractionService
and have more than one application using this API installed at a time, they:
android.settings.ACTION_VOICE_INPUT_SETTINGS
intent to show a default app settings menu for voice input and assist.If device implementations allow launching normal Android Activities on secondary displays, they:
android.software.activities_on_secondary_displays
feature flag.ActivityOptions.setLaunchDisplayId()
API.Display.FLAG_PRIVATE
flag is removed.VirtualDisplay
if the display itself is resized.android.content.res.Configuration
which corresponds to that display in order to be displayed, operate correctly, and maintain compatibility if an activity is launched on secondary display.If device implementations allow launching normal Android Activities on secondary displays and primary and secondary displays have different android.util.DisplayMetrics:
resizeableActivity=false
in AndroidManifest.xml
) and apps targeting API level 23 or lower MUST NOT be allowed on secondary displays.If device implementations allow launching normal Android Activities on secondary displays and a secondary display has the android.view.Display.FLAG_PRIVATE flag: