The Runtime module (
com.android.runtime.release.apex) is an APEX
module for native and managed Android runtimes. The module includes the
- Managed Core Library (new in Android 10)
- ICU libraries
The Runtime module is generated when building Android and contains the build
artifacts of its constituent projects. It's closely coupled with both the
com.android.conscrypt.apex) and the
Time Zone Data
com.android.tzdata.apex), also new in Android
Android Runtime (ART) changes
In Android 10, the ART build system creates the
Runtime module in two variants: release and debug (contains
additional diagnostic and debugging tools). The release version is installed
user builds and the debug version is installed on
eng builds. When a device boots,
apexd mounts the Runtime module under
In the module, the boot class path is split between classes such as Managed
Core Library, classes in other modules (such as Conscrypt and Media), and
classes in the system partition (such as
framework.jar). If a
module is updated, dex2oat JIT compiles boot classes in modules.
Android 10 includes the following API changes:
- A new API for DEX file support provides a stable interface between system code (such as the stack unwinder) and ART.
- A new API is used as an ART-specific platform abstraction layer (PAL) with
the system. The system element (
libartpalette-system.so) exposes system functionality depended on by ART and is accessible through a client library (
libartpalette.so), that loads the system library installed on device.
Android 10 also refactors paths for some ART
binaries, moving the following binaries from
/system/bin to the
profman. For compatibility, the
refactor includes symlinks in
tzcode uses time zone data provided by the
Runtime module (
/apex/com.android.runtime/etc/tz/) and the Time
Zone Data module (
tzcode prioritizes data from
APK-based time zone updates
over APEX-based time zone updates (provided by the Time Zone Data module) and
falls back to
libc uses a new library (
libandroidicu) instead of
libicui18n. For details, see
Managed Core Library.
Finally, Bionic-shared libraries and dynamic linker paths are now symlinks (applies to 64-bit variants as well). Specifically:
Boot sequence changes
To support the Runtime module, Android 10 updates the boot sequence to the following:
initprepares the bootstrap and default mount namespaces. A
tmpfsis mounted on
/apexand the propagation type of the mount point is set to
apexdstarts in bootstrap mode, before any other process. It activates the APEX files in
/system/apexand mounts them in the bootstrap mount namespace.
- Other pre-
apexdprocesses start. These processes are in the bootstrap mount namespace and are provided with libraries from system APEX files.
initswitches into the default mount namespace and starts
apexdas a daemon.
apexdscans both /
/system/apexand activates the most recent APEX files in those directories. APEX files activated in this phase are mounted in the default namespaces only and aren't visible to the pre-
Managed Core Library
The Managed Core Library is a collection of low-level, updatable, managed
dex executed by Android Runtime) code that was previously known
as libcore. In Android 10, the Managed Core
Library includes multiple Git projects (in addition to
platform/libcore/), and the new term refers to the collection
The Managed Core Library is provided by the Runtime, Time Zone Data, and
Conscrypt modules and relies on native libraries present in the Runtime
module, such as
Collected code comes from multiple Git projects such as
zlib. The library is split between multiple
files on the boot classpath (for example
apache-xml.jar); however, it doesn't include
Android 10 repackages several components
that were previously packaged under
com.android.* using bytecode manipulation. These components are
repackaged using source code transformation to enable Java annotations to be
used for API metadata.
Core Platform API
The Core Platform API provides a stable, managed-code API for use by the Android framework, enabling the Managed Core Library to be updated by ensuring that all framework dependencies are clearly understood. The Core Platform API:
- Indicates dependencies in addition to the public SDK APIs. For API
content, refer to
- Explicitly annotates managed code with
@libcore.api.CorePlatformApi. For code in
libcore/ojluni/src/, refer to the annotations in
libcore/ojluni/annotations/mmodule/; for all other projects, refer to the main source files.
The build system defaults to using the Core Platform API when building Java
source platform targets (that is, in the absence of
.bp files or
.mk files). This default
ensures that Android framework code is restricted to using public APIs and
the Core Platform API only (no implementation classes). Other
sdk_version values such as
"current" work as they always have (they allow use of public SDK
APIs only). The build system also reports changes to the Core Platform API
surface and prevents targets (outside of a small set of exceptions) from
depending on Managed Core Library internals.
The Runtime module performs access checks for fields and methods covered by
the Core Platform API. The checks are performed when platform code accesses
methods in the Core Platform API. The system property
persist.debug.dalvik.vm.core_platform_api_policy controls the
policy around these checks. Valid policy values are
just-warn. For debug and eng builds,
the standard policy is
just-warn, which logs a warning when a
policy violation is detected. For user builds, the default policy is
disabled and no action is taken. The Runtime module also performs
Core Platform API checks when native code resolves fields and methods through
the Java Native Interface (JNI).
Android 10 also includes numerous changes to simplify the APIs, runtime dependencies, and build-time dependencies between the Android framework and Managed Core Library.
Android 10 repackages the
Android 10 refactors native libraries that support
the Managed Core Library. Several dynamically linked libraries (for example,
were previously shared with other parts of the platform are now duplicated so
that the Runtime module has its own copies loaded into the runtime linker
namespace. Dynamically linked native libraries provided by the Runtime module
The Runtime module includes ICU libraries (ICU4C and ICU4J) and associated data.
Android 10 includes
libandroidicu, a new
dynamic library that makes a subset of ICU4C functions available to framework
code. The linker symbols for
libandroidicu are stable across ICU
releases (the symbols end with
_android rather than
_icu-version-number used in
libicui18n). However, for app compatibility,
libicui18n symbols remain available.
Also for app compatibility, the linker redirects absolute paths to ICU
libraries in dlopen() calls, i.e.
dlopen("/system/lib/libicui18n.so", ...), redirect to the
corresponding libraries in
targetSdkVersion < 29.
At runtime, the ICU data file installs to
/apex/com.android.runtime/etc/icu/. For app compatibility,
Android 10 includes a symlink from the previous ICU
data file location (
Android 10 moves Conscrypt, which is logically part
of the Managed Core Library, to its own independently
module. Between the Conscrypt and Runtime modules, a new bi-directional
API surface indicates dependencies in addition to the public SDK APIs (for
details, refer to
libcore/mmodules/intracoreapi/). API elements
are explicitly annotated with
The build system verifies that Conscrypt code is restricted to public APIs and the intra-core API. Other Managed Core Library dependencies on Conscrypt are reflection based; the build system records such dependencies where possible and reports all changes to the API surface.
Time Zone Data interactions
In Android 10, architecture libcore, Runtime libcore,
and ICU4J/ICU4C use time zone data provided by the Runtime module
/apex/com.android.runtime/etc/tz/) and the Time Zone Data module
/apex/com.android.tzdata/etc/tz/). These libraries:
- Fall back to
- Prioritize data from APK-based time zone updates over APEX-based time zone updates (provided by the Time Zone Data module).
Android 10 moves the
AsynchronousCloseMonitor API from
libandroidio.so. The API is exposed by
Android 10 moves the
library to the Runtime module as this library is tightly coupled with
libnativeloader and the Bionic C libraries that are part of the
In Android 10, the Runtime module makes
libnativehelper available to system and frameworks code, while
code outside of the Runtime module links against a stubs API (C only) for
- A reduced set of cached JNI classes, methods, and fields.
- Improved JNI macros in
- New JNI helper methods for accessing the internals of
java.nio.Bufferclasses from native code (see methods starting with
libnativehelper/include/nativehelper/JNIHelp.h). These methods are used by the framework code.
In Android 10, the Runtime module includes the
libnativeloader library, which is responsible for creating linker
namespaces for Java class loaders. The linker namespaces apply to the native
libraries loaded by Android apps written in managed code. The library
is closely coupled to the Bionic linker, which is also in the module.
Android 10 moves
libpac, which provides
a C API for PacProcessor, into the Runtime module. The
by PacProcessor (an independent package and process).
Linker configuration changes
In Android 10,
are used to separate internal dynamic native library dependencies in the
Runtime module from the platform and other APEX modules. The
runtime linker namespace is set up for Runtime module libraries,
with appropriate links to and from other namespaces for external dependencies.
The linker configuration resides in
/system, and in
/apex/com.android.runtime/etc/ld.config.txt for binaries in the
Runtime module itself (
SystemServer and framework changes
In Android 10, the SystemServer hosts a new RuntimeService for reporting information from the Runtime module. To view this information, use the following ADB command:
adb shell dumpsys runtimeinfo
The information managed by the RuntimeService is extensible. For service
source code, refer to
for example client code, refer to
Android 10 also updates the over-the-air (OTA) update
process to use
dex2oat and other tools from the Runtime module.