History log of /frameworks/base/cmds/idmap/scan.cpp
Revision Date Author Comments (<<< Hide modified files) (Show modified files >>>)
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