When permission is granted to another app via URI, we implicitly grant
visibility to that app of the app ID that that URI resolves to.
Test: atest AppSecurityTests
Fixes: 149781706
Fixes: 145677500
Exempt-From-Owner-Approval: Owner approved prior to cherry-pick
Change-Id: I7c8967a4464fd821e4f95d8eb6c0bcfadadb912e
The ActivityTaskManagerTestService has a special method to start a
DreamActivity. This CL adds a verification check before the activity is
started to check that the caller is the currently active dream
component.
Bug: 133216167
Test: atest DreamManagerServiceTest
Merged-In: Id71b4cbc57c6569f58b6d906cc8361c104a507dc
Change-Id: Id71b4cbc57c6569f58b6d906cc8361c104a507dc
(cherry picked from commit 20dc51820a)
Currently, the DreamService uses a floating Window to display the
content of the dream on the screen. This introduces difficulties in the
interactions with the Assistant application, which is an activity.
By design, if the Assistant is invoked while the device is dreaming, the
Assistant should be shown on top. However, since floating windows are
always drawn on top of all activities, the Assistant can't be shown on
top of the Dream.
Here, we migrate the implementation of the DreamService to use an
Activity (DreamActivity). Since the screensaver application is not part
of the framework, we can't declare the activity in their AndroidManifest.xml.
Therefore, we start the dream activity with a dedicated method in
ActivityTaskManagerService.
Bug: 133216167
Test: 1. m && ./vendor/google/tools/flashall
2. Go to Settings > Device Preferences > Screensaver > Start now
3. Verify dream appears
4. Click any key to wake up the dream
5. Verify that dream disappears
Merged-In: I8dff0a124cd1b41fb925a73528305431b49ee06d
Change-Id: I8dff0a124cd1b41fb925a73528305431b49ee06d
(cherry picked from commit 148478a85e)
* changes:
Fix issues in register/unregister client API implementation
Add a TRM use case priority hints info object
Add requestFrontend implementation in TunerResourceManager
Implement TRM setFrontendInfoList logic with unit tests
The PackageSetting object is sometimes copied during
scan/install and will not match the reconciledPkg's pkgSetting.
This meant the usesLibrary parsing assigned the values to one
PackageSetting object, but dexopt read from the other, copied
object.
Unfortunately this copy logic leaves the two settings out of
sync and thus the isUpdatedSystemApp flag has to be copied
between them.
All of this would be great to resolve in a future refactor.
Bug: 150142306
Test: adb install -r {out_of_blueline_target}/product/app/CalculatorGooglePrebuilt/CalculatorGooglePrebuilt.apk
installs correctly, with dexopt run with the correct paths
Change-Id: Ifca3bafcea1b8858baf4a22ddd264d5e07a0f1e5
It was being removed from adb_temp_keys.xml but not adb_keys.
Bug: 150138676
Bug: 111434128
Test: atest AdbDebuggingManagerTest
Change-Id: I3c31394e4480e787c771e193b179a472d6ee4a62
Issues include:
1. clientId array size checking too hard
2. missed use case validation
3. missed in use resources update when unregistering client(same in on
binder dead, will be in separate CL)
4. Calling PID should have only be used when tvinputsession id is null
5. Adding resources list to client profile
Test: atest TunerResourceManagerServiceTest
Bug: 147380513
Change-Id: I09b4105659a491b3c07e3b737fe0617b83d24447
(cherry picked from commit 19b71275e0)
This object includes a parser that reads the vendor config xml
Test: atest UseCasePriorityHintsTest
Bug: 147380513
Change-Id: I4bff0bc196a0c2a78ce4305acec7ce7cc9a4fa70
(cherry picked from commit 2f62bf64ca)
Note that this CL includes some format changes and redundant
implementation removing in ClientProfile.java and
TunerResourceManagerService.java.
The key change of the CL is the FrontendResource.java object and
the impl of the setFrontendResourceList method in
TunerResourceManagerService.java.
Test: atest TunerResourceManagerServiceTest
Bug: 147380513
Change-Id: I3df8e386ad37bc67694594b07de04cc9f3b88e02
(cherry picked from commit caf201a8e7)
ApplicationInfo now automatically tries to "squash" the same instances in a
Parcel.
NOTE: This CL still does *not* optimize the package manager APIs that return a
list. e.g. PM.queryContentProviders() still return duplicate AppInfo's.
We can optimize them by making ParcelableListSlice call "allowSquashing",
but that *could* have negative side effects, so I'm not doing it in this CL.
I think we can do that for S.
Bug: 148588589
Test: atest CtsContentTestCases # except for two preexsiting failures:
- android.content.pm.cts.PackageManagerTest#testGetIcon
- android.content.pm.cts.PackageManagerTest#testGetPreferredActivities
Test: Use the debugger and make sure bindApplication() is not receiving
duplicate AppInfo's in the provider list.
Change-Id: I3ba2c047a469169340c0f75c36bdfd394bc5d627
(cherry picked from commit 7d09275d70)
The bounds animation is cleaned up within window manager and it's now
the SysUI component listening on callbacks from TaskOrganizer for
entering to and exiting from PiP mode.
Additionally, the expand and move of the PiP window is now part of SysUI
as well.
Known issues:
- Black background when in transition from PiP to fullscreen. The
wallpaper gets into hidden state too early
- App gets into PiP mode too early when entering PiP, need to defer the
configuration change sent to app in this case
Bug: 146594635
Bug: 148198539
Bug: 138144750
Bug: 149569903
Test: atest PinnedStackTests
Test: atest PipAnimationControllerTest
Test: atest RecentsAnimationTest
Test: atest RecentTasksTest
Test: atest com.android.server.wm.ActivityStarterTests
Merged-In: Id0c8ce03fa26952daf5e3687b18b2eb2375b7d20
Change-Id: Id0c8ce03fa26952daf5e3687b18b2eb2375b7d20
Change reduced scale implementation to toggle on/off based on
config_lowResTaskSnapshotScale=0 instead of ro.config.low_ram=true
Also, only use _reduced.jpg if reduced scale is enabled. Previously,
for task snapshots, [0-9]+_reduced.jpg would be used if reduced scale
was disabled, and [0-9]+.jpg would never be used. This patch swaps that
behavior to make the underlying system more intuitive. Now, if reduced
snapshots are disabled, store the task snapshot in [0-9]+.jpg and never
use [0-9]+_reduced.jpg.
Also, store low-res snapshots at config_lowResTaskSnapshotScale.
Prevously, low-res snapshots were stored at lowResScale * highResScale
Test: TaskSnapshotCacheTest
Test: TaskSnapshotControllerTest
Test: TaskSnapshotPersisterLoaderTest
Test: TaskSnapshotSurfaceTest
Bug: 148099851
Bug: 142063079
Change-Id: I5a0d58766347d875eaec138820323063aa1c2988
Store the original task snapshot size instead of the scale from which
the bitmap was saved. This simplifies the logic around restoring and
saving from the proto, as both the reduced scale and full scale
snapshots make use and share the same state.
Also remove scale from TaskSnapshot, and remove and reducedScale from
TaskSnapshot.Builder.
Test: TaskSnapshotCacheTest
Test: TaskSnapshotControllerTest
Test: TaskSnapshotPersisterLoaderTest
Test: TaskSnapshotSurfaceTest
Bug: 148491788
Bug: 148617404
Bug: 142063079
Change-Id: I1dccaba87c3d8b95bf4156f41f9fd5d40019f675
The DisplayContent was merging its transaction into the
RootWindowContainer's pendingTransaction. However, that transaction is
never applied so it was stuck in that transaction forever.
There's no need to merge to parent transaction when removing since
calling getPendingTransaction will already return the DisplayContent's
transaction.
Also added a forced Transaction.apply() when removing the DisplayContent
since there's a chance it may no be reachable when
performSurfacePlacement is called to apply all transactions.
Test: EncodeVirtualDisplayWithCompositionTest#testVirtualDisplayRecycles
No longer leaks SurfaceControls
Fixes: 149526716
Change-Id: I14aa5b2e0e14d75fb0285a1b7a511235064f621c
(cherry picked from commit 93938469fc)
We were passing "system" as the callingPackage argument when calling
registerUidObserver, which is apparently invalid. null is a valid option
here and seems to pin everything as expected, so this change updates
this call to avoid the SecurityException.
Note that this SecurityException does not seem to have affected the
actual pinning of the expected files - we still pin the same files
before and after this change.
Bug: 147355976
Test: No longer see the SecurityException at boot. Running dumpsys
pinner at boot shows that the same files are pinned as before this
change, including the Camera app but not including a Launcher app.
After using the four-corner tap to bypass the setup wizard, the Launcher
app is pinned. This indicates that the uid observer worked correctly to
re-pin the Launcher app after it replaces the setup wizard.
Change-Id: I2cd845cb5fad3de251d110141dcd1af9ec3aa234
Merged-In: I2cd845cb5fad3de251d110141dcd1af9ec3aa234
(cherry picked from commit 96f6b2d1d9)
Also did a small refactoring in computeOutcome() method to make it work
for cases when boot reason has a sub-reason, e.g.:
reboot,mount_userdata_failed,no_userdata_in_fstab.
Test: adb shell svc reboot userspace
Bug: 148767783
Change-Id: I13474d8a5be9382f56fdc8f17cf201666492e60d
KEYCODE_BACK was previously hardcoded as a wake key in KeyEvent.java.
For TV remotes, we want to make this behavior configurable.
Test: Tested on Android TV Device.
Bug: 144979700
Change-Id: I496c9c283525d5e04325e4bb3d6ab19a571db0c7
This reverts commit 288e1bd045.
The previous implementation of computeWindowInsets is to
use last view from WM#addView, which may be invalid because
the last added view is removed and throws NPE when getting
property from the invalid view.
In this CL, we change the approach to always obtain window
insets from server.
fixes: 148789183
fixes: 149480577
Test: atest FrameworksCoreTests:WindowMetricsTest
Test: atest WindowMetricsTests
Change-Id: I6db5970d14ac9eebe0ab0df65cb1300515ad1754
(cherry picked from commit 6bb2d4f68c)
Changing the checkpointing retry count to 2 resolves
issues of apex sessions being reverted if a hard reboot takes
place during a userspace reboot. Previously, a revert would
occur based on what stage of the boot sequence a hard reboot
took place in, now the revert will not occur at all.
Bug: 148270009
Test: atest ApexRollbackTests
Change-Id: Idce2d60f0a25f01a7d081420c937e5c9cec12e5d
In the cases that a logging parent cannot be found for any packages
in a rollback, the watchdog event should still be logged. Ensure
that the state of a rollback is captured on boot by removing the
condition of only saving a rollback id if there is a logging package,
and by adding a symbolic null package to the list of logging packages
on boot if none were found. Expand tests to verify.
Bug: 149957011
Test: atest StagedRollbackTest
Test: atest NetworkStagedRollbackTest
Change-Id: I56f8afb6730e59fbe67ea8747e0da3aca19a0d8a
