Current slop of 30ms was causing too many WTFs to be thrown. Increase the slop
to 750ms.
Bug: 23391894
Change-Id: Ica5be9b00745bfe58872d43be8c32f8c147075ed
Fixes a bug where WindowManager's and SurfaceFlinger's
view of the wallpaper's position could get out of sync.
Bug: 13020924
Change-Id: Iad17b0f516fffacd2877ceac40fcc8e2647c06b2
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
...with protection flag PROTECTION_FLAG_DEVELOPMENT
Bring back the old grant/revoke code for development permissions.
Also some more dumpsys output to help debugging.
And new dumpsys command for checking a permission.
Change-Id: I6e27e62a9ca5ec1ecc0f102714a448ea02f0f41c
The platform grants runtime permissions by default to apps on the
system image that provide core device use cases which a user expects
to work out-of-the-box. We are now adding a test to ensure that
OEMs cannot pregrant premissions on non approved components.
bug:23043018
Change-Id: Id76717cce0ee59678956bd0be347d3c045fe4c51
Global restriction of background data only applies to metered
interfaces, but battery saver applies to all interfaces. In the
very specific case where global background had been turned on while
battery saver was enabled, we'd end up with a stale battery saver
rule floating around.
This change triggers an update of iface rules when the global
restriction changes, giving us consistent behavior.
Bug: 23098198
Change-Id: I454dc71cf11d50a2e9e6122e8a801ff17039b43a
When upgrading from a pre-M version of Android, install permissions for
exisiting system are promoted to runtime permissions. This only happens
for apps that existed prior to the OTA. Other system apps targeting M
are not automatically granted any permissions.
Bug: 22970710
Change-Id: I964ee3f93c66ea43fbb1be6b5ac6b09ddea3c385
The timeout for waiting for Keyguard drawn was posted at the wrong
place. If the screen was turning on but the device wasn't waking up,
like in doze mode, we didn't post the timeout, thus, if Keyguard
wouldn't notify us, we would never unblock the screen. This doesn't
really cause a user visible bug but it *could*
prevent the screen from turning on if Keyguard doesn't behave nicely.
Put it at the right place so I can sleep better.
Bug: 21855614
Change-Id: Icda31399261b4ee80c292ce09a0858b0127e2999
Removes overlap from the color views which resulted in subotimal looks
when both color views were translucent and the nav bar was on the right
edge.
Also fixes a bug introduced in I2df7092a91eceeb815367ef917dd7289f4f2b27e
where the navigation-bar-on-right-side case got forgotten and caused
flickering in landscape when IMMERSIVE_STICKY was set but the navigation bar
was visible.
Bug: 22876533
Change-Id: I449a82eb3dc3f7b5051f26b37b362a196b4ff63a
AccountManagerService can't ever synchronize on mUsers within a block of
code locked by UserAccounts.cacheLock. That will lead to deadlocks.
This change fixes a case where we were doing that in
getAccountsInternal(). Also I have purgeOldGrantsAll() run off the the
main thread.
Bug: 23036400
Change-Id: I8634691ca54c57a6e83633baba549226fdcd1064
Icdad980eec64e081d15679600da07cf4431e40d6 allowed us to
properly return to the home acitvity when a task is moved
to back. However, this improperly moved the home task to
the front if it is the task we are moving to the back on
a single stack device. We now prevent the movement of the
home task to the front from happening.
Bug: 23088310
Change-Id: Ic21779cdb2d2007671d212d41fab5e68be2ae632
BUG: 23086704
Cherry-picked from https://android-review.googlesource.com/#/c/162280/
When the screen goes off or dreaming start, an alarm will be
scheduled and idle state will be true when the alarm expired.
If the screen goes on or dreaming stop happens before
the alarm expired, the alarm isn't cancelled and idle state is
set to be true when the device is in SCREEN_ON or DREADING_STOPPED
state. There is also a case that Idle alarm triggered when
the screen on or dreaming stop just start to be processed.
ACTION_TRIGGER_IDLE will set mIdle to true during screen on
or dreaming stop.
In this patch, the alarm will be cancelled when the screen goes
on or dreaming stop and screen-on flag will be set. So the idle
state can only be set when screen is off or dreaming started.
Change-Id: Ic21a2394418ca55513ab932b3bfad1126b8769c1
This tightens the guarantee that detached stack won't be used. We also
add logging to detecting a situation where a stack not belonging to a
display is being moved on that display.
Bug: 22191609
Change-Id: Ia674bb5960018104a56c5138775ab5216906675b
