king
/
v811_spc009
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
Branches Tags
${ item.name }
Create tag ${ searchTerm }
Create branch ${ searchTerm }
from 'main'
${ noResults }
v811_spc009/compatibility/cdd/3_software/3_2_soft-api-compatibility.md

32 KiB
Raw Permalink Blame History Escape

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.
Parameter Details
VERSION.RELEASE The version of the currently-executing Android system, in human-readable format. This field MUST have one of the string values defined in ANDROID_VERSION.
VERSION.SDK The version of the currently-executing Android system, in a format accessible to third-party application code. For Android ANDROID_VERSION, this field MUST have the integer value ANDROID_VERSION_INT.
VERSION.SDK_INT The version of the currently-executing Android system, in a format accessible to third-party application code. For Android ANDROID_VERSION, this field MUST have the integer value ANDROID_VERSION_INT.
VERSION.INCREMENTAL A value chosen by the device implementer designating the specific build of the currently-executing Android system, in human-readable format. This value MUST NOT be reused for different builds made available to end users. A typical use of this field is to indicate which build number or source-control change identifier was used to generate the build. The value of this field MUST be encodable as printable 7-bit ASCII and match the regular expression “^[^ :\/~]+$”.
BOARD A value chosen by the device implementer identifying the specific internal hardware used by the device, in human-readable format. A possible use of this field is to indicate the specific revision of the board powering the device. The value of this field MUST be encodable as 7-bit ASCII and match the regular expression “^[a-zA-Z0-9_-]+$”.
BRAND A value reflecting the brand name associated with the device as known to the end users. MUST be in human-readable format and SHOULD represent the manufacturer of the device or the company brand under which the device is marketed. The value of this field MUST be encodable as 7-bit ASCII and match the regular expression “^[a-zA-Z0-9_-]+$”.
SUPPORTED_ABIS The name of the instruction set (CPU type + ABI convention) of native code. See section 3.3. Native API Compatibility.
SUPPORTED_32_BIT_ABIS The name of the instruction set (CPU type + ABI convention) of native code. See section 3.3. Native API Compatibility.
SUPPORTED_64_BIT_ABIS The name of the second instruction set (CPU type + ABI convention) of native code. See section 3.3. Native API Compatibility.
CPU_ABI The name of the instruction set (CPU type + ABI convention) of native code. See section 3.3. Native API Compatibility.
CPU_ABI2 The name of the second instruction set (CPU type + ABI convention) of native code. See section 3.3. Native API Compatibility.
DEVICE A value chosen by the device implementer containing the development name or code name identifying the configuration of the hardware features and industrial design of the device. The value of this field MUST be encodable as 7-bit ASCII and match the regular expression “^[a-zA-Z0-9_-]+$”. This device name MUST NOT change during the lifetime of the product.
FINGERPRINT A string that uniquely identifies this build. It SHOULD be reasonably human-readable. It MUST follow this template:

$(BRAND)/$(PRODUCT)/
    $(DEVICE):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS)

For example:

acme/myproduct/
    mydevice:ANDROID_VERSION/LMYXX/3359:userdebug/test-keys

The fingerprint MUST NOT include whitespace characters. The value of this field MUST be encodable as 7-bit ASCII.
HARDWARE The name of the hardware (from the kernel command line or /proc). It SHOULD be reasonably human-readable. The value of this field MUST be encodable as 7-bit ASCII and match the regular expression “^[a-zA-Z0-9_-]+$”.
HOST A string that uniquely identifies the host the build was built on, in human-readable format. There are no requirements on the specific format of this field, except that it MUST NOT be null or the empty string ("").
ID An identifier chosen by the device implementer to refer to a specific release, in human-readable format. This field can be the same as android.os.Build.VERSION.INCREMENTAL, but SHOULD be a value sufficiently meaningful for end users to distinguish between software builds. The value of this field MUST be encodable as 7-bit ASCII and match the regular expression “^[a-zA-Z0-9._-]+$”.
MANUFACTURER The trade name of the Original Equipment Manufacturer (OEM) of the product. There are no requirements on the specific format of this field, except that it MUST NOT be null or the empty string (""). This field MUST NOT change during the lifetime of the product.
MODEL A value chosen by the device implementer containing the name of the device as known to the end user. This SHOULD be the same name under which the device is marketed and sold to end users. There are no requirements on the specific format of this field, except that it MUST NOT be null or the empty string (""). This field MUST NOT change during the lifetime of the product.
PRODUCT A value chosen by the device implementer containing the development name or code name of the specific product (SKU) that MUST be unique within the same brand. MUST be human-readable, but is not necessarily intended for view by end users. The value of this field MUST be encodable as 7-bit ASCII and match the regular expression “^[a-zA-Z0-9_-]+$”. This product name MUST NOT change during the lifetime of the product.
SERIAL MUST return "UNKNOWN".
TAGS A comma-separated list of tags chosen by the device implementer that further distinguishes the build. The tags MUST be encodable as 7-bit ASCII and match the regular expression “^[a-zA-Z0-9._-]+” and MUST have one of the values corresponding to the three typical Android platform signing configurations: release-keys, dev-keys, and test-keys.
TIME A value representing the timestamp of when the build occurred.
TYPE A value chosen by the device implementer specifying the runtime configuration of the build. This field MUST have one of the values corresponding to the three typical Android runtime configurations: user, userdebug, or eng.
USER A name or user ID of the user (or automated user) that generated the build. There are no requirements on the specific format of this field, except that it MUST NOT be null or the empty string ("").
SECURITY_PATCH A value indicating the security patch level of a build. It MUST signify that the build is not in any way vulnerable to any of the issues described up through the designated Android Public Security Bulletin. It MUST be in the format [YYYY-MM-DD], matching a defined string documented in the Android Public Security Bulletin or in the Android Security Advisory, for example "2015-11-01".
BASE_OS A value representing the FINGERPRINT parameter of the build that is otherwise identical to this build except for the patches provided in the Android Public Security Bulletin. It MUST report the correct value and if such a build does not exist, report an empty string ("").
BOOTLOADER A value chosen by the device implementer identifying the specific internal bootloader version used in the device, in human-readable format. The value of this field MUST be encodable as 7-bit ASCII and match the regular expression “^[a-zA-Z0-9._-]+$”.
getRadioVersion() MUST (be or return) a value chosen by the device implementer identifying the specific internal radio/modem version used in the device, in human-readable format. If a device does not have any internal radio/modem it MUST return NULL. The value of this field MUST be encodable as 7-bit ASCII and match the regular expression “^[a-zA-Z0-9._-,]+$”.
getSerial() MUST (be or return) a hardware serial number, which MUST be available and unique across devices with the same MODEL and MANUFACTURER. The value of this field MUST be encodable as 7-bit ASCII and match the regular expression “^[a-zA-Z0-9._-,]+$”.

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:

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

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

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

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

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

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:

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:

If device implementations provide the data saver mode, they:

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

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

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

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

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.