The LOCAL_*_$(TARGET_ARCH) variables don't make sense for host
modules, only append use them for target modules.
Also complete the list of LOCAL_*_arch and LOCAL_*_32/64 to be
consistent.
Change-Id: I00c83e5c4e08ed9a844f9f99a79ce4bcc3f0bf11
combo/TARGET_x86*.mk mistakenly added TARGET_GLOBAL_CFLAGS to their
linker command lines. This results in clang builds not working properly,
since they strip some unknown flags from TARGET_GLOBAL_CFLAGS.
Change-Id: I60a1ff5df70305323134435e4ae107ea7acfe8ea
Add four new variables for module makefiles:
LOCAL_MODULE_TARGET_ARCH specifies that a module is only supported for
one or more architectures. Any architecture not in the list will be
not attempt to build the module. The expected use case is prebuilts
that are only suitable for a single architecture, or modules like llvm
that need per-architecture support.
LOCAL_MODULE_UNSUPPORTED_TARGET_ARCH specifies that a module cannot be
built for one or more architectures.
LOCAL_MODULE_TARGET_ARCH_WARN and LOCAL_MODULE_UNSUPPORTED_TARGET_ARCH_WARN
are the same, but warn that the arch is not supported, which is useful
for modules that are critical but not yet working.
The logic for whether or not to build an architecture is fairly
complicated, so this patch consolidates it into module_arch_supported.mk
Change-Id: I120caf4a375f484e1fd6017b60c2f53882ae01e6
exceeds 92 symbols (91 valid symbols + \0). It is better to catch that
issue on earlier stage, i.e. fail the build with an appropriate message.
For developer's build, show warning message instead of failing the build
(in the latter case, as developers do not usually care about build properties
too much).
Change-Id: I03ced7b486d43a71b1921e0a9c48b43aa30727c7
-- Added TARGET_PREFER_32_BIT, which sets LOCAL_32_BIT_ONLY for an
executable, if LOCAL_NO_2ND_ARCH is not true.
Name resolving in 64-bit multilib build:
-- Name resolving in PRODUCT_PACKAGES:
foo:32 resolves to foo_32;
foo:64 resolves to foo;
foo resolves to both foo and foo_32 (if foo_32 is defined).
-- Name resolving for LOCAL_REQUIRED_MODULES:
If a module is built for 2nd arch, its required module resolves to
32-bit variant, if it exits;
Otherwise for executable and shared library, a required module
resolves to the default 64-bit variant; for other module classes,
required module foo resolves to both foo and foo_32 (if foo_32 is
defined)
Bug: 12898862
Change-Id: I5fda1a77f58814097b10b5ad2743ee25adfaecc4
1. Following the setup of gcc in build/core/combo/,
we added the [HOST|TARGET]_<arch>.mk clang config files,
and load only the configs needed by the current product.
2. Added support for the 2nd arch.
Change-Id: I2a383418a9688a050b39492f8e489d40eeeb5f2d
I don't think we can realistically turn this on for 32-bit builds any
time soon.
Also, fix the arm64 stack-protector hack.
Change-Id: Ie1e7c875bbc06fb21bb372b8ca99879a23ef53d4
2ND_TARGET_DEPENDENCIES_ON_SHARED_LIBRARIES was not set,
which was causing the later += to act like = instead of
:=, and the dependencies would disappear as soon as
LOCAL_MODULE was cleared.
Change-Id: Idea291524fc06377deafec62f37d20eaa7f93bca
Users of ARCH_ARM_* defines don't care about first vs. second arch,
set ARCH_ARM_* regardless of which arch is arm.
Change-Id: I2ae83ec5c3f839ff91a0e352c95d76ec2cbd5dc5
This adds a few missing font families to SDK system images.
This allows, in particular, support for the Korean language.
Note that this depends on other patches under device/generic/
to fix some board and product configuration files, otherwise
this change will have no effect.
See http://b.android.com/40340
Change-Id: Idba6471de32232833f511a4da97fd652906fec51
For whatever reason, two modules may have the same file as their
installed module. In that case circular dependency is created if the two
modules have requited-by relation.
Change-Id: I15ed271ca3f3c343e4662182ded5ccc63d6c42cc
Support any number of overlay packages. Support any target package.
UPDATED PACKAGE MATCHING
------------------------
In Runtime resource overlay, iteration 1, only a single overlay package
was considered. Package matching was based on file paths:
/vendor/overlay/system/framework-res.apk corresponded to
/system/framework-res.apk. Introduce a more flexible matching scheme
where any package is an overlay package if its manifest includes
<overlay targetPackage="com.target.package"/>
For security reasons, an overlay package must fulfill certain criteria
to take effect: see below.
THE IDMAP TOOL AND IDMAP FILES
------------------------------
Idmap files are created by the 'idmap' binary; idmap files must be
present when loading packages. For the Android system, Zygote calls
'idmap' as part of the resource pre-loading. For application packages,
'idmap' is invoked via 'installd' during package installation (similar
to 'dexopt').
UPDATED FLOW
------------
The following is an outline of the start-up sequences for the Android
system and Android apps. Steps marked with '+' are introduced by this
commit.
Zygote initialization
Initial AssetManager object created
+ idmap --scan creates idmaps for overlays targeting 'android', \
stores list of overlays in /data/resource-cache/overlays.list
AssetManager caches framework-res.apk
+ AssetManager caches overlay packages listed in overlays.list
Android boot
New AssetManager's ResTable acquired
AssetManager re-uses cached framework-res.apk
+ AssetManager re-uses cached 'android' overlays (if any)
App boot
ActivityThread prepares AssetManager to load app.apk
+ ActivityThread prepares AssetManager to load app overlays (if any)
New AssetManager's ResTable acquired as per Android boot
SECURITY
--------
Overlay packages are required to be pre-loaded (in /vendor/overlay).
These packages are trusted by definition. A future iteration of runtime
resource overlay may add support for downloaded overlays, which would
likely require target and overlay signatures match for the overlay to
be trusted.
LOOKUP PRIORITY
---------------
During resource lookup, packages are sequentially queried to provide a
best match, given the constraints of the current configuration. If any
package provide a better match than what has been found so far, it
replaces the previous match. The target package is always queried last.
When loading a package with more than one overlay, the order in which
the overlays are added become significant if several packages overlay
the same resource.
Had downloaded overlays been supported, the install time could have been
used to determine the load order. Regardless, for pre-installed
overlays, the install time is randomly determined by the order in which
the Package Manager locates the packages during initial boot. To support
a well-defined order, pre-installed overlay packages are expected to
define an additional 'priority' attribute in their <overlay> tags:
<overlay targetPackage="com.target.package" priority="1234"/>
Pre-installed overlays are loaded in order of their priority attributes,
sorted in ascending order.
Assigning the same priority to several overlays targeting the same base
package leads to undefined behaviour. It is the responsibility of the
vendor to avoid this.
The following example shows the ResTable and PackageGroups after loading
an application and two overlays. The resource lookup framework will
query the packages in the order C, B, A.
+------+------+- -+------+------+
| 0x01 | | ... | | 0x7f |
+------+------+- -+------+------+
| |
"android" Target package A
|
Pre-installed overlay B (priority 1)
|
Pre-installed overlay C (priority 2)
Change-Id: If49c963149369b1957f7d2303b3dd27f669ed24e
Colin Cross