beautypg.com

Soft api compatibility, Permissions, Build parameters – Google Android Compatibility Definition: Android 1.6 User Manual

Page 6: Permissions 3.2.2. build parameters

background image

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.

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 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 1.6. Device implementations MUST meet all the
requirements presented in this section.

3.2.1. Permissions

Device implementers MUST support and enforce all permission constants as documented by the
Permission reference page [

Resources

, 9]. Note that Section 10 lists addtional 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 [

Resources

, 10] that are

intended to describe the current device. 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

Comments

android.os.Build.VERSION.RELEASE

The version of the currently-executing Android system, in human-
readable format. For Android 1.6, this field MUST have the string value
"1.6".

android.os.Build.VERSION.SDK

The version of the currently-executing Android system, in a format
accessible to third-party application code. For Android 1.6, this field
MUST have the integer value 4.

android.os.Build.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 re-used for different builds shipped 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. There
are no requirements on the specific format of this field, except that it
MUST NOT be null or the empty string ("").

android.os.Build.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. There are no requirements on the specific format of this field,
except that it MUST NOT be null or the empty string ("").

android.os.Build.BRAND

A value chosen by the device implementer identifying the name of the
company, organization, individual, etc. who produced the device, in
human-readable format. A possible use of this field is to indicate the OEM