3.2. 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 as intents, permissions, and similar aspects of Android applications that cannot be enforced at application compile time.

3.2.1. Permissions

• [C-0-1] Device implementers MUST support and enforce all permission constants as documented by the Permission reference page. Note that section 9 lists additional requirements related to the Android security model.

3.2.2. Build Parameters

The Android APIs include a number of constants on the android.os.Build class that are intended to describe the current device.

• [C-0-1] To provide consistent, meaningful values across device implementations, the table below includes additional restrictions on the formats of these values to which device implementations MUST conform.

3.2.3. Intent Compatibility

3.2.3.1. Common Application Intents

Android intents allow application components to request functionality from other Android components. The Android upstream project includes a list of applications which implement several intent patterns to perform common actions.

Device implementations:

• [C-SR] Are STRONGLY RECOMMENDED to preload one or more applications or service components with an intent handler, for all the public intent filter patterns defined by the following application intents listed here and provide fulfillment i.e meet with the developer expectation for these common application intents as described in the SDK.

Please refer to Section 2 for mandatory application intents for each device type.

3.2.3.2. Intent Resolution

• [C-0-1] As Android is an extensible platform, device implementations MUST allow each intent pattern referenced in section 3.2.3.1 , except for Settings, to be overridden by third-party applications. The upstream Android open source implementation allows this by default.

• [C-0-2] 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 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:

• [C-0-4] MUST attempt to validate any intent filters by performing the validation steps defined in the Digital Asset Links specification as implemented by the Package Manager in the upstream Android Open Source Project.
• [C-0-5] MUST attempt validation of the intent filters during the installation of the application and set all successfully validated URI intent filters as default app handlers for their URIs.
• MAY set specific URI intent filters as default app handlers for their URIs, if they are successfully verified but other candidate URI filters fail verification. If a device implementation does this, it MUST provide the user appropriate per-URI pattern overrides in the settings menu.
• MUST provide the user with per-app App Links controls in Settings as follows:
  • [C-0-6] The user MUST be able to override holistically the default app links behavior for an app to be: always open, always ask, or never open, which must apply to all candidate URI intent filters equally.
  • [C-0-7] The user MUST be able to see a list of the candidate URI intent filters.
  • The device implementation MAY provide the user with the ability to override specific candidate URI intent filters that were successfully verified, on a per-intent filter basis.
  • [C-0-8] The device implementation MUST provide users with the ability to view and override specific candidate URI intent filters if the device implementation lets some candidate URI intent filters succeed verification while some others can fail.

3.2.3.3. Intent Namespaces

• [C-0-1] Device implementations 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.* or com.android.* namespace.
• [C-0-2] 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.
• [C-0-3] Device implementers MUST NOT alter or extend any of the intent patterns listed in section 3.2.3.1.
• Device implementations MAY include intent patterns using namespaces clearly and obviously associated with their own organization. This prohibition is analogous to that specified for Java language classes in section 3.6.

3.2.3.4. Broadcast Intents

Third-party applications rely on the platform to broadcast certain intents to notify them of changes in the hardware or software environment.

Device implementations:

• [C-0-1] MUST broadcast the public broadcast intents listed here in response to appropriate system events as described in the SDK documentation. Note that this requirement is not conflicting with section 3.5 as the limitation for background applications are also described in the SDK documentation. Also certain broadcast intents are conditional upon hardware support, if the device supports the necessary hardware they MUST broadcast the intents and provide the behavior inline with SDK documentation.

3.2.3.5. Conditional Application Intents

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:

• [C-1-1] MUST honor the 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.

  • MUST use the user-selected default Phone app's UI for incoming and outgoing calls except for emergency calls, which would use the preinstalled Phone app.

