Android Utility Function Library

If you need a feature that is native to Linux but not present on other
platforms, construct a platform-dependent implementation that shares
the Linux interface. That way the actual device runs as “light” as
possible.

If that isn’t feasible, create a system-independent interface and hide
the details.

The ultimate goal is not to create a super-duper platform abstraction
layer. The goal is to provide an optimized solution for Linux with
reasonable implementations for other platforms.

Resource overlay

Introduction

Overlay packages are special .apk files which provide no code but
additional resource values (and possibly new configurations) for
resources in other packages. When an application requests resources,
the system will return values from either the application’s original
package or any associated overlay package. Any redirection is completely
transparent to the calling application.

Resource values have the following precedence table, listed in
descending precedence.

• overlay package, matching config (eg res/values-en-land)

• original package, matching config

• overlay package, no config (eg res/values)

• original package, no config

During compilation, overlay packages are differentiated from regular
packages by passing the -o flag to aapt.

Background

This section provides generic background material on resources in
Android.

How resources are bundled in .apk files
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Android .apk files are .zip files, usually housing .dex code,
certificates and resources, though packages containing resources but
no code are possible. Resources can be divided into the following
categories; a `configuration’ indicates a set of phone language, display
density, network operator, etc.

• assets: uncompressed, raw files packaged as part of an .apk and
  explicitly referenced by filename. These files are
  independent of configuration.

• res/drawable: bitmap or xml graphics. Each file may have different
  values depending on configuration.

• res/values: integers, strings, etc. Each resource may have different
  values depending on configuration.

Resource meta information and information proper is stored in a binary
format in a named file resources.arsc, bundled as part of the .apk.

Resource IDs and lookup
~~~~~~~~~~~~~~~~~~~
During compilation, the aapt tool gathers application resources and
generates a resources.arsc file. Each resource name is assigned an
integer ID 0xppttiii (translated to a symbolic name via R.java), where

• pp: corresponds to the package namespace (details below).

• tt: corresponds to the resource type (string, int, etc). Every
  resource of the same type within the same package has the same
  tt value, but depending on available types, the actual numerical
  value may be different between packages.

• iiii: sequential number, assigned in the order resources are found.

Resource values are specified paired with a set of configuration
constraints (the default being the empty set), eg res/values-sv-port
which imposes restrictions on language (Swedish) and display orientation
(portrait). During lookup, every constraint set is matched against the
current configuration, and the value corresponding to the best matching
constraint set is returned (ResourceTypes.{h,cpp}).

Parsing of resources.arsc is handled by ResourceTypes.cpp; this utility
is governed by AssetManager.cpp, which tracks loaded resources per
process.

Assets are looked up by path and filename in AssetManager.cpp. The path
to resources in res/drawable are located by ResourceTypes.cpp and then
handled like assets by AssetManager.cpp. Other resources are handled
solely by ResourceTypes.cpp.

Package ID as namespace
~~~~~~~~~~~~~~~~~~~
The pp part of a resource ID defines a namespace. Android currently
defines two namespaces:

• 0x01: system resources (pre-installed in framework-res.apk)

• 0x7f: application resources (bundled in the application .apk)

ResourceTypes.cpp supports package IDs between 0x01 and 0x7f
(inclusive); values outside this range are invalid.

Each running (Dalvik) process is assigned a unique instance of
AssetManager, which in turn keeps a forest structure of loaded
resource.arsc files. Normally, this forest is structured as follows,
where mPackageMap is the internal vector employed in ResourceTypes.cpp.

mPackageMap[0x00] -> system package
mPackageMap[0x01] -> NULL
mPackageMap[0x02] -> NULL
…
mPackageMap[0x7f - 2] -> NULL
mPackageMap[0x7f - 1] -> application package

The resource overlay extension

The resource overlay mechanism aims to (partly) shadow and extend
existing resources with new values for defined and new configurations.
Technically, this is achieved by adding resource-only packages (called
overlay packages) to existing resource namespaces, like so:

mPackageMap[0x00] -> system package -> system overlay package
mPackageMap[0x01] -> NULL
mPackageMap[0x02] -> NULL
…
mPackageMap[0x7f - 2] -> NULL
mPackageMap[0x7f - 1] -> application package -> overlay 1 -> overlay 2

The use of overlay resources is completely transparent to
applications; no additional resource identifiers are introduced, only
configuration/value pairs. Any number of overlay packages may be loaded
at a time; overlay packages are agnostic to what they target – both
system and application resources are fair game.

The package targeted by an overlay package is called the target or
original package.

Resource overlay operates on symbolic resources names. Hence, to
override the string/str1 resources in a package, the overlay package
would include a resource also named string/str1. The end user does not
have to worry about the numeric resources IDs assigned by aapt, as this
is resolved automatically by the system.

As of this writing, the use of resource overlay has not been fully
explored. Until it has, only OEMs are trusted to use resource overlay.
For this reason, overlay packages must reside in /system/overlay.

Resource ID mapping
~~~~~~~~~~~~~~~
Resource identifiers must be coherent within the same namespace (ie
PackageGroup in ResourceTypes.cpp). Calling applications will refer to
resources using the IDs defined in the original package, but there is no
guarantee aapt has assigned the same ID to the corresponding resource in
an overlay package. To translate between the two, a resource ID mapping
{original ID -> overlay ID} is created during package installation
(PackageManagerService.java) and used during resource lookup. The
mapping is stored in /data/resource-cache, with a @idmap file name
suffix.

The idmap file format is documented in a separate section, below.

Package management
~~~~~~~~~~~~~~
Packages are managed by the PackageManagerService. Addition and removal
of packages are monitored via the inotify framework, exposed via
android.os.FileObserver.

During initialization of a Dalvik process, ActivityThread.java requests
the process’ AssetManager (by proxy, via AssetManager.java and JNI)
to load a list of packages. This list includes overlay packages, if
present.

When a target package or a corresponding overlay package is installed,
the target package’s process is stopped and a new idmap is generated.
This is similar to how applications are stopped when their packages are
upgraded.

Creating overlay packages

Overlay packages should contain no code, define (some) resources with
the same type and name as in the original package, and be compiled with
the -o flag passed to aapt.

The aapt -o flag instructs aapt to create an overlay package.
Technically, this means the package will be assigned package id 0x00.

There are no restrictions on overlay packages names, though the naming
convention

The ID map (idmap) file format

The idmap format is designed for lookup performance. However, leading
and trailing undefined overlay values are discarded to reduce the memory
footprint.

idmap grammar
~~~~~~~~~
All atoms (names in square brackets) are uint32_t integers. The
idmap-magic constant spells “idmp” in ASCII. Offsets are given relative
to the data_header, not to the beginning of the file.

map := header data
header := idmap-magic
idmap-magic := <0x706d6469>
data := data_header type_block+
data_header := header_block{m}
header_block := <0> |
type_block := entry{n}
entry :=

idmap example
~~~~~~~~~
Given a pair of target and overlay packages with CRC sums 0x216a8fe2
and 0x6b9beaec, each defining the following resources

Name Target package Overlay package
string/str0 0x7f010000 -
string/str1 0x7f010001 0x7f010000
string/str2 0x7f010002 -
string/str3 0x7f010003 0x7f010001
string/str4 0x7f010004 -
bool/bool0 0x7f020000 -
integer/int0 0x7f030000 0x7f020000
integer/int1 0x7f030001 -

the corresponding resource map is

0x706d6469 0x216a8fe2 0x6b9beaec 0x00000003 \
0x00000004 0x00000000 0x00000009 0x00000003 \
0x00000001 0x7f010000 0x00000000 0x7f010001 \
0x00000001 0x00000000 0x7f020000

or, formatted differently

0x706d6469 # magic: all idmap files begin with this constant
0x216a8fe2 # CRC32 of the resources.arsc file in the original package
0x6b9beaec # CRC32 of the resources.arsc file in the overlay package
0x00000003 # header; three types (string, bool, integer) in the target package
0x00000004 # header_block for type 0 (string) is located at offset 4
0x00000000 # no bool type exists in overlay package -> no header_block
0x00000009 # header_block for type 2 (integer) is located at offset 9
0x00000003 # header_block for string; overlay IDs span 3 elements
0x00000001 # the first string in target package is entry 1 == offset
0x7f010000 # target 0x7f01001 -> overlay 0x7f010000
0x00000000 # str2 not defined in overlay package
0x7f010001 # target 0x7f010003 -> overlay 0x7f010001
0x00000001 # header_block for integer; overlay IDs span 1 element
0x00000000 # offset == 0
0x7f020000 # target 0x7f030000 -> overlay 0x7f020000

總結

以上是生活随笔為你收集整理的ResourceID(frameworks/base/libs/utils/README)的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。