[C-0-2] MUST NOT add any publicly exposed elements (such as classes or interfaces, or
fields or methods to existing classes or interfaces) or Test or System APIs to the APIs in
the above namespaces. A “publicly exposed element” is any construct that is not
decorated with the “@hide” marker as used in the upstream Android source code.
Device implementers MAY modify the underlying implementation of the APIs, but such modifications:
[C-0-3] MUST NOT impact the stated behavior and Java-language signature of any
publicly exposed APIs.
[C-0-4] MUST NOT be advertised or otherwise exposed to developers.
However, device implementers MAY add custom APIs outside the standard Android namespace, but
the custom APIs:
[C-0-5] MUST NOT be in a namespace owned by or referring to another organization. For
instance, device implementers MUST NOT add APIs to the
com.google.*
or similar
namespace: only Google may do so. Similarly, Google MUST NOT add APIs to other
companies' namespaces.
[C-0-6] MUST be packaged in an Android shared library so that only apps that explicitly
use them (via the <uses-library> mechanism) are affected by the increased memory usage
of such APIs.
If a device implementer proposes to improve one of the package namespaces above (such as by
adding useful new functionality to an existing API, or adding a new API), the implementer SHOULD
visit
source.android.com
and begin the process for contributing changes and code, according to the
information on that site.
Note that the restrictions above correspond to standard conventions for naming APIs in the Java
programming language; this section simply aims to reinforce those conventions and make them
binding through inclusion in this Compatibility Definition.
3.7. Runtime Compatibility
Device implementations:
[C-0-1] MUST support the full Dalvik Executable (DEX) format and
Dalvik bytecode
specification and semantics
.
[C-0-2] MUST configure Dalvik runtimes to allocate memory in accordance with the
upstream Android platform, and as specified by the following table. (See
section 7.1.1
for
screen size and screen density definitions.)
SHOULD use Android RunTime (ART), the reference upstream implementation of the
Dalvik Executable Format, and the reference implementation’s package management
system.
SHOULD run fuzz tests under various modes of execution and target architectures to
assure the stability of the runtime. Refer to
JFuzz
and
DexFuzz
in the Android Open
Source Project website.
Note that memory values specified below are considered minimum values and device
implementations MAY allocate more memory per application.
Screen Layout
Screen Density
Minimum Application Memory
120 dpi (ldpi)
32MB
160 dpi (mdpi)
Page 37 of 132
