Session IDs are an implementation detail that the framework can (and should)
abstract away. This was previously reverted due to breaking master.
Test: adb shell am instrument -w -e package
com.android.server.locksettings.recoverablekeystore
com.android.frameworks.servicestests/android.support.test.runner.AndroidJUnitRunner
Change-Id: I4427c818348c054ada39d799b6da3b739f27eba9
Session IDs are an implementation detail that the framework can (and should)
abstract away.
Test: adb shell am instrument -w -e package
com.android.server.locksettings.recoverablekeystore
com.android.frameworks.servicestests/android.support.test.runner.AndroidJUnitRunner
Change-Id: Ieba641a9b54ac9bba197a6e9749b621a07e40c67
format of vault_handle
Test: adb shell am instrument -w -e package
com.android.server.locksettings.recoverablekeystore
com.android.frameworks.servicestests/android.support.test.runner.AndroidJUnitRunner
Change-Id: I105d17ac87b70795fa977b7649c7a1fdcb97b5e9
This introduces a more stable way of setting a remote animation
than using overridePendingTransition: An activity can register
a set of remote animations which is broke down by transition type.
Whenever the activity is involved into such a transition, the
remote animation will be started.
Remote animations take precedence over regular animations, and
prefixOrderIndex in the hierarchy decides precedence within
multiple apps that set remote animation definitions such that
higher apps override lower apps.
Bug: 64674361
Test: go/wm-smoke
Test: Use with launcher
Change-Id: Id300ff62d9f60966ea2609168f6a02860b3de7af
Allow client to add a description to a brightness
config and dump to dumpsys
Dump time and package name of system app that
set the last brightness config.
Bug: 71854421
Test: atest PersistentDataStoreTest
Test: manaual - check adb shell dumpsys display
Change-Id: I5ff0c0d3a4c5e30c9d4aa7eea850c7174ee20450
I will also rename RecoveryManager to RecoveryController -- in a separate CL,
as this one is already becoming too large.
Test: adb shell am instrument -w -e package
com.android.server.locksettings.recoverablekeystore
com.android.frameworks.servicestests/android.support.test.runner.AndroidJUnitRunner
Change-Id: I2fb4e1f55fb50d95f15c230783c3d289dd71f7f3
Adds the ability for another app to control an entire app
transition. It does so by creating an ActivityOptions object that
contains a RemoteAnimationAdapter object that describes how the
animation should be run: Along of some meta-data, this object
contains a callback that gets invoked from WM when the transition
is ready to be started.
Window manager supplies a list of RemoteAnimationApps into the
callback. Each app contains information about the app as well as
the animation leash. The controlling app can modify the leash like
any other surface, including the possibility to synchronize
updating the leash's surface properties with a frame to be drawn
using the Transaction.deferUntil API.
When the animation is done, the app can invoke the finished
callback to get WM out of the animating state, which will also
clean up any closing apps.
We use a timeout of 2000ms such that a buggy controlling app can
not break window manager forever (duration subject to change).
Test: go/wm-smoke
Test: RemoteAnimationControllerTest
Bug: 64674361
Change-Id: I34e0c9a91b28badebac74896f95c6390f1b947ab
This is a preparation for remote animations: We used to set app
visibility state immediately after we started the animation.
However, with remote animations, we'd like to allow them drawing
until the transition is done. For that, we defer hiding the client
until the animation is done.
Instead of special-casing remote animations, we do it for all
apps, as there is no harm in doing so.
Test: Open YouTube, make sure it enters Auto-PIP when pressing
home.
Test: go/wm-smoke
Test: Open trace with open/closing a couple of apps. Make sure
app visibility gets dispatched at the correct time.
Test: WindowStateTests
Bug: 64674361
Change-Id: I8deb6a97ca1c3d8f4a70a6e045f45a6bc16604bb
all forced app standby enabled except for when the device
is charging.
Bug: 69259147
Test: Manual test
Test: atest frameworks/base/services/tests/servicestests/src/com/android/server/ForceAppStandbyTrackerTest.java
Change-Id: Ica3fe6835958f186269413519ee82bc19fb83275
makeVisibleIfNeeded was recently modified to ensure activities
becoming visible were not left in the stopped state. However, the
condition was based on simply not being in the paused state, rather
than requiring it be in the stopped/stopping state. This can lead
to lifecycle issues for moving an initializing activity into the
paused state.
This changelist ensures that only stopped/stopping activities are
considered.
Change-Id: I17fc6310db6ee111d1db8f69599090becd1e1760
Fixes: 72028454
Test: atest FrameworksServicesTests:com.android.server.am.ActivityRecordTests
Changes of the SP are caused by untrusted credential reset which can be
triggered by certain admin modes. When such an admin is active, the SP
needs to be cached. Untrusted reset will be removed in a future release
at which point this caching can also be removed.
Bug: 71527305
Test: runtest frameworks-services -p com.android.server.locksettings
Test: cts-tradefed run cts-dev -m CtsDevicePolicyManagerTestCases -t com.android.cts.devicepolicy
Change-Id: I54f3b299b79ce019ba679b5550d37fd090b679fb
Replace the FLAG2_LAYOUT_IN_DISPLAY_CUTOUT flag with a
dedicated layoutInDisplayCutout field; given the change
in behavior of SYSTEM_UI_FLAG_LAYOUT_FULLSCREEN with respect
to the display cutout, apps that request this now also need
a way to request the same behavior as FLAG_FULLSCREEN.
Broadly, there's three categories of apps:
1) Apps that want to make dedicated use of the cutout
area -> no letterbox ever
2a) Apps that hide the status bar, but don't expect the
cutout to be there cutting into their content
-> we want those to get letterboxed
b) Some apps may only be transiently fullscreen, but always
want to get letterboxed
-> we want those to get letterboxed even if not currently
fullscreen
3) Apps that never go fullscreen, and just draw the status
bar background in the cutout area (i.e. the most common type
of app)
-> these need to get letterboxed whenever the cutout and
status bar don't coincide (under our current guidelines
that's only in fullscreen and landscape)
To cover each use case, we have:
ALWAYS: Always allow the app to draw into the cutout, never letterbox it; covers 1
NEVER: Never allow the app to draw into the cutout, always letterbox it; covers 2a and 2b
DEFAULT: Allow the app to draw into the cutout if that area is covered by the status bar
anyways. This does the right thing for most existing apps (2a and 3).
Bug: 65689439
Test: atest PhoneWindowManagerLayoutTest
Change-Id: Ib8d551251e9be4ef9d580ca2151bf40a9678acae
This CL is the last of the P1 CLs for binding on-demand. During
transport-usage migration to binding on-demand the permanent-bound
code was still there and we piggybacked on it to register the
transports. Now that everything is migrated we removed the permanent
binding and used the registration code created in the CL #9
(selectTransport) for registering all the transports.
I put a 3s delay on registration after bring-up. Any operation that uses
the transport before that will gracefully fail.
The TransportBoundListener does not return a boolean anymore because it
can't fail anymore (we pass it the data it needs so that it doesn't need
to be exposed to TransportNotRegistered exceptions). It's now called
OnTransportRegisteredListener.
Eligible transports were a similar thing to valid transports from the
permanent binding code, whose only need came from rebinding from what I
could tell. I saw no need for it anymore and removed it. If I missed
something please shout :)
I shuffled methods a bit in TransportManager.
There were a lot of changes to robo test infra to bring together
TransportManager tests and the rest and re-use mocking infra.
Change-Id: If61268228dd0bb724b718abd3dcafdad50e8b3dc
Ref: http://go/br-binding-on-demand
Bug: 17140907
Test: m -j RunFrameworksServicesRoboTest
Test: runtest -p com.android.server.backup frameworks-services
Test: gts-tradefed run commandAndExit gts-dev -m GtsBackupTestCases
Test: gts-tradefed run commandAndExit gts-dev -m GtsBackupHostTestCases
Test: cts-tradefed run commandAndExit cts-dev -m CtsBackupTestCases
Test: adb shell bmgr enable true/false
Test: adb shell bmgr list transports [-c]
Test: adb shell bmgr transport <transport_name>/-c <transport_component>
Test: adb shell bmgr restore <token>/<token> <package>/<package>
Test: adb shell bmgr backup <pacakge>
Test: adb shell bmgr run
Test: adb shell bmgr wipe <transport> <package>
Test: adb shell bmgr fullbackup <package>
Test: adb shell bmgr backupnow --all/<packages>
Test: adb shell cmd jobscheduler run -f android <job_id>
Test: adb shell dumpsys backup
Test: D2D scenario
The original implementation of object pool for lifecycle
transactions tried to always recycle objects after a
transaction was scheduled. In case when a client was running
in the same process this lead to objects being emptied before
it could actually perform the transaction.
Also when checking if object was already in the pool we should
use "==" instead of equality check.
Bug: 70554032
Bug: 71346774
Test: com.android.server.am.ClientLifecycleManagerTests
Test: android.app.servertransaction.ObjectPoolTests
Change-Id: I85fb3dae4589c2390e00a37144da0d285d16d151
Add a user restriction to allow profile owners to enforce a stronger
isolation of managed profile by preventing users sharing data into
the profile. This is achieved by disabling a subset of built-in cross
profile intent filters added by ManagedProvisioning during profile
inflation.
Implementation wise, DevicePolicyManagerService listens for the restriction
change and notifies ManagedProvisioning to modify the built-in intent
filters. This is needed since ManagedProvisioning has ground truth of all
built-in intent filters and manages them. It also has the advantage that
ManagedProvisioning only needs to run when a policy change happens.
Test: cts-tradefed run cts-dev -m CtsDevicePolicyManagerTestCases -t com.android.cts.devicepolicy.ManagedProfileTest#testDisallowSharingIntoProfileFromPersonal
Test: cts-tradefed run cts-dev -m CtsDevicePolicyManagerTestCases -t com.android.cts.devicepolicy.ManagedProfileTest#testDisallowSharingIntoProfileFromProfile
Bug: 63911046
Change-Id: Ia6d12a5086627d1280325cd19d6e3a0752dae633
- Removed START_USER_IN_BACKGROUND in createAndMaangeUser
- Added startUserInBackground that can return whether user is started. It checks for whether more users can be started without stopping existing users.
- Added canStartMoreUsers in UserController and ActivityManagerService
- Updated javadoc of a few user management API in DevicePolicyManager
- In UserController.startUser, return false if maximum running user limit is reached when starting user in background
- Only stop guest or ephemeral user that is being switched out in stopGuestOrEphemeralUserIfBackground
Bug: 71694116
Test: Create 3 ephemeral users, can startUserInBackground for first two but failed for the third.
Test: Switch to first user, second user is not affected.
Test: Switch out first user, second and third user is not affected. Can startUserInBackground for third user at this point.
Change-Id: I46aa1d8788851b10b5b169ac656cb982791de479
The change is based on API review.
1) package and class names update
2) Builders for Parcelables.
3) Use Constant for RECOVER_KEYSTORE permission defined in
android.Manifest.
Bug: 66499222
Test: adb shell am instrument -w -e package \
com.android.server.locksettings.recoverablekeystore \
com.android.frameworks.servicestests/android.support.test.runner.AndroidJUnitRunner
Change-Id: I49f80acbb6dc0eb6d049e18e8cb0d1aa326dadb2
