When unlocking orientation on the same frame as a rotation takes place
(example: orientation is locked to landscape, but phone is physically
oriented to portrait), onConfigurationChange is not invoked, and so
Global Actions is positioned as if it were in the locked orientation,
even though it has been rotated.
We work around this by post()ing the rotation unlock, so that it
happens on the next frame, at which point onConfigurationChange is
correctly invoked and the layout is re-oriented properly.
Fixes: 132581161
Test: manual
Change-Id: I1c11844e24bea115f9f44560fef8db863d19d7af
- Setup wizard used to finish itself and start home automatically, but now
we have the Tips app show afterwards which requires the user to swipe
up to go home as a part of learning the gesture. Previously that would
have created the home task for the secondary user and subsequent swipes
would work, but in the new flow, the creation of the secondary user
home task would never happen because the recents animation logic tries
to find the primary user's home task. This is only an issue on the first
launch for the secondary user, subsequent launches after completing SUW
will start home as a part of switching users.
This change ensures that we account for the user when trying to resolve
an existing target activity.
Bug: 132410734
Test: atest RecentsAnimationTest
Change-Id: If14ad535948c5aadd83af528592b320dba62c40e
After we stage a session for rollback, we need to wait for the
session to be ready and then reboot. To ensure we don't miss the
ready signal, we register a BroadcastReceiver to listen to session changes
and also check for session ready right away. This caused a race condition
where we may handle post-ready twice. This caused a crash because we
attempt to unregister the receiver twice, it's also a problem because
we could log the same event twice.
Now, we store the rollback ids we are about to handle and ensure we never
handle post-ready more than once.
Test: Manual test && atest StagedRollbackTest
Bug: 132866890
Change-Id: I5187ff20fb83b29f7a00a28bf6ad8105ca4f0067
Now that we have LocalCallingIdentity, we can start caching it in
very narrow cases. We must be careful to not cache too long, since
any changes to granted permissions for the UID mean we need to
re-evaluate any cached answers.
The best middle-ground for this in the Q release is to use an active
camera session as a proxy for when we should create a cache object
and then later invalidate it. (It's very unlikely that a user
changes permissions while actively using the camera, and this is
a strong signal that the caller is sensitive to performance.)
Many other sprinkled optimizations to avoid extra binder calls into
the OS, such as aggressively caching VolumeInfo related details.
Track IDs that are owned by each LocalCallingIdentity, to speed up
all future security checks.
Dispatch all change notifications asynchronously, and delay them by
several seconds while the camera is being actively used, to give
more important foreground work a fighting chance. Invalidate
thumbnails asynchronously.
Optimizations to ModernMediaScanner where it's safe to skip the
"reconcile" and "clean" steps when we're focused on a single file
that we successfully scanned.
Local tests show this CL improves performance of a test app that
takes 100 rapid shots by 45%. (All the collective optimizations
done so far this week add up to a 70% improvement.)
Bug: 130758409
Test: atest --test-mapping packages/providers/MediaProvider
Exempt-From-Owner-Approval: trivial manifest change
Change-Id: I38cc826af47d41219ef44eae6fbd293caa0c01d5
am: 3469404de1 -s ours
am skip reason: change_id Ic10931b7fab998bfebe09d316a2d87886222dae3 with SHA1 4c11809764 is in history
Change-Id: Ie66d2848b4bcde00c01648c6f7ca565accb8baee
