7df3625d5bb28d11cce9ac23429f5e3c6ebac030 |
|
16-Jan-2014 |
Martin Kosiba <mkosiba@google.com> |
Allow for appending of resources to an AssetManager. BUG: 11505352 Change-Id: Ifa290580a6dc63c2f471d0bbf5f066db14aed4d7
/frameworks/base/include/androidfw/AssetManager.h
|
de898ff42912bd7ca1bfb099cd439562496765a4 |
|
30-Jan-2014 |
Adam Lesinski <adamlesinski@google.com> |
Shared library resource support Shared libraries can now export resources for applications to use. Exporting resources works the same way the framework exports resources, by defining the public symbols in res/values/public.xml. Building a shared library requires aapt to be invoked with the --shared-lib option. Shared libraries will be assigned a package ID of 0x00 at build-time. At runtime, all loaded shared libraries will be assigned a new package ID. Currently, shared libraries should not import other shared libraries, as those dependencies will not be loaded at runtime. At runtime, reflection is used to update the package ID of resource symbols in the shared library's R class file. The package name of the R class file is assumed to be the same as the shared library's package name declared in its manifest. This will be customizable in a future commit. See /tests/SharedLibrary/ for examples of a shared library and its client. Bug:12724178 Change-Id: I60c0cb8ab87849f8f8a1a13431562fe8603020a7
/frameworks/base/include/androidfw/AssetManager.h
|
1cbea39fe1740d7d1c3e4aa0e4771a99a56c79ef |
|
12-Feb-2014 |
Nick Kralevich <nnk@google.com> |
resolved conflicts for merge of dd3d95f1 to klp-volantis-dev Change-Id: I96c0f0da852a0b3cf8aef9158678d38aa30f456f
|
d9e385b111ebf811beb0f29178a2fbd4d667509f |
|
11-Feb-2014 |
Dianne Hackborn <hackbod@google.com> |
Fix build. At least part of what is broken. Other stuff still seems to be. Change-Id: I367dc0377bd5b4e59d9d9b68f3506bf1d64aa591 (cherry picked from commit 32bb5fae353b5bb6275e75952e89c514c7369cee)
/frameworks/base/include/androidfw/AssetManager.h
|
48d22323ce39f9aab003dce74456889b6414af55 |
|
31-Jan-2014 |
Mårten Kongstad <marten.kongstad@sonymobile.com> |
Runtime resource overlay, iteration 2 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
/frameworks/base/include/androidfw/AssetManager.h
|
65a05fd56dbc9fd9c2511a97f49c445a748fb3c5 |
|
31-Jan-2014 |
Mårten Kongstad <marten.kongstad@sonymobile.com> |
New command line tool 'idmap' Introduce a new tool 'idmap' to handle generation and verification of idmap files. The tool is modelled on 'dexopt', and is intended to be used similarly, notably by 'installd'. See cmds/idmap/idmap.cpp for further documentation on 'idmap'. Note: this commit is interdependent on a commit in project build/ to add 'idmap' to PRODUCT_PACKAGES. Note: the changes to androidfw are only stubs. The actual implementation will be provided in Runtime resource overlay, iteration 2. Change-Id: I7131b74ece1e46c8a9c0a31d103e686aa07da2bb
/frameworks/base/include/androidfw/AssetManager.h
|
745d4efc8369d255341d810790132660e33d3b61 |
|
27-Jan-2014 |
Narayan Kamath <narayan@google.com> |
AssetManager cookies should be int32_t and not void*. Cookies are really indices into vectors and arrays, so they don't need to be void*. We choose int32_t instead of size_t to allow their width to be well specified. (cherry picked from commit ebfdd0f467e39c3af8d92cade78263935340acb7) (cherry picked from commit a7fa2e592e2e579e5acdb903dba83fc074ebc215) (cherry picked from commit a9d5701b034ed2d9771b3f0943e1add00741d7cd) Change-Id: I2aed3db568b6fdc487bf99e2c5dd123206736fda
/frameworks/base/include/androidfw/AssetManager.h
|
1f5762e646bed2290934280464832782766ee68e |
|
07-May-2013 |
Mathias Agopian <mathias@google.com> |
libutils clean-up Change-Id: I11ee943da23a66828455a9770fc3c5ceb4bbcaa9
/frameworks/base/include/androidfw/AssetManager.h
|
a982dc05d7ca919c07f50e446549ef9dceadf6bd |
|
23-Mar-2012 |
Colin Cross <ccross@android.com> |
frameworks/base: move Zip* from libandroidfw to libutils ZipUtils is needed by build/tools, move it from libandroidfw (frameworks/base) to libutils (frameworks/native). Change-Id: I2b4b7adcdf68eb25ee7cba5dd3b69eadf0523af3
/frameworks/base/include/androidfw/AssetManager.h
|
b13b9bdad2baf6ad1ec2e56b6b7598fa20f55fc4 |
|
18-Feb-2012 |
Mathias Agopian <mathias@google.com> |
frameworks/base refactoring. step 2: move libutils headers to their new home: androidfw Change-Id: I14624ba23db92a81f2cb929f104386e1fab293ef
/frameworks/base/include/androidfw/AssetManager.h
|