This extra is not exposed and is not used by anyone as such.
Leaving it there for internal use/unsupported app usage.
Test: basic sanity
Bug: 140908357
Merged-in: I9fe6e904291affb1cd7b705212d47525b61a5679
Change-Id: I9fe6e904291affb1cd7b705212d47525b61a5679
(cherry picked from commit bb61b17cd9)
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
This change adds a feature flag that specifies the date associated
with the Vulkan dEQP tests that a device claims to pass.
Bug: 136573508
Change-Id: I0cec29fe5f69f228faaa2298b7f5b65bcf988dba
Merged-In: I0cec29fe5f69f228faaa2298b7f5b65bcf988dba
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
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
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
Ethernet tethering can be started via
startTethering(TETHERING_ETHERNET).
Test: flashed, enabled ethernet tethering, verified internet access on
downstream.
Bug: 130840861
Merged-In: I34842acd94b972e440c3622f7617df10c18acf65
Change-Id: I34842acd94b972e440c3622f7617df10c18acf65
(cherry-pick with conflicts in test-current.txt)
This change adds the VpnManager, which will be used by apps to install
profiles for all platform VPN types (currently only IKEv2).
Bug: 143325939
Test: Compiles, FrameworksNetTests passing.
Change-Id: I57f854d0a5b18358f3541c24ca0cd8aed03fd7a1
ConnectivityDiagnosticsManager should be accessed through
Context#getService. In order for this to be possible, it needs to be
defined as a service inside SystemServiceRegistry.
Bug: 146444622
Test: compiles.
Test: CTS testing in aosp/1211164
Change-Id: I6fe29441ecc9967a04ceb394b3bbe54830bef079
The service is already registered in ServiceManager. It needs to be
accessible from SystemServiceRegistry so that other mainline modules
can communicate with it.
Bug: 147255753
Test: Dependent CLs using the service
Change-Id: I940c62064466c3b3b8d2a195b810e90eaade7e6c
Merged-In: I940c62064466c3b3b8d2a195b810e90eaade7e6c
Existing annotations in libcore/ and frameworks/ will deleted after the migration. This also means that any java library that compiles @UnsupportedAppUsage requires a direct dependency on "unsupportedappusage" java_library.
Bug: 145132366
Test: m && diff unsupportedappusage_index.csv
Change-Id: I6ab53570aca580fbee1fcc927871caa09780f58f
Merged-In: I6ab53570aca580fbee1fcc927871caa09780f58f
This is to fix an issue when calling getUser for a context that
is different than the context of the current foreground user.
getUser for a ContextWrapper would call the base
class Context#getUser which returns the user of the current foreground
process rather than returning the user of the calling context.
Currently, this is a bug that does not meet the ContextWrapper class Javadoc.
It looks like the ContextWrapper call was missed in Ib772ec4438e57a2ad4950821b9432f9842998451.
Fix: 144024489
Test: called the API from a test App with a different context than the
current application context.
Change-Id: I58ec9fda24bf135ba8c648a905ef0c81d36ea098
Merged-In: I2d24f5141e8cbc2546c8dc5894a1aeab376b7632
(cherry-pick from ag/9673528)
Includes Context.NETWORK_POLICY_SERVICE into system API
so that system apps(including mainline modules) could
obtain the service.
Bug: 138306002
Test: FrameworksNetTests
FrameworksTelephonyTests
Change-Id: I3f751b14e55969952c69b33c97ef86d859cef8b5
Move tethering out of ConnectivityService. All client would
use TetheringManager to talk with TetheringService directly.
Bug: 144320246
Test: -build, flash, boot
-atest TetheringTests
Change-Id: Ib051bea724a256f9c4572b566e46ae7b9c4abe6e
Merged-In: Ib051bea724a256f9c4572b566e46ae7b9c4abe6e
Expose the string IccCardConstants as system APIs
Use TelephonyManger.SIM_STATE_XXX for remaining
Bug: 145767148
Test: Build
Change-Id: I5711d783be8c8414b8f9d7baa80cb4224bd771aa
Add a new time zone detection service. Much of the code is from
frameworks/opt/telephony with some changes for naming, threading and
to modify the interaction with the "Callback" class.
Overall goal:
Implementing the service in the system server means it will be easier to
add new time zone detection logic unrelated to telephony in future.
Bug: 140712361
Test: atest com.android.server.timezonedetector
Test: atest android.app.timezonedetector
Change-Id: I89505fc4fecbd3667b60f8e1479b8f177eaa60ae
Merged-In: I89505fc4fecbd3667b60f8e1479b8f177eaa60ae
(cherry picked from commit 3e3b5405b6)
with appOp as String and options as Bundle
Bug: 139077993
Test: Build, GsmInboundSmsHandlerTest, CdmaInboundSmsHandlerTest and WapPushOverSmsTest
Change-Id: I60e21c7202d1bc7c5d28dfad2e2edde902f28a15
Merged-In: I60e21c7202d1bc7c5d28dfad2e2edde902f28a15
The parcelable is misused as generic type,
even though AIDL compiler have not supported it yet.
So, turn on generic in this type.
Test: m
Bug: 145275738
Change-Id: If1f6e3238511439f1aca7b13b945be5998d04045
Context.registerReceiverForAllUsers are already marked as @SystemApi.
The same method in ContextWrapper overriding it doesn't need to be
annotated as such. In fact, that API is even not recorded in
system-current.txt.
Bug: 144424011
Test: atest CtsSystemApiAnnotationTestCases
Merged-In: I60890104bf20a2c674edd91ec6b487cca1b4e37b
Change-Id: I60890104bf20a2c674edd91ec6b487cca1b4e37b
