| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
Change-Id: I3f026447ba7c6d2c3f9ef065269c31a78cf73512
|
|\ |
|
| |
| |
| |
| |
| |
| |
| |
| | |
LTE radios take 10 seconds to power down, so we should set the
activity timeout to 10 seconds.
Bug:23294704
Change-Id: I7478b77f134b0fe2d82e39acd5c370add12735ca
|
|\ \ |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This reverts commit 8ae1be120806d0189f65a492004a7b5416aa6c6f.
Fixes bug 23187090
Change-Id: Idd9798895b08618f7d272b818818a45d3c9dc7d2
|
| | |
| | |
| | |
| | | |
Change-Id: I34d4fcdc103b3a6ea5c4ed78895f2fe18597237a
|
|\ \ \ |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
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
|
|\ \ \ \ \
| |_|/ / /
|/| | | | |
|
| |/ / /
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The target app crashed at an inopportune time but this shouldn't
invalidate the whole ongoing restore operation; it's a problem local to
the specific app undergoing restore. Recognize this, clean up the app's
possibly-incomplete data, and continue running the restore queue as
planned.
Bug 23228982
Change-Id: If9a19d2fe6a0ce5339c893630d7a61a5a5ccd9b1
|
|\ \ \ \
| | | | |
| | | | |
| | | | | |
into mnc-dev
|
| | |_|/
| |/| |
| | | |
| | | |
| | | | |
Bug: b/22982966
Change-Id: I4af525532e2f97973ba255bf8dbb002e42997eea
|
| |/ /
|/| |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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
|
|\ \ \ |
|
| |/ /
| | |
| | |
| | |
| | |
| | |
| | | |
This is necessary so non-privilged apps can call setInterruptionFilter.
Bug: 23156657
Change-Id: Ia903a39626c93957276d66805446cd25a91341b5
|
|\ \ \ |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
..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
|
|\ \ \ \
| | | | |
| | | | |
| | | | | |
into mnc-dev
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
...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
|
|\ \ \ \ \
| |_|_|/ /
|/| | | |
| | | | | |
into mnc-dev
|
| |/ / /
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
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
|
|\ \ \ \
| |/ / /
|/| | | |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
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
|
|\ \ \ \
| |_|/ /
|/| | | |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
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
|
|\ \ \ \ |
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
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
|
|\ \ \ \ \ |
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
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
|
|\ \ \ \ \ \ |
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Bug: 22870354
Change-Id: Ib4efaa0f05bec81856c939c5c640eceff98d88ed
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
This will prevent users from losing their language setting when they
take an OTA to M.
bug: 23021286
Change-Id: Ifb66f6bf6a940ab745edac709321f3009ec6eab4
|
|\ \ \ \ \ \ \
| |_|_|_|_|/ /
|/| | | | | |
| | | | | | | |
into mnc-dev
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
If socket initialization fails, DhcpState#exit will call
mReceiveThread#stop and crash the system with an NPE. Make sure
we don't do that if mReceiveThread is null, and properly null it
out when exiting.
Bug: 23088314
Change-Id: I4378d8280f9d8588f5eaa8bd7ade61beab1c3ce2
|
|\ \ \ \ \ \ \
| |_|_|_|_|/ /
|/| | | | | | |
|
| | |_|_|/ /
| |/| | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
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
|
|\ \ \ \ \ \
| | | | | | |
| | | | | | |
| | | | | | | |
mnc-dev
|
| | |_|_|/ /
| |/| | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
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
|
|\ \ \ \ \ \ |
|
| | |_|/ / /
| |/| | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
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: 23027554
Change-Id: I185492b5008058fdb23a4536a8a73177ee4903d8
|
|\ \ \ \ \ \
| |_|_|/ / /
|/| | | | |
| | | | | | |
updated." into mnc-dev
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
- In the existing logic, the call to onProvidersChanged() is called when a package
with widgets is added or removed, but only called when a package is updated _and_
there is an app widget bound to a host. This differs from what the expected
behavior is based on the documentation and means that packages with widgets that
update have no way of notifying host apps of changes except via package events.
Bug: 20698931
Change-Id: I60af36d51e99ca1ea751d9d9d03a50ef2d5bef98
|
|\ \ \ \ \ \
| |_|/ / / /
|/| | | | | |
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
... by never rebasing the theme. We don't need to do this unless the
system theme is configuration-dependent, which it is not currently.
Bug: 22943781
Change-Id: I96e695441543379e4d5fdf3cc6f18d9e6cf953b4
|
|\ \ \ \ \ \
| | | | | | |
| | | | | | |
| | | | | | | |
into mnc-dev
|
| | |_|/ / /
| |/| | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
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
|