d5566c6c47faa6b9dda282741e25ac78c9487d58 |
|
16-Mar-2017 |
Todd Lee <leetodd@google.com> |
OEM single-build/multi-SKU via dynamic RRO support The purpose here is to provide support for selectively enabling Runtime Resource Overlays (RROs) (specifically those pertaining to a specific SKU, within a OEM's "single build" covering multiple SKUs) at boot based on the value of a pre-defined system property. This mechanism is designed to be compatible with other, recent changes to Runtime Resource Overlays - specifically: - has no effect on 'isStatic'. Resource overlays must be attributed as static in order to qualify for loading into the system_server. The 'requiredSystemPropertyName/ requiredSystemPropertyValue' mechanism operates independent of this and can be used on both static and non static overlays. The effect of specifying a conditional property on any overlay is that it will ONLY be enabled in the event that the system reflects both the property and the specified value (Note that in the ABSENCE of a conditional property, overlays are assumed to be enabled). - has no effect on OverlayManagerService (OMS) API. The OMS provides the system with an interface through which overlays can be enabled/disabled and even rearranged at runtime. This provides the basis of support for various user-level features (e.g. dynamic theme selection). The 'requiredSystemPropertyName/requiredSystemPropertyValue' mechanism operates independent of this - with enablement being completely coupled to the available system properties on the device and NOT subject to change at runtime. Note: as part of this change, original overlay tests have been updated (fixed) and expanded to include tests to cover the conditional property implementation. Issue: http://b/35100249 Test: frameworks/base/core/tests/overlaytests/testrunner.py Change-Id: I1990ce21a27a385db1e2f53294b69dd03988351e
/frameworks/base/cmds/idmap/scan.cpp
|
0434289c45bc18f81f26d66e6bcbf8facf128665 |
|
02-Mar-2017 |
Jaekyun Seok <jaekyun@google.com> |
Apply static RRO Static RRO package is designed to support resource overlay for system server and they shouldn't be disabled or changed by a user. The design details are in go/treble-static-rro. Selection method for static RROs will be applied later when its design is determined. Test: building succeeded and tested on sailfish. Bug: 35742444 Change-Id: I8cbf2fd37a73a24bf6ad291e2c5cf75a0fc757fc
/frameworks/base/cmds/idmap/scan.cpp
|
7de2f9c73fbe93bfb7dff3c046cf7a3137599f6c |
|
01-Mar-2017 |
Jaekyun Seok <jaekyun@google.com> |
Reinstate codes to enable RRO on system server Test: building succeeded and tested with sailfish Bug: 35742444 Change-Id: I99d0f1d097525d3eb46255d6cf823f6ae2a02385
/frameworks/base/cmds/idmap/scan.cpp
|
2e0d0f311100d8e0bb40d7d60b8498237f011f0c |
|
02-Jun-2016 |
Mårten Kongstad <marten.kongstad@sonymobile.com> |
OMS: integrate OverlayManagerService into framework Hand over ownership of overlays to OverlayManagerService. Changes to a package's overlays are propagated using the activity life cycle. Affected activities will be recreated as needed. This provides a well-defined point to modify an application's assets while the application is paused. Consolidate how overlays targeting the system and overlays targeting regular applications are handled. Previously, system overlays were handled as a special case. Now, everything is handled identically. As a side effect, the call to idmap --scan during Zygote boot has become obsolete and is removed. Information on what overlays to use is recorded in ApplicationInfo.resourceDirs. The PackageManagerService is responsible for the creation of ApplicationInfo objects. The OverlayManagerService is responsible for informing the PackageManagerService in advance about what resourceDirs to use. When launching an application, the ApplicationInfo is already populated with up-to-date information about overlays. When enabling or disabling an overlay for a running application, the OverlayManagerService first notifies the PackageManagerService about the updated resourceDirs. It then tells the ActivityManagerService to push the new ApplicationInfo object to the application's ActivityThread. Finally the application requests its ResourcesManager to create new ResourcesImpl objects based on the updated paths. Change-Id: Ib8afa05ccab4e2db558f89ce4423983c086bb61a Co-authored-by: Martin Wallgren <martin.wallgren@sonymobile.com> Signed-off-by: Zoran Jovanovic <zoran.jovanovic@sonymobile.com> Bug: 31052947 Test: run tests from 'OMS: tests for OverlayManagerService'
/frameworks/base/cmds/idmap/scan.cpp
|
95459806920dec34abb3214ab6e1a9b9213a2a61 |
|
23-Feb-2017 |
Guang Zhu <guangzhu@google.com> |
Revert "OMS: integrate OverlayManagerService into framework" Bug: 31052947 Bug: 35697944 This reverts commit 21a3d1ad686dee97b9cf0ed80389ee2ab0d48013. Change-Id: I2d86931020301524c26cf8c8e80d557c97fdd6c3
/frameworks/base/cmds/idmap/scan.cpp
|
21a3d1ad686dee97b9cf0ed80389ee2ab0d48013 |
|
02-Jun-2016 |
Mårten Kongstad <marten.kongstad@sonymobile.com> |
OMS: integrate OverlayManagerService into framework Hand over ownership of overlays to OverlayManagerService. Changes to a package's overlays are propagated using the activity life cycle. Affected activities will be recreated as needed. This provides a well-defined point to modify an application's assets while the application is paused. Consolidate how overlays targeting the system and overlays targeting regular applications are handled. Previously, system overlays were handled as a special case. Now, everything is handled identically. As a side effect, the call to idmap --scan during Zygote boot has become obsolete and is removed. Information on what overlays to use is recorded in ApplicationInfo.resourceDirs. The PackageManagerService is responsible for the creation of ApplicationInfo objects. The OverlayManagerService is responsible for informing the PackageManagerService in advance about what resourceDirs to use. When launching an application, the ApplicationInfo is already populated with up-to-date information about overlays. When enabling or disabling an overlay for a running application, the OverlayManagerService first notifies the PackageManagerService about the updated resourceDirs. It then tells the ActivityManagerService to push the new ApplicationInfo object to the application's ActivityThread. Finally the application requests its ResourcesManager to create new ResourcesImpl objects based on the updated paths. Co-authored-by: Martin Wallgren <martin.wallgren@sonymobile.com> Signed-off-by: Zoran Jovanovic <zoran.jovanovic@sonymobile.com> Bug: 31052947 Test: run tests from 'OMS: tests for OverlayManagerService' Change-Id: Idc96dae6fc075d5373aa055bbf50e919136d7353
/frameworks/base/cmds/idmap/scan.cpp
|
0fbb60811076e6fcfd576287b6e6a16ac1a69c44 |
|
11-Aug-2015 |
Martin Wallgren <martin.wallgren@sonymobile.com> |
RRO: Synchronize access to overlays.list idmap --scan is executed as a part of the pre-loading in ZygoteInit. The pre loading is executed in parallel for each supported architecture (32/64 bit). This will cause a race condition in the creation of the overlays.list file and the idmap files for the system overlays. Apply flock on overlays.list to prevent the file from being thrown away and recreated when it is in use by another Zygote. Cherry-picked from AOSP. Bug: 28032298 Test: manual Change-Id: I51d39f121d207b11181340b68b164b60020f0c61
/frameworks/base/cmds/idmap/scan.cpp
|
0881a7445f9106e835486c5a697c01f4f18e619b |
|
05-Nov-2015 |
Dan Albert <danalbert@google.com> |
Use std::unique_ptr instead of UniquePtr. We're deprecating UniquePtr, so we need to move to the real thing. Bug: http://b/22403888 Change-Id: I5b7fdf4924dd8c12a8c7dba89278714ca6fdc60a (cherry picked from commit b0624da1181276ff4caa5e57a7a4abf766902e3e)
/frameworks/base/cmds/idmap/scan.cpp
|
bac309ca8f4ecd1a835aa36f4be2a1fa45577eab |
|
12-Oct-2015 |
Adam Lesinski <adamlesinski@google.com> |
Merge "RRO: idmap: fix sorting of overlays.list"
|
7197d91eb7dfbd0f5b065b56d4f391019e71d03a |
|
18-Mar-2015 |
Mårten Kongstad <marten.kongstad@sonymobile.com> |
RRO: idmap: fix sorting of overlays.list Multiple overlay packages with targetPackage="android" are loaded in the wrong order due to the incorrect order they are listed in overlays.list. This will cause runtime resource overlay to fail when multiple overlay packages target the same resources in framework-res.apk. Correct the order in which overlays are loaded by changing the sorting of overlays.list. Background: commit f90f2f8d changed the order in which overlay packages should be added to ResTables. The expected order is now in ascending priority. This must be reflected in overlays.list. Change-Id: I249984c0e34b6009e7280ce2777750c76ab16e37
/frameworks/base/cmds/idmap/scan.cpp
|
83ab0d7c1824f3a29e41af8a95a954c73f48c287 |
|
20-Mar-2015 |
Mårten Kongstad <marten.kongstad@sonymobile.com> |
Make 'idmap --scan' accept more than one input directory The 'idmap --scan' command was limited to only scan a single directory for overlay packages. Update idmap to support any number of directories. Change-Id: I851f5720a3c1d844235911a0833670652a20a3c8
/frameworks/base/cmds/idmap/scan.cpp
|
4600dd053dbdbd4b95f3b11057a1cc55b99f9c77 |
|
16-Jun-2015 |
Narayan Kamath <narayan@google.com> |
ZipFileRO: Use precise widths for zip file types. getEntryInfo crashes on 64-bit devices because "long" types were being passed int pointers (that pointed to a stack frame) that were reinterpret_cast'ed to long* (sigh.). To fix this issue once and for all, use types with explicitly defined widths. This change also removes some dead invariant checking from Asset.cpp instead of cleaning it up. Note that we've introduced a wart in NativeLibraryHelper, where we need to deal with zlib's uLong type, which is "at least 32 bits wide". bug: 21622286 Change-Id: Iae675a9601db7aae03a8b80b40321d2cc1d97f50
/frameworks/base/cmds/idmap/scan.cpp
|
b62286e60c079936a5f1e5b0befd32d2d9bf1b3f |
|
01-Apr-2015 |
Mark Salyzyn <salyzyn@google.com> |
idmap: scan missing include for sys/stat.h scan.cpp gets sys/stat.h inherited from private/android_filesystem_config.h it should not rely on this in the future. The intent is to move fs_config function into libcutils and thus deprecate any need for sys/stat.h in this include file. Bug: 19908228 Change-Id: If547e86513b06c536972138ae571c3d9c714ffe9
/frameworks/base/cmds/idmap/scan.cpp
|
688ff4cf0f93d1a886437884f23874e5595d59a3 |
|
23-Feb-2015 |
Narayan Kamath <narayan@google.com> |
Track removal of refcounts from FileMap. Use delete instead of release. Change-Id: I25c841b368aa9d51e9259399b94cafa2bbb7a076
/frameworks/base/cmds/idmap/scan.cpp
|
46c82b4cd241a447834ed2f5a6be16777b7a990b |
|
30-Nov-2014 |
Bernhard Rosenkränzer <Bernhard.Rosenkranzer@linaro.org> |
Adjust format strings to work on both 32-bit and 64-bit builds Adjust format strings to not produce Clang warnings in both 32-bit and 64-bit builds Change-Id: I76c29d8d5d0fb4b5e9d9518077652370ffe9e871 Signed-off-by: Bernhard Rosenkränzer <Bernhard.Rosenkranzer@linaro.org>
/frameworks/base/cmds/idmap/scan.cpp
|
6698749dd4d4d6513b26aa9071af290b956b68a7 |
|
20-Nov-2014 |
Dan Albert <danalbert@google.com> |
Add appropriate casts for char16_t. C++11 defines a real char16_t, which is not implicitly convertible to uint16_t (and by extension jchar). Add casts as needed. Bug: 18300613 Change-Id: I00752002ef2e938bdb57f70947e8fd53ec103293
/frameworks/base/cmds/idmap/scan.cpp
|
cfedceb8c180a2e176154d461659e0c3569dc931 |
|
01-Oct-2014 |
Andreas Gampe <agampe@google.com> |
Frameworks/base: Turn on -Wall -Werror in cmds Fix small warnings, turn on -Wall -Werror. Change-Id: Iab1f01a7c7ebd6ba832b75067c5e395f380a1b8b
/frameworks/base/cmds/idmap/scan.cpp
|
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/cmds/idmap/scan.cpp
|
13221c9cffdb289851411bdc73a9a5236fcb9291 |
|
12-Feb-2014 |
Colin Cross <ccross@android.com> |
frameworks/base: move idmap from frameworks/native idmap depends on libandroidfw, so it should go in frameworks/base. Change-Id: I3c1db3baa355f53d6b523d60f4377e63eff00c30
/frameworks/base/cmds/idmap/scan.cpp
|