We've been seeing some really funky behavior when upgrading or
downgrading system apps around OTA time. Put more of these one-time
logs into durable storage to help investigate.
Bug: 17805839
Change-Id: If898d7df229c1f71e598b0d965325c272060e5e7
This reverts commit 851a5059a47cbf76e530c9d050a677cb6e3f8657 as
it creates a regression. Let us revert this and correctly fix the
issue the original change was trying to address.
bug:17789608
Change-Id: I8abb1a61d5310430e839e4ef60e7ca5cc0cbdd80
We also refine the order of delivery within any given package. Now,
we identify which apps have wakeup alarms being delivered in the
current pass, and deliver all of that app's alarms before moving
on to alarm delivery to apps who are only receiving non-wakeup alarms
in the current delivery pass. The TIME_TICK alarm is also hoisted to
the start of the current delivery pass if present.
Bug 17778686
Change-Id: I6306a00fe657787a77d0254c0807ac51e810fdcf
Listen for phone call state changes in NoMan, and disable
incoming non-call notification effects when non-idle.
Bug:17658454
Change-Id: I6f7d66413970fbff6822ab29a12f91cbed068261
Tweak the oom tuning to raise everything by 50%. This is the same
increase we did for Volantis; I am thinking that most of the issue
there was not it being 64 bit, but it being tighter on RAM. From
my testing, it looks like in user switching there was some paging
going on with Nakasi, and with this change things seem to be better.
We should probably revisit this for future work on RAM. It seems
likely that a 64 bit device will need more RAM, so probably the value
I am picking here is larger than we actually need for other devices.
I think this is the safest change at this point though -- it leaves
Volantis the same, where we already had tweaked it to address paging
issues, raises it on Nakasi (to the same value as Volantis) where we
seem to have paging issues, and on our other devices also raises it
but those are generally not under memory pressure so this shouldn't
really make a difference.
Change-Id: Ib19394068734d322a015ed07370d9d4961877e4b
This reverts commit cf2bd348e73e880fe5bfc7a025732d4ec606ff1f.
Reverted because for account removal the AccountManagerService
delegates the sending of LOGIN_ACCOUNTS_CHANGED to the authenticator.
See b/17511110.
Change-Id: Ic03016af98070b4add5f7a5ec1fdff32ba63298e
Previous commit bfed9f34c makes the preloaded system app take
precedence over third-party apps when defining permissions, but
it also makes it be able to override android built-in permissions.
Now allow preloaded system app to take the ownership of built-in
permissions instead of overriding it.
Change-Id: I10d588d0284e4316ea4be552fd6191f33e3c725b
Due to a recent change there was a regression that caused the
screen brightness to be animated down to 0 while the screen
off animation was running. When the brightness was low this
would cause the screen off animation to be cut short.
This change ensures that we take into account the actual screen
state instead of the desired screen state when making screen
brightness decisions in case we are in the middle of a transition.
The darkness came early. The pixel fairies trembled.
Bug: 17718416
Change-Id: Ib4b55d61b359abbc70920e324f08a5db07bdd035
It's perfectly ok for a secondary display to not have a home stack.
There is no reason to report it.
Related to b/17677973.
Change-Id: Ia9d52cabb601760d32d2b847dfa0ca4f304e4e2a
Previously the score was not sent out causing other NetworkFactories
to have the lower unvalidated score and to repeatedly try to bring
up a new Network only to have it torn down.
Also, avoid logging an error when tearing down a network with only
listening requests.
bug:17726566
Change-Id: I82ff7c9bd5ec962f62a50ad0042c278622953969
Explicitly selected Networks may never be validated (e.g. Chromecast)
but are still given a high score so they can explicitly become the
default Network. Without this fix they do not become the default
Network if another Network is present. This was an artifact of how
unvalidated Networks were handled, but now that unvalidated Networks
are properly handled, ala 50807d, we can freely rematch even
unvalidated Networks and NetworkRequests.
Also, never linger and teardown unvalidated Networks as the user
might be in the process of signing in. This better matches prior
behavior when unvalidated networks didn't match NetworkRequests,
and thus were never lingered.
Also, don't disconnect networks that may be lingering. The
disconnect logic in rematchNetworkAndReqeuests() is adjusted to only
fire when a network is newly validated.
It is incorrect to consider rematching uncreated Networks and
explicitly selecting created Networks, so this change logs error
messages in those cases.
bug:17647968
bug:17396616
Change-Id: Id6b8a350b8200f484d5bfd14ca0a8f64f08846a0
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
