Reason for revert: cache needs to be cleared on package install.
This is much simpler to do in internal master with recent changes
(ag/10172190) so I'm reverting the cache from aosp to keep it correct,
and cherrypicking this into internal master.
Change-Id: I71757a5b60fbdba3c69322b95a20527a1e3a66e9
Original commit:
[DexLoadReporter] Report classloader contexts directly from classloader
At the moment classloader contexts are incorrectly computed in the
PackageManager for secondary dex files. There are two issues:
(1) The wrong computed classLoaderContext will be reported for a secondary
dex file if it was loaded at the same time as a primary dex file
- This is due to the continue statement that doesn't increment
dexPathIndex
(2) If a secondary dex file was loaded with a shared library then that
shared library info isn't passed through the dex load reporting
infrastructure, and thus its classloader context is incorrectly computed
in PackageManager.
In order to fix the issues described above & prevent further classloader
context computation divergences between the package manager and the
runtime, lets compute the classloader context in the runtime at dex load
time and report the expected classloader context directly to
DexLoadReporter (and thus the package manager).
Notes: This is mostly just a refactor (i.e. there are a lot of line
changes, but functionally speaking this set of CLs doesn't do much
except change where the classloader context is computed)
Addendum: The bugs described above could also be fixed by:
- changing DexLoadReporter to report information about shared libraries that
the reported classloaders depend on to PackageManager
- Teach DexoptUtils.processContextForDexLoad about shared libraries
- Fix dexPathIndex calculation in DexManager
I opted for this set of changes instead because this reduces the
possibility of context computation divergence between the framework and the
runtime. Additionally it feels more "solid" that the classloader context
is now computed directly when a dex file is loaded, rather than the
context recreated later on in the PackageManager.
Test: atest com.android.server.pm.dex.DexManagerTests
Test: atest com.android.server.pm.PackageManagerServiceTest
Test: Install app depending on shared library & uses secondary dex
files; adb shell pm bg-dexopt-job; launch app and see odex file
successfully loaded (from smaps/no logcat errors)
Bug: 148494302
Exempt-From-Owner-Approval: This is a pure re-revert, previously owner approved.
Reason for revert: Re-land
Reverted Changes:
I295a6e99e:Revert "Fix shared libraries not being reported vi...
Ib58066e8f:Revert "[DexLoadReporter] Report classloader conte...
Change-Id: I8d1af791f93a3f8fa6eca78df50891cd2ebbb4a3
Revert "Fix shared libraries not being reported via Reporter"
Revert submission 1198456-slclc
Reason for revert: Fails on luci:
https://ci.chromium.org/p/art/builders/ci/host-x86_64-cdex-fast/3123
Exempt-From-Owner-Approval: pure revert
Bug: 148494302
Reverted Changes:
I46d8d9105: Fix shared libraries not being reported via Report...
I00357cfe0: [DexLoadReporter] Report classloader contexts dire...
Change-Id: Ib58066e8f059642a11d9eaab02ec0b8b3217e487
If both BaseBundles are empty, we can infer that without needing to
unparcel any of them.
Test: atest FrameworksCoreTests:android.os.BundleTest
Bug: 146037505
Change-Id: I04c28cdd1293227d9887b0c17e178f61328c1959
Merged-In: I04c28cdd1293227d9887b0c17e178f61328c1959
Cached call values are kept in ChangeIdStateCache (per-process cache).
Use "cache_key.is_compat_change_enabled" system property to
invalidate the cache (i.e. any value different from the last observed
will trigger an invalidation).
Any process can read that property, but only system server can change it.
Bug: 140441727
Test: atest PlatformCompatTest
Test: atest CompatConfigTest
Test: atest CompatChanges
Test: atest PlatformCompatGating
Change-Id: Ibed398ae965b7da2432aaf8d5ffc259f7d228c7e
At the moment classloader contexts are incorrectly computed in the
PackageManager for secondary dex files. There are two issues:
(1) The wrong computed classLoaderContext will be reported for a secondary
dex file if it was loaded at the same time as a primary dex file
- This is due to the continue statement that doesn't increment
dexPathIndex
(2) If a secondary dex file was loaded with a shared library then that
shared library info isn't passed through the dex load reporting
infrastructure, and thus its classloader context is incorrectly computed
in PackageManager.
In order to fix the issues described above & prevent further classloader
context computation divergences between the package manager and the
runtime, lets compute the classloader context in the runtime at dex load
time and report the expected classloader context directly to
DexLoadReporter (and thus the package manager).
Notes: This is mostly just a refactor (i.e. there are a lot of line
changes, but functionally speaking this set of CLs doesn't do much
except change where the classloader context is computed)
Addendum: The bugs described above could also be fixed by:
- changing DexLoadReporter to report information about shared libraries that
the reported classloaders depend on to PackageManager
- Teach DexoptUtils.processContextForDexLoad about shared libraries
- Fix dexPathIndex calculation in DexManager
I opted for this set of changes instead because this reduces the
possibility of context computation divergence between the framework and the
runtime. Additionally it feels more "solid" that the classloader context
is now computed directly when a dex file is loaded, rather than the
context recreated later on in the PackageManager.
Test: atest com.android.server.pm.dex.DexManagerTests
Test: atest com.android.server.pm.PackageManagerServiceTest
Test: Install app depending on shared library & uses secondary dex
files; adb shell pm bg-dexopt-job; launch app and see odex file
successfully loaded (from smaps/no logcat errors)
Bug: 148494302
Change-Id: I00357cfe086ff149f92c1078c6df6daa713c8f7c
The PropertyInvalidatedCache class provides a framework for caching
frequently-read, seldom-written information between processes.
Test: caching CLs
Test: atest FrameworksCoreSystemPropertiesTests
Bug: 140788621
(cherry picked from commit 06e9a4e01b)
Merged-In: I2d650129389e9567e4982b3a613fb8d1cbc97f4b
Change-Id: Ia03c2e6ab0ba0388ac729e5872795e25d06ee322
The tests included are unit tests for the implementation (under
FrameworksServicesTests), for the corresponding TestRule
(PlatformCompatGating) and CTS tests.
Bug: 137821288
Test: cd frameworks/base/core/java/android/app/compat && atest
Test: cd frameworks/base/services/core/java/com/android/server/compat \
&& atest
Change-Id: I1a652775715f1a9738cc72725303bc78dfa17d03
Since this was already a recurring pattern when using PlatformCompat
directly, clear calling id before binder calls in CompatChanges.
Bug: 149091690
Test: atest CtsAppCompatHostTestCases
Change-Id: I4eec315eba14b840f9ef222b81b624d8e4f201eb
Includes backend code to support LightsManager binder calls and route
them to the HALs.
Bug: 144979010
Bug: 144978691
Bug: 142715294
Change-Id: I0080972620ba7a3fb1197cdd0288287d3cfa8780
Fix: 142230898
Test: atest LightsManagerTest
Test: atest LightsServiceTest
Merged-In: I2db7f2caa432cd1e2389ea5ca6544200ada18675
