Bug: 148155907
Bug: 135299581
Test: Covered by CTS
We plan to remove Bitmap#createGraphicBufferHandle. Call the new
Bitmap#getHardwareBuffer instead.
Change-Id: I0b3ada9636fcc00df82472ea9479eb0bfbcda9eb
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
Feature is disabled on non-FBE devices since the profile user will
end up in RUNNING_UNLOCKED state.
Bug: 143516540
Test: atest com.android.server.devicepolicy.DevicePolicyManagerTest
Test: manual
Change-Id: Ib87492577b4e5153a8108036af89c547e4bb76ee
* changes:
Clear preferred activities affected by MIME groups changes
Implement new API to modify MIME groups by adding/removing MIME types
Add mimeGroup tag to intent filters
This change includes an AppOp that will be used to grant access to telephony call audio (RX and TX) to the default dialer application (assigned to the Dialer role).
A new permission was created so only apps that also require this permission will be granted. It will also be used to keep track of usage (audit).
Test: Compilation and manual verification
Bug: 135197853
Change-Id: I5d042f667ca5fe64f8048b8aff7b98f51b3c1500
Adds getThermalHeadroom, which allows users to determine how close the
device currently is to SEVERE thermal throttling. For intensive
applications which can scale their workloads, this allows them to help
manage the thermal envelope of the device.
Test: Manual, modify Filament test app to call and observe values
Test: PowerManagerTest#testGetThermalHeadroom
Test: atest android.os.cts.PowerManager_ThermalTest
Test: atest com.android.systemui.statusbar.phone.StatusBarTest
Test: atest CachedDeviceStateServiceTest
Test: atest AbstractAccessibilityServiceConnectionTest
Test: atest KeyEventDispatcherTest
Test: atest AttentionManagerServiceTest
Test: atest HdmiControlServiceTest
Test: atest ThermalManagerServiceTest
Test: atest RecoverySystemServiceTest
Bug: 136285293
Change-Id: I26e1c849c4b08cbf7ee0057f555cf0893750da43
Use the early TaskOrganizer concepts to implement Split-screen
in system-ui.
This includes changes to both FW and SystemUI. The changes to
FW involve removing the use of split-screen specific behavior (like
minimize dock and direct ordering) and also reducing things that
care about primary vs secondary. It also changed ActivityStack
to inherit bounds from parent** when in split-mode so that sysui
only needs to manipulate the tile and/or reparent stacks to
effect their geometry.
This means a lot of layout logic moves to SystemUI. The bulk of
the work done in ActivityStack which is split-screen related is
moved into SplitDisplayLayout. This basically takes a snapshot of
display configuration and manages the sizes of splits and their
snap targets.
Intermediate dragging of divider bar now only moves root task leashes
around rather than talking to WM. This includes position as well
as crop (which used to be stack crop). Once the user releases
the divider bar, it will calculate (based on snaps) the new
root task sizes and update their configurations via
WindowContainerTransaction. Because the interim updates are only
on the leashes, no configuration updates occur until the end.
Entering/Exiting split-mode is now handled by SplitScreentaskOrganizer#
onTaskInfoChanged. This is effectively a state-machine that
looks at the current split task membership vs. previous and then decides
when to move things into/out-of split tasks and how to coordinate with the
DividerView.
Minimized dock is relegated to a purely system-ui concept. To
accomplish this, **the home *stack* is set to the minimizedhomebounds
by systemui. This means that it's relative position to its parent is
negative! This allows us to leave the split sizes constant, have
their children inherit the "actual" split sizes, but keep the
home stack unchanging in its minimized size. We just adjust the crop
negative to reveal it.
IME handling is done through the same mechanism as app-driven IME
animation... only Divider receives the control instead of the app.
This allows synchronized animation of split tasks with IME. To
account for insets, though, when IME is opened, the bottom stack
will be repositioned in WM.
Bug: 133381284
Test: Manual, use split-screen, rotate device, launch unresizable
apps in split, use divider snap to close/maximize apps, etc.
Change-Id: I7133e151a1037c42b275b97857936437a7a6725f
Context.getSystemService() shouldn't return null, but sometimes we observer it.
Add WTFs to investigate it.
Bug: 149406139
Test: Boot with "adb logcat | grep -i wtf" and make sure no wtf is logged
Change-Id: I64c6776cedaeb534d98621db2955d585e6846b8d
Revert "Update CTS tests for tile-based split-screen"
Revert submission 9964969-sysui_split_screen
Reason for revert:
- Random SysUI crash (ag/10335781)
- Breaks IME tests with new_insets set to 2
- Crashes SysUI in split screen with new_insets set to 2.
Reverted Changes:
I103f68030: SystemUI Split via TaskOrganizer
If6740b7ee: Connect split-screen things to systemui divider
I44f497e7d: Update CTS tests for tile-based split-screen
Change-Id: Ife6878044ff19905ed97b599d8c67f80cb8e399e
... and any other display that isn't considered a public presentation
display, as per Display.isPublicPresentation()
Bug: 141745510
Test: atest CtsWindowManagerDeviceTestCases:PresentationTest
Change-Id: I2aaab1903dee54190338f7b6e49888aa51437108
MIME groups can now be modified via PackageManager.
MIME group modification will affect intent-filters
that were declared with that |mimeGroup| in manifest
in the same way, as if intent-filter was initially
declared with |mimeType| attributes that correspond to
MIME types in MIME group
Preferred activities will be handled in the next CL
Bug: 134736173
Bug: 136635677
Test: atest android.content.pm.PackageParserTest#testPackageWithIntentFilters*
Change-Id: I083a8794897e632aad5325a67311931193c69a3c