• [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.

• [C-2-4] MUST allow android.telecom.CallRedirectionService for an app that holds the android.app.role.CALL_REDIRECTION role.

• [C-2-5] MUST provide the user affordance to choose an app that holds the android.app.role.CALL_REDIRECTION role.

• [C-2-6] MUST honor the android.intent.action.SENDTO and android.intent.action.VIEW intents and provide an activity to send/display SMS messages.

• [C-SR] Are Strongly Recommended to honor android.intent.action.ANSWER, android.intent.action.CALL, android.intent.action.CALL_BUTTON, android.intent.action.VIEW & android.intent.action.DIAL intents with a preloaded dialer application which can handle these intents and provide fulfillment as described in the SDK.

If device implementations report android.hardware.nfc.hce, they:

• [C-3-1] MUST honor the android.settings.NFC_PAYMENT_SETTINGS intent to show a default app settings menu for Tap and Pay.
• [C-3-2] MUST honor android.nfc.cardemulation.action.ACTION_CHANGE_DEFAULT intent to show an activity which opens a dialog to ask the user to change the default card emulation service for a certain category as described in the SDK.

If device implementations report android.hardware.nfc, they:

• [C-4-1] MUST honor these intents android.nfc.action.NDEF_DISCOVERED, android.nfc.action.TAG_DISCOVERED & android.nfc.action.TECH_DISCOVERED, to show an activity which fulfils developer expectations for these intents as described in the SDK.

If device implementations support the VoiceInteractionService and have more than one application using this API installed at a time, they:

• [C-4-1] MUST honor the android.settings.ACTION_VOICE_INPUT_SETTINGS intent to show a default app settings menu for voice input and assist.

If device implementations report android.hardware.bluetooth, they:

• [C-5-1] MUST honor the ‘android.bluetooth.adapter.action.REQUEST_ENABLE’ intent and show a system activity to allow the user to turn on Bluetooth.
• [C-5-2] MUST honor the ‘android.bluetooth.adapter.action.REQUEST_DISCOVERABLE’ intent and show a system activity that requests discoverable mode.

If device implementations support the DND feature, they:

• [C-6-1] MUST implement an activity that would respond to the intent ACTION_NOTIFICATION_POLICY_ACCESS_SETTINGS, which for implementations with UI_MODE_TYPE_NORMAL it MUST be an activity where the user can grant or deny the app access to DND policy configurations.

If device implementations allow users to use third-party input methods on the device, they:

• [C-7-1] MUST provide a user-accessible mechanism to add and configure third-party input methods in response to the android.settings.INPUT_METHOD_SETTINGS intent.

If device implementations support third-party accessibility services, they:

• [C-8-1] MUST honor the android.settings.ACCESSIBILITY_SETTINGS intent to provide a user-accessible mechanism to enable and disable the third-party accessibility services alongside the preloaded accessibility services.

If device implementations include support for Wi-Fi Easy Connect and expose the functionality to third-party apps, they:

• [C-9-1] MUST implement the Settings#ACTION_PROCESS_WIFI_EASY_CONNECT_URI Intent APIs as described in the SDK documentation.

If device implementations provide the data saver mode, they:

• [C-10-1] MUST provide a user interface in the settings, that handles the Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS intent, allowing users to add applications to or remove applications from the allow list.

If device implementations do not provide the data saver mode, they:

• [C-11-1] MUST have an activity that handles the Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS intent but MAY implement it as a no-op.

If device implementations declare the support for camera via android.hardware.camera.any they:

• [C-12-1] MUST honor the android.media.action.STILL_IMAGE_CAMERA and android.media.action.STILL_IMAGE_CAMERA_SECURE intent and launch the camera in still image mode as described in the SDK.
• [C-12-2] MUST honor the android.media.action.VIDEO_CAMERA intent to launch the camera in video mode as described in the SDK.
• [C-12-3] MUST honor only allow preinstalled Android applications to handle the following intents MediaStore.ACTION_IMAGE_CAPTURE, MediaStore.ACTION_IMAGE_CAPTURE_SECURE, and MediaStore.ACTION_VIDEO_CAPTURE as described in the SDK document.

If device implementations report android.software.device_admin, they:

• [C-13-1] MUST honor the intent android.app.action.ADD_DEVICE_ADMIN to invoke a UI to bring the user through adding the device administrator to the system (or allowing them to reject it).

• [C-13-2] MUST honor the intents android.app.action.ADMIN_POLICY_COMPLIANCE, android.app.action.GET_PROVISIONING_MODE, android.app.action.PROVISIONING_SUCCESSFUL, android.app.action.PROVISION_MANAGED_DEVICE, android.app.action.PROVISION_MANAGED_PROFILE, android.app.action.SET_NEW_PARENT_PROFILE_PASSWORD, android.app.action.SET_NEW_PASSWORD & android.app.action.START_ENCRYPTION and have an activity to provide fulfillment for these intents as described in SDK here.

If device implementations declare the android.software.autofill feature flag, they:

• [C-14-1] MUST fully implement the AutofillService and AutofillManager APIs and honor the android.settings.REQUEST_SET_AUTOFILL_SERVICE intent to show a default app settings menu to enable and disable autofill and change the default autofill service for the user.

If device implementations include a pre-installed app or wish to allow third-party apps to access the usage statistics, they:

• [C-SR] are STRONGLY RECOMMENDED provide user-accessible mechanism to grant or revoke access to the usage stats in response to the android.settings.ACTION_USAGE_ACCESS_SETTINGS intent for apps that declare the android.permission.PACKAGE_USAGE_STATS permission.

If device implementations intend to disallow any apps, including pre-installed apps, from accessing the usage statistics, they:

• [C-15-1] MUST still have an activity that handles the android.settings.ACTION_USAGE_ACCESS_SETTINGS intent pattern but MUST implement it as a no-op, that is to have an equivalent behavior as when the user is declined for access.

If device implementations report the feature android.hardware.audio.output, they:

• [C-SR] Are Strongly Recommended to honor android.intent.action.TTS_SERVICE, android.speech.tts.engine.INSTALL_TTS_DATA & android.speech.tts.engine.GET_SAMPLE_TEXT intents have an activity to provide fulfillment for these intents as described in SDK here.

Android includes support for interactive screensavers, previously referred to as Dreams. Screen Savers allow users to interact with applications when a device connected to a power source is idle or docked in a desk dock. Device Implementations:

• SHOULD include support for screen savers and provide a settings option for users to configure screen savers in response to the android.settings.DREAM_SETTINGS intent.

3.2.4. Activities on secondary/multiple displays

If device implementations allow launching normal Android Activities on more than one display, they:

• [C-1-1] MUST set the android.software.activities_on_secondary_displays feature flag.
• [C-1-2] MUST guarantee API compatibility similar to an activity running on the primary display.
• [C-1-3] MUST land the new activity on the same display as the activity that launched it, when the new activity is launched without specifying a target display via the ActivityOptions.setLaunchDisplayId() API.
• [C-1-4] MUST destroy all activities, when a display with the Display.FLAG_PRIVATE flag is removed.
• [C-1-5] MUST securely hide content on all screens when the device is locked with a secure lock screen, unless the app opts in to show on top of lock screen using Activity#setShowWhenLocked() API.
• SHOULD have 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 a secondary display has the android.view.Display.FLAG_PRIVATE flag:

• [C-3-1] Only the owner of that display, system, and activities that are already on that display MUST be able to launch to it. Everyone can launch to a display that has android.view.Display.FLAG_PUBLIC flag.