Tell the activity manager when the lock screen is shown, so it
can keep itself (mostly) in sleep mode during this time, having
the foreground actvities remain in their stopped state.
Change-Id: I71c86d3298f23a98014d7ae36fd540c9df9a64e6
We now have an animation to apply to the thing behind the lock
screen animation when it isn't on the wallpaper, which looks
similar to the animation we use when both are on the wallpaper.
In implementing this, cleaned up the code to figure out up-front
which animation to run, getting rid of that kludgy thing that
cleared the window animation if the wallpaper was not being used
for the lower windows.
Change-Id: Ifc4c8a8894ad384124dcf4bbdaab134f1157b0f3
Due to the step to query the users, dumpsys was crashing when run
as non-root. Clearing the calling identity after checking perms
fixes this.
Bug: 6311443
Change-Id: I0b0bca5c7305cea19adc772b3bfec34c16bb24c4
Added handling for EV_MSC / MSC_SCAN which typically reports
the HID usage associated with a key. This will enable key maps
to map keys with HID usages that Linux does not natively recognize.
Removed keyCode and flags fields from EventHub RawEvent since
they don't necessarily make sense in isolation now that we
pay attention to HID usage codes too.
Removed the fallback code for mapping keys and axes. In practice,
an input device should be self-sufficient. We should not ever
need to look at the built-in keyboard's key map. In fact, there
usually isn't a built-in keyboard anyhow. This code was originally
working around a problem where we weren't loading the key map
for touch screens with virtual keys, which has long since been fixed.
Change-Id: I0a319bdec44be9514f795526347397e94d53a127
The method setTokenVisibilityLocked returns true when animations are
delaying the exit of an app. Previously this only checked AppToken
animations but that caused exiting WindowState animations to be
ignored.
In particular if an application both hid an AppToken and then
dismissed the AppToken, the AppToken was being removed from
mClosingTokens before the animation finished. This caused
rebuildAppWindowListLocked to lose a WindowState. Furthermore
Surfaces were not being removed when a WindowState was lost and
we were leaking Surfaces.
Fixes bug 6297563.
Change-Id: Ie75c71064518199237ec4a17d3f65e2a2dd29674
On a device with emulated external storage, the low storage notification
should go to the main storage settings UI. This shows the user all of
the things that could be causing their storage to be low.
Change-Id: I9c345b6cb7abbabc24a67c7e104d077ecbbfb86d
Add a test to make sure that we are dimming before we send the message
to stop it. This prevents a CPU consuming loop when dimming is already on.
Fixes bug 6320003.
Change-Id: If26dc5b0800300d8e38c166824651223eded4cfa
Instead of each application loading the KeyCharacterMap from
the file system, get them from the input manager service as
part of the InputDevice object.
Refactored InputManager to be a proper singleton instead of
having a bunch of static methods.
InputManager now maintains a cache of all InputDevice objects
that it has loaded. Currently we never invalidate the cache
which can cause InputDevice to return stale motion ranges if
the device is reconfigured. This will be fixed in a future change.
Added a fake InputDevice with ID -1 to represent the virtual keyboard.
Change-Id: If7a695839ad0972317a5aab89e9d1e42ace28eb7
We now allow processes that currently have stopping activities to
be managed as if they were done stopping, so that memory trimming
can be done before the process goes to the background. Hopefully
this will reduce cases where the processes goes to the background
and immediately gets killed, but wouldn't have had to be killed if
it had a chance to trim its memory.
Also change window memory trimming to always do the aggressive
trimming when memory is critical, even if not on a low-end device.
And tweak web view trimming to not trim for foreground UI events.
Change-Id: I241b3152b52d09757bd14a202477cf69c9b78786
The ANR dumping code was reusing the shared StringBuilder while
not holding the ActivityManagerService lock. As a result, other
threads could sweep in and clobber the ANR information.
We don't want to hold the lock here, so just create a new StringBuilder.
Change-Id: I0d91af55f5c123102cfab2cd97035491efed59c0
This change keeps requestTraversalLocked from being called on virtually
every call to animate while rotating.
Change-Id: I6d2db37db3bb82f4f9ecc84b17dbf121819a6c1b
Keep track of the number of frames pending in the timed audio queue so
we can implement framesReady in O(1) time instead of O(N). This
change partially addresses bug 6020970; the bug will be completely
addressed once this change has been up-integrated into master.
Change-Id: I599eb15ea1f6d715b97b30e65214fb6fadd169df
Signed-off-by: John Grossman <johngro@google.com>
Addresses issues seen in bug 6260139.
This is a really tough bug to repro, but there is no doubt that it is
happening occasionally on our super huge A@H subnet. I have collected
data all weekend; the failure did not occur, but I got enough to have
a theoretical sequence of events which could trigger this behavior.
The sequence goes like this.
1) A network is running and happy with a timeline master M,
maintaining timeline X.
2) Device B boots, but its network is taking a long time to come up.
After 60 seconds of waiting for the network to come up, device B
goes into networkless master mode and creates timeline Y.
3) Device B's network comes up. It immediately sends a master
announcement saying that it is the current low-priority master of
timeline Y (its low priority because it has never had any real
clients)
4) Master M ignores B because B is low priority.
5) Device C boots and sends out a who is master request. It is a race
between M and A to see who will respond first. In this case, A
responds first.
6) C sends B a request which B receives. B now has its first client
and is now high priority. In this scenario, B matches M in all
aspects of the priority ranking function, including winning the tie
breaker (larger MAC address when interpreted as a 48 bit integer)
7) M sends its master announcement; it is ignored by B since B
now wins in the ranking function vs M.
8) Finally, B sends its next master announcement. M sees it, realizes
that there is a higher priority master out there (looks like a
bridged network scenario to M). M gives up master status along
with timeline X. The clients of M become clients of B and move
from timeline X to timeline Y (something which should only be
needed during an actual network bridging event)
This change has a few different things meant to severely minimize the
chance that this can happen.
First, and the most important change, is that networkless masters do
not immediately announce themselves as masters on the network they are
joining. Instead, they transition into Ronin to discover any
pre-existing masters on the network. If there are no masters out
there, the device will simply transition back to master and continue
to maintain the timeline it had in networkless mode. In the scenario
above, however, B should discover M and become its client, preserving
the established timeline X.
Second, any time a device experienced an interface reconfiguration
(including coming out of networkless mode), it clears its high
priority bit. This is a good thing. The bit used to get set again
any time...
1) The device is master and receives a client request.
2) The device becomes a client of another master on the network.
3) The device becomes a master.
Number 3 in this list is a mistake. The high priority bit should only
be set for devices during master election which have been
participating in a timeline which has been used by multiple devices.
We know that this is the case when we are master and receive a
request. We also know that this is the case when we hear from a
master and decide to become its client. Simply becoming a master
should not make us high priority. This behavior has been removed.
Third, timeouts have been adjusted just for some extra "stickyness"
when it comes to master status. Clients now say in the Ronin state
for up to 10 seconds looking for a master sending up to 20 discovery
requests, instead of only 3 seconds (sending 6 requests). The
wait-for-election timeout has been adjusted up from 5 seconds to 12.5
seconds to track the longer election cycle as well. Also, while in
steady-state, clients will now wait until 10 packets (10 seconds)
have not been answered by its master before giving up and dropping
into Ronin.
Change-Id: I438b39f31265e34d6719d4adfa9e8b95a2afc188
Signed-off-by: John Grossman <johngro@google.com>
Rather than normal Activities (which have a host of problems
when used for this purpose), screen savers are now a
special kind of Service that can add views to its own
special window (TYPE_DREAM, in the SCREENSAVER layer).
Dreams are now launched by the power manager; whenever it is
about to turn the screen off, it asks the window manager if
it wants to run a screen saver instead. (http://b/5677408)
Also, the new config_enableDreams bool allows the entire
feature to be switched on or off in one place. It is
currently switched off (and the APIs are all @hidden).
Change-Id: Idfe9d430568471d15f4b463cb70586a899a331f7
