| 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
|