Fix Slog.wtf to not acquire the activity manager lock in its code
path, so that it can never deadlock. This was the original intention
of it, but part was missed.
Now we can put back in the code to detect when strict mode data is
getting large (a little more targeted now to the actual problem),
and use Slog.wtf to report it. And as a bonus, when this happens
we will now clear all of the collected violations, to avoid getting
in to the bad case where IPCs start failing. So this should be
good enough for L to fix the problem, with wtf reports for us to
see if the underlying issue is still happening.
Finally, switch a butch of stuff in the system process from Log.wtf
to Slog.wtf, since many of those are deadlocks waiting to happen.
Oh and fix a crash in the settings provider I noticed in APR.
Change-Id: I307d51b7a4db238fd1e5fe2f3f9bf1b9c6f1c041
There was a path through idle where we could clear mBooting but not set
mBooted, so we would no longer start activities. This is probably happening
because if you start a user or userdebug build with the device plugged in
to adb, the system early on starts the USB security dialog, before home is
started. If that goes idle first, we will end up in the case where we
clear booting (because something went idle) but not set booted (because it
was not home that went idle).
Change this so that we always set booted when clearing booting.
Change-Id: I40053710eefa939315aeb9475ecdd2e8a87351ff
Accessibility introspection APIs are meant to query only the state of
the current user. There are command line tools that run as the shell
user and want to be able to intropspect the screen. When resolving
the calling user we were using the calling user id instead of the
special constant for the current user.
Now when resolving the calling user for intrspection we are using
the current user constant and consequentially only the current
user or a profile of the current user or the root or the shell or
the system or an app with cross user permission can introspect the
screen.
bug:17674631
Change-Id: I36d1d7b65441d04c3b4204123c4b6d036ff032c0
Added a new SLEEP_TIMEOUT setting which governs how long the device will
remain awake or dreaming without user activity. By default this
value is set to -1 which maintains today's existing behavior.
We basically represent the time we are allowed to be dreaming as a new
kind of user activity summary state called DREAM, similar to BRIGHT
and DIM. When the sleep timeout expires, the state is cleared and
the dream ends.
Bug: 17665809
Change-Id: I59aa7648dcec215f1285464fc1134934a09230e5
Previously if an activity requested to keep running behind
translucent activities (Activity.requestVisibleBehind()) and then
converted itself to opaque (Activity.convertFromTranslucent()), we
would clear the visible-behind activity. This change tests to see
if the top activity is the visible-behind activity and does not
clear it in that case.
This change also clears the visible-behind activity whenever it
comes back to the front. That forces the activity to call
requestVisibleBehind() each time it is resumed.
Fixes bug 17648436.
Change-Id: Id0fc4d7e2a2b907675305d98bad1b08cb610919e
Allow events through if configured, and use a switch
for separating mode-specific logic.
Bug:17580878
Change-Id: Id7b5d8b50173015d6a78568ed0a90e0bccf98549
...but dev.bootcomplete flag is not set
Rework things to address a few issues I found:
- When the activity goes idle, the way we were handling finishing the
boot there was calling finishBooting() with the lock held, but it
shouldn't. We now dispatch that and turning on the screen together
in a separate message.
- Make sure we don't try to start the home activity until we have
reached the point of the system being ready and mBooting being set.
This ensures we don't do any work prematurely.
Change-Id: If30c1f287af73bc2164e7aadbe98022ae42cc5e7
Don't wait for the brightness ramp to complete before reporting
display ready. Keep track of whether we have any unfinished
brightness changes and take care to grab a wakelock to ensure
they are eventually applied.
Ideally we would rewrite the whole state machine to more carefully
coordinate screen state and brightness changes but that's too
risky for now.
The pixel fairies are having a bad day.
Bug: 17718416
(cherry picked from commit 875f80c2732a3fbe652a6e8fc14031041f791308)
Change-Id: I7a2d8ba4591a12b773653d3dbf86c7db016f967e
We allow a fake accessibility service to connect to the system for UI
automation. If the process hosting the fake service dies right after
registering it, the accessibility layer ends up in a bad state and
subsequent attempts to connect UI automation service fail.
bug:17725904
Change-Id: Idad288eab41bbdd486d95e1e5803220640653fb7
In some cases, when starting an animation while another starting window is visible,
the starting window is never scheduled to be removed. In that case, we try and
schedule the closing app starting window to be removed when we are starting the
transition to a new activity. This also partially addresses issues related to
leaking windows in b/17381033.
Change-Id: Id26525cd71380852f109ec2f55a4a60db5086ded
If the window maanger received BinderDied for a starting window
before activity manager then it would null
AppWindowToken.startingWindow and not go through the
PhoneWindowManager.removeStartingWindow call later. That meant that
Surface.release() was never called from
ViewRootImpl.dispatchDetachedFromWindow(). Which in turn meant that
graphics memory was being leaked.
This change notifies the PhoneWindowManager to go through the
removeStartingWindow path when the starting window gets removed for
any reason.
This change also ensures that scheduleRemoveStartingWindow is
always called with the window manager lock held.
Fixes bug 17381033.
Change-Id: Ic6860d0e1410c9bb5053d85ae21a08b11f573b6d
When calling getContentProvider() across user boundaries, and
creating the provider for the first time, we need to clear caller
identity. (We could have torn down the provider while the system
was under memory pressure.)
Bug: 17409650
Change-Id: I67713a03e5f7106f5e8fcf33fe3fdae81ce644ec
When device is encrypted the user has to authenticate in order to decrypt
the data partition which is required for running accessibility services
and Text-To-Speech. In order to address this issue we are falling back
to use the default password if there is an enabled accessibility service
and the user has secure lock. This will enable the user to authenticate
when accessibility layer is completely functional.
bug:17671790
Change-Id: Iafffe7bcd234008cf91ffb5011b21b803dca227a
This ensures that we'll only adjust volume on a session's stream if
that stream is actually in use.
bug:17690423
Change-Id: I5fce8265a015bbc5034afa16719d9a0bbf257598
This makes copies of objects with bundles before posting to another
thread and is more aggressive about locking before making assignments
of mutable objects.
bug:17692568
Change-Id: I28e8229718b862c485e870fd2ca06a3a18a7c454
Previous calculation would always exit downtime on Sunday mornings,
due to the target day ending up at zero (an invalid day).
Bug:17682999
Change-Id: Icc5f01a42c3c644170eea9e60442cf77ce15a06c
Most of this logic is simply removed from ConnectivityService.
The captive portal detection is now done by the NetworkMonitor.
The notification logic is still left in ConnectivityService as
it's used by both the NetworkMonitor and telephony's mobile
provisioning logic.
bug:17324098
Change-Id: Ibd1c42b1a75795f90a6483d3d0a5a14f88b193d8
Currently, LegacyTypeTracker sends out connected broadcasts
before updating its internal lists of networks. This creates a
race condition where an app can query LegacyTypeTracker state
(e.g., via getActiveNetworkInfo) as soon as it gets the
broadcast, and get information that has not been updated.
Bug: 17540101
Change-Id: Iefd6d5e9fd0b427c5872166208831f70fcef8b6f
Add the app directory to the arguments for starting a process.
Add a check for NeedsNativeBridge and a call to PreInitializeBridge
in the native fork code.
(cherry picked from commit 2eacd06bfb82b33dfcbccafbcfc0bf1218484bb5)
Bug: 17671501
Change-Id: I970db5b284b0c12e2d8a45df3950c1fff2927a4e
This checks if the phone app is currently getting or in a call when a
media key event is sent and sends it to the phone session instead of the
foreground app if it is.
bug:17527302
Change-Id: Ie5d6cf0c897da81d106f2b1a0561b79f4fc35e82
