When there is overlay package in system_ext, turn on POLICY_SYSTEM_PARTITION.
In other words, overlay pacakge in /system_ext is considered as system's one
Test: mv vendor/overlay/framework-res__auto_generated_rro.apk system_ext/overlay
and then check if it works properly.
Bug: 136715327
Change-Id: Ib225368eae41203a8630f4310d26e9cf1afa706a
Merged-In: Ib225368eae41203a8630f4310d26e9cf1afa706a
(cherry picked from commit cba9579158cc70bf8eadb6e8a239e0ab2dc073d2)
Change idmap to iterate over the resources in the overlay package
instead of the target package when scanning for resources defined in
both packages. This cuts down the runtime cost of creating an idmap
considerably since the algorithm now scales with the number of resources
in the overlay package (a handful) and not the number of resources in
the target package (android: 10k, SystemUI: 8k) at a minor cost to code
complexity.
Improvements on the runtime of ResTable::createIdmap (systrace on an
emulator running aosp_x86_64-eng):
- target=android: 12.5 ms -> 3.0 ms
- target=SystemUI: 8.6 ms -> 1.0 ms
The bulk of the cost of creating an idmap from installd is now the fork
and execl to call "idmap --fd ..." which weigh in at 16 ms.
Bug: 80150169
Test: make libandroidfw_tests
Test: atest OverlayHostTests OverlayDeviceTests
Change-Id: I98e18d5958c0cd835a73055b714f5bf0f4f95a09
Prepare the idmap and asset managers for interfacing with idmap2 instead
of today's installd + idmap pipeline, but don't make the switch just
yet.
Instead, idmap2 runs as its own native daemon with an AIDL interface.
This removes the need for installd to fork and exec on each idmap call,
saving about 50 ms per call.
Bug: 78815803
Test: atest OverlayDeviceTests OverlayHostTests
Change-Id: I60852e15d99329896ff9de6559d1e7cd1c67e33d
See CL I7a6a30bf8e8db9f2738594d187bb9148f138b8da for a more detailed
description of the change.
Test: see CL I7a6a30bf8e8db9f2738594d187bb9148f138b8da description
Bug: 80741439
Change-Id: I6cc9d713c07c319fc2ee1c531af41243bd1d4aee
This CL will support the followings.
- installing a RRO package for framework from /product/overlay
- installing apps from /product/app
- installing priv-apps from /product/priv-app
- installing permissions from
/product/etc/[default-permissions|permissions|sysconfig]
Bug: 64195575
Test: `mm` under frameworks/base/tests/[libs|privapp]-permissions
adb sync && adb reboot
adb shell cmd package list libraries
=> confirmed com.android.test.libs.product library
adb shell cmd package dump \
com.android.framework.permission.privapp.tests.product
=> confirmed that the package is a priv-app
And I moved vendor/overlay/framework-res__auto_generated_rro.apk into
system/product/overlay/ on sailfish, and I confirmed that the RRO was
installed properly.
Change-Id: I16175933cebd9ec665d190cc5d564b5414a91827
It is now just a shell of itself. :)
Also brings in a few fixes to never try to open files from the system
process.
Test: manual
Change-Id: Ia8187196af597046fd2e7092dbf19ce1dc1ea457
We can use the new mechanism to ask the calling shell to open
a file in order to implement the rest of these commands, allowing
you to give the path to an apk to install. That API is thus
extended to allow you to open readable files, not just opening
file for writing.
Doing this however means we no longer can pass a file path to
AssetManager for the apk to parse, we only have an already open
fd for that. Extending AssetManager to allow adding apks from
fds is not that hard, however, since the underlying zip library
already supports this.
This main thing this changes is in AssetManager.cpp where we
retrieve the open zip file for a particular apk that has been
added. This used to look up the zip file by path every time
it was needed, but that won't work anymore now that we can have
things added by fd. Instead, we keep track of each opened zip
in the AssetManager, so we can just directly retrieve it from
the asset_path representing the item that was added. As a
side-effect, this means for normal paths we no longer need to
look up by name, but just have the opened zip file directly
accessible. (This is probably good, but it does mean that we
no longer run the logic of seeing if the zip file's timestamp
has changed and re-opening it if it has. We probably shouldn't
be relying on that for an active AssetManager anyway, and maybe
it is even good that we don't allow the zip file to change
under it?)
A follow-up change will finally remove the Pm.java implementation
and turn the pm "command" into a simple shell script that runs
cmd package.
Test: manual
Change-Id: Ie103e3bdaa5b706796cc329254f2638151a3924f
This reverts commit 2dc804be11444565e3d1d151c2a693db3ade94c0.
It also removes the related calls from UiModeManager.
Fixes: 32721178
Test: make & flash
Change-Id: Id371bccec611155cc6910e46b3277c3d27fc1c79
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'
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
Plug a memory leak in AssetManager::createIdmap.
Bug: 31052947
Test: use Valgrind and dummy native app
Change-Id: I83af3a40516ed2d50d5a7c8ee175ed960fde9933
This allows the overlay being used to be changed without a new build
but still will require a reboot to take effect. Should no longer be
needed once hierarchical resources are in place, and can be removed.
Also fix check in fd_utils to point at correct location.
Test: Manual
Bug: 32721178
Change-Id: I2a63aea0c87791c8eb845d735cb1182716c8174d
Fix a idmap leak in AssetManager::addSystemOverlays.
And, The fix could also prevent fd leak of idmap.
Test: none
Change-Id: Iff8831e1951a1ca103821f64a612a8b28d2c14e7
Signed-off-by: Hyangseok Chae <neo.chae@lge.com>
The name 'sku' does not fit well as we recommend to use the same
value for different SKUs if vendors wish to have the same colors
on those SKUs.
Bug: 32268656
Change-Id: Ib5e5a3386676453dafeb13a6a6bf91f81bb48a11
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
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.
Bug: 28032298
Change-Id: I51d39f121d207b11181340b68b164b60020f0c61
Remove a few vendor-related methods and fix comments
to no longer reference legacy concepts like vendor.
Change-Id: I61dbe53b6b305d8fb3468423462f5de2925b78bd
Test: dead-code removal, if builds, it works
A lot of the vendor/locale specific code existed pre-1.0
and was reworked into the current system.
Test: refactoring CL, all code except setLocale() was not being executed.
Test: setLocale() change tested manually
Change-Id: Ifb098f9808763a6cf5fb4336e089430adc09e198
The SharedZip's Asset is not thread-safety,the getResourceTableAsset()
and setResourceTableAsset(Asset* asset) function of the SharedZip is
not sync with a same lock.
Consider the following sequence of events:
Thread A calls setResourceTableAsset(Asset* asset),it will set
mResourceTableAsset = asset; then to calls getBuffer() of the asset.
Thread B calls getResourceTableAsset(),which return mResourceTableAsset,
then to calls getBuffer() of the mResourceTableAsset,the asset and
mResourceTableAsset is same one object.
Thread A to delete mZipInflater in getBuffer().
Thread B to delete mZipInflater in getBuffer().
It will cause crash becuase double delete mZipInflater in getBuffer().
https://code.google.com/p/android/issues/detail?id=211941
Bug:31734545
Change-Id: I5a7d67fdf64c4aa03f505b37a2fa840f4443d158
Signed-off-by: songjinshi <songjinshi@xiaomi.com>
See go/sku-colors. This changes the directory to search for framework
overlays if the right system property is defined. This allows
OEMs to specify different resources based on device SKUs.
Bug: 31692079
Change-Id: I9cb121b286b7f52aa26de1757fde1f3110cd47fd
The SharedZip's Asset is not thread-safety,the getResourceTableAsset()
and setResourceTableAsset(Asset* asset) function of the SharedZip is
not sync with a same lock.
Consider the following sequence of events:
Thread A calls setResourceTableAsset(Asset* asset),it will set
mResourceTableAsset = asset; then to calls getBuffer() of the asset.
Thread B calls getResourceTableAsset(),which return mResourceTableAsset,
then to calls getBuffer() of the mResourceTableAsset,the asset and
mResourceTableAsset is same one object.
Thread A to delete mZipInflater in getBuffer().
Thread B to delete mZipInflater in getBuffer().
It will cause crash becuase double delete mZipInflater in getBuffer().
https://code.google.com/p/android/issues/detail?id=211941
Change-Id: I5a7d67fdf64c4aa03f505b37a2fa840f4443d158
Signed-off-by: songjinshi <songjinshi@xiaomi.com>
Previously, if a mix of "fil" and "tl" resources existed in Resources
(from mixing resources from libraries for example), only resources
from one or the other would be chosen, resulting in default resources
getting surprisingly used. Now, we resolve the equivalent languages
at a per-resource levels (breaking ties for the identical code).
Also, previously if both "tl" and "fil" resources were present in
assets, getLocales() could return a list with duplicate locales.
This change removes Filipino duplicates in the return value of
AssetManager::getLocales().
Finally, there was a bug in the replacement of "tl" with "fil" that
considered any locale starting with the letter "tl" to be Tagalog.
This failed in case of various languages, including Klingon ("tlh")
and Tlingit ("tli"). It's now fixed.
Bug: 29073000
Change-Id: I0e8b9ae337ced2e640a2575897948c4c5ca307d3
Change the implementation of getLocales() to iterate the set of
configurations using a templated method, instead of using the result
of getConfigurations().
Also remove the check for AndroidManifest.xml when adding an asset path.
This is unneccessary.
Bug:28625993
Change-Id: I16de5da598d0c371421d1dc8eee054dce9baf53a
Also:
1. Add AssetManager method for finding non-system locales: This is
used in per-app locale negotiation. (Normally,
AssetManager#getLocales() returns both system and non-system
locales.)
2. Match pseudolocales correctly in locale negotiation.
Bug: 25800576
Bug: 26236938
Change-Id: I116caf3a91c290deb4ad68b291c65b7035b18dd4
- Added aapt command line flag --app-as-shared-lib to build app resources
that could be loaded as shared lib at runtime.
- Added new method AssetManager.addAssetPathAsSharedLibrary() to load an
app resource as shared library.
Bug 22487604
Change-Id: Ib9b33c35f9c2b7129f3ba205de03d4564623ea39
Now that ZipFileRO::startIteration supports prefix/suffix matching,
we can pass dirName to the function for simpler code and slightly
better performance.
(cherry-pick of c796ad0a8be6df4a3b354690dfe5ce1df8136c09)
Change-Id: I0e2ac58de28020c2af8d8e569a97592b09596185
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
(cherry picked from commit 4600dd053dbdbd4b95f3b11057a1cc55b99f9c77)
Change-Id: I7886cb37a229cc27c625699c80e6a6a6117d2203
