- Scrims: When dismissing Keyguard, don't wait until the next frame
to start the animation. Saves 16ms
- Scrims: Skip first frame, because it's completely black anyways.
Saves 16ms.
- Don't wait with navigation bar to show until the screen has turned
on. Window manager is blocked on DisplayPowerController anyways, so
the animation will exactly be started when the screen turns on. Fixes
some jank as well.
- Window manager: Don't wait for the window below Keyguard for draw
completion until turning on screen. Saves a lot of time depending on
how the app is behaving.
Bug: 23401557
Change-Id: I9734f9a12143f0e3c0647e9aa066831a29a6de63
If we have a window orientation sensor available then we can defer
our orientation calculation to it and potentially let the AP go into
XO shutdown.
By default we'll use the typical accelerometer-based sensor unless
the device tells us the name of the sensor to look for.
Bug: 23038651
Change-Id: I94f02e0639956a7a6a3ab85710aa0f2537fbf7f3
So when SystemUI/Keyguard crashes, we only call onStartedWakingUp and
onScreenTurnedOn when the device is interactive and/or the screen is
on.
Bug: 23344236
Change-Id: I0d0be91ff15d6c552304659956770ab88bb26ba4
Fixed b/23325974.
The camera was always launched in the device owner's profile. Now it can
work with secondary users.
Change-Id: I826b341a7e73a9dd603dd5df7aa31bfaf4d440c4
This isn't specific to work profile. When multiple user
deletions happen in sequence, a race causes a dying user
to lose permissions prematurely. This fix delays removal of
user state until the user is completely cleaned up and all the
processes have been killed.
Bug: 23178833
Change-Id: I1636bc2022416359a25f19a3f65d113c05289cd3
LTE radios take 10 seconds to power down, so we should set the
activity timeout to 10 seconds.
Bug:23294704
Change-Id: I7478b77f134b0fe2d82e39acd5c370add12735ca
This fixes an issue where a window state animator holds on to old clip
rect from previous transition and applies it to the newly created surface.
Bug: 22851074
Change-Id: Ic416a2a0c5d0f69fc80d5656541256ade41c9c36
This introduces a new phase of device idle mode, immediately
before going idle (once we are sure the device is not moving),
try to collect a location for the device so that any later
requests for it will have a good chance of having an accurate
value.
We do this with two location requests: one a single-shot as
accurate as possible location, and a second longer-running
attempt to get an accurate location from the GPS. There is
a limit on how long we will try to collect the location (default
is 30 seconds), and we stop collection once we reach a desired
accuracy (default is 20 meters).
Also cleanup various transition paths out of the normal state
flow to clean up any active state we may have running.
Change-Id: Ibd3d2e9a720fbfd9640755baf5547180dd409f6a
In particular, don't assume that the absence of an explicit permission
requirement means that the activity is freely launchable unless you have
also checked thing like exported="true" first.
Bug 23223804
Change-Id: Idbfd1f5662b374a7a447b738591b267a1c497e41
...from Camera360 to Hangouts }
In the short URI toString, include a small summary of the ClipData (instead
of just saying it has a clip data). This makes it a lot easier to understand
what is happening when you look at the log of activity starts.
Also separate out the activity manager dump of URI permission grants from
its dump of providers, so it is easy to just look at that state.
Change-Id: I68093d9f279944e1aa9a29347075f237f4f55ed3
..in link-opening behavior. If a candidate is marked as "ask
every time," then the user is guaranteed to get a disambiguation
prompt including that candidate even when some other candidate
app is in the "always prefer this over a browser" state.
Bug 23147746
Change-Id: I904d8697a992b3f16f32b1c1b49c2bf9424c7137
