Change-Id: Iff2cfec5280a314989d915aa830c16124f921611
5214105: taking a screenshot while "Android is upgrading..." crashes device
5109947: Race condition between retrieving a content provider and updating its oom adj
The content retrieval APIs are synchronous from a client's
perspective but internally they are asynchronous. The client thread
calls into the system requesting an action and providing a callback
to receive the result after which it waits up to a timeout for that
result. The system enforces security and then delegates the request
to a given view hierarchy where a message is posted (from a binder
thread) describing what to be performed by the main UI thread the
result of which it delivered via the mentioned callback. However,
the blocked client thread and the main UI thread of the target view
hierarchy can be the same one, for example an accessibility service
and an activity run in the same process, thus they are executed on the
same main thread. In such a case the retrieval will fail since the UI
thread that has to process the message describing the work to be done
is blocked waiting for a result is has to compute! To avoid this scenario
when making a call the client also passes its process and thread ids so
the accessed view hierarchy can detect if the client making the request
is running in its main UI thread. In such a case the view hierarchy,
specifically the binder thread performing the IPC to it, does not post a
message to be run on the UI thread but passes it to the singleton
interaction client through which all interactions occur and the latter is
responsible to execute the message before starting to wait for the
asynchronous result delivered via the callback. In this case the expected
result is already received so no waiting is performed.
bug:5138933
Change-Id: I382e2d8689f5189110226613c2387f553df98bd3
When recording data usage, measure the actual active time, since
buckets can be quite long. Offer incrementOperationCount() version
that reads thread stats tag for caller. Rethrow any NPE as ISE
during stats parsing, which callers already handle.
Bug: 5171812, 5184508, 5180659
Change-Id: I6da80ccc0162be68bee279529e3a23b6f98ebd87
We now use Intent.makeRestartActivityTask() to build the notification
PendingIntent objects, so that when tapped they restart the activity
in the desired state.
Fixes bug 5011926
Change-Id: Ie1ec3543cc0f49d1bd407622a617316cf53a078c
Instead of polling every 15 minutes, register for alerts that trigger
when system-wide traffic passes a threshold. Still mixed with polling
to persist UID stats, but relaxed to 30 minutes. Currently watches
for every 512kB.
Make persistence decision separately for network versus UID, and use
total delta bytes when making decision. Use light bootstrap during
systemReady() instead of heavy poll, which had been force-loading all
UID data unnecessarily.
Bug: 5023631
Change-Id: I04b723d6c4bf872fb1028071122dba66a8e1b576
Add policy controls to NetworkStateTracker which are combined with
other user preference and internal flags to decide if data connection
should be established. Better locking around enabled flags.
When data network would be over limit, proactively disable data on
that network. Enable when policy is snoozed or when cycle resets.
Track and dismiss notifications from now-stale policies.
Bug: 4587023, 5178147
Change-Id: Ibfcc9f73cda7c369209af701b46eddd3d1943f2d
The new specification calls for LED to continue blinking until the user
pulls down the notification shade in the status bar.
Bug: 5143247
Change-Id: Id004cc3d1d9d76108329e57c6fbd8a8100068e0a
Signed-off-by: Mike Lockwood <lockwood@android.com>
...(when turning display on after recently turning it off)
Also clean up when we decide to turn the screen on to improve that
transition. There are still problems here with turning it on
before the wallpaper gets dispayed.
Change-Id: I2bc56c12e5ad75a1ce5a0546f43a845bf0823e66
This introduces a new facility for code during the boot process
to display messages to the user through a progress dialog. This
is only for use when performing longer-than-usual post-upgrade
operations such as running dexopt on applications or upgrading
databases.
Change-Id: I0e78439ccec3850fb67872c22f235bf12a158dae
As init now uses SIGKILL to stop daemons, performing graceful shutdown
becomes impossible. Here we implement our own solution by asking daemons
to monitor the control socket and terminate when it is closed.
Change-Id: I07a28807173a81b7f95e70f4193e974317acf88a
This fixes a crash caused by permission problems when we try to update
the password history and discover there's no password salt. The code
attempts to create the salt, which triggers the exception.
This could be fixed by wrapping the call with a clearCallingIdentity()/
restoreCallingIdentity(ident). However, while looking at it, it occurred to me
that this can cause unexpected failures if the DPM tries to set the
password twice or happens to set it to something in the password history.
Instead, we should *always* allow the DPM to reset the password to whatever it wants,
provided it passes the minimum password criteria.
Change-Id: I1505b24f9c097ee5c2c44e4bf378ba90095b113b
