Touching StatusBar.disable() directly can make the cached value over
in StatusBarManagerService stale. Instead, dispatch DISABLE_BACK
through setSystemUiVisibility() on tablets; it's unused on phones.
Also DISABLE_NOTIFICATION_TICKER when showing secure lockscreen, and
watch for TIME_CHANGED in DateView.
Bug: 5255469
Bug: 5242677
Change-Id: I4efaf9799b2f229f49d7024da5dafceacd5e08bb
The resolver activity was hiding the following activity from recents.
Also some other fixes: a little better memory use debugging, removed
some unneeded code from window manager, moved some system activities
into their own process, added some more running process information for
manage apps.
Change-Id: I66687d16989ff965d524b92dc360f37c19199717
When ifaces change, poll UID stats without persisting, since they
depend on knowing active iface to store correctly. Log dropped UID
stats when iface is unknown. Switch to using flags when calling
performPoll().
Enforce that "idx" values are consistent from xt_qtaguid. Transition
to using Log.wtf() for important checks, mostly around file I/O,
kernel stats parsing, and kernel module control. Increase stats
persist threshold to 2MB to reduce churn.
Bug: 5269476, 5270106
Change-Id: I721215bfb65127f95775c71cf135e907cd567e92
For the purpose of exposing the class as a storage for Wps
info with p2p, it is better to just call it Wps
Bug: 5247957
Change-Id: Iaebef958dd8f08fdbeb4b9d7fa5ad5527400710d
This patch parallels the previous one that fixed backup timeouts.
It establishes the same sort of state-machine process for walking
through the restore steps solely as events posted to the backup
manager's HandlerThread.
Fixes the rest of bug 5074923
Change-Id: I122a021cb1e9bb1342de0b71e5d4bc84cc630c58
- this really just calls cryptfs cryptocomplete
- needed so that UI logic can present a factory reset option if
encryption screwed up
Bug: 3384231
Change-Id: I553de87f0d03a65851030c9c5266e85866d30fa6
1. Tuned the max angle between two moving fingers in touch
exploration mode for a gesture to be considered a drag.
The previous value was too aggressive and it was fairly
easy for the user to get out of dragging state if she
ingreases the distance between her fingers.
bug:5223787
2. Before clicking the explorer was sending hover enter and
exit resulting in firing the corresponding accessibility
events which leads to announcement of the content under
the tap that triggered the click. However, the click is
actually performed on the last touch explored location
(if in the distance slop of course) instead of the actual
tapping pointer location. Before fixing that the user was
confused since he was hearing announcement of one content
but actually was clicking on something else.
bug:5225721
Change-Id: I79fec704878f98c95f181bf8a9647e0bb1bd10ef
Away in the misty span of very-long-ago, it was suggested that spinning
a separate thread to run the backup process was wasteful, and that it
could just run it inline on the dedicated HandlerThread that the
backup manager uses for its own operations. That was indeed true,
except that the timeout management was also using delayed messages
to that handler. You see where this is going: timeouts were never
actually being processed, with the effect that a badly-behaving
app's backup agent could lock up the entire backup / restore system
until the device was rebooted.
This is bad.
Backup operations are now driven as an asynchronous state machine:
each step (init, call one agent to obtain data, send resulting
data to the transport, finalize the backup) is handled as a formal
state transition on-looper. No synchronous wait-for-completion
or -timeout is performed on any thread.
As an additional effect this greatly tightens up the serialization
and locking semantics. We no longer have to worry about an in-
flight operation involving a standalone thread spinning off on
its own; everything is on the HandlerThread and can be coherently
manipulated from that perspective.
Along the way, this CL tightens up the per-agent error handling
logic. Previously a single failed agent would abort the entire
backup process, tantamount to a transport-level failure. This could
mean that the aforesaid badly-behaving app's agent could in effect
starve out other apps whose agents were routinely showing up later
in the queue. There's some nondeterminism involved, but in practice
it could and did happen. Furthermore, the failure case would
reschedule *immediately* in this case, because the transport itself
would see that all is well and sure, why not run a backup soon?
This, as you might imagine, causes battery-life issues.
Now we note that the single agent has failed, mark it for a future
repeat attempt, and process the rest of the queue normally, pretending
success at the transport level even though we didn't actually send
any data for that app. This means that (a) we now finish running
backups for everything in the queue, (b) reschedule backups only for
those apps whose agents individually failed during this run, and
(c) perform the retry after the normal interval [typically on the
order of an hour] rather than immediately.
NOTE: this CL does not retool the restore code path, just backup.
Restore is similarly vulnerable to misbehaving apps, though, so a
future CL will address that bug vector.
Addresses bug 5074923
Change-Id: I67e3f8d06f322607881eaa4093de6d675b85ff2c
Persistent process can no longer use hardware acclerated drawing
when running on a low-memory device.
Change-Id: I3110335617af1c98fcede9bf41f4a1d0c20d0e87
When in a phone call, we keep the screen off while the prox sensor returns positive
and the device is oriented in a vertical position.
If the call is terminated on the other end, we keep the screen off
until the proximity sensor returns negative.
We do this to avoid having the screen turn on as soon as the other end
hangs up while the phone is still next to your head.
However, we allow the power button to wake the screen while waiting for the proximity
sensor to go negative as a precaution in case there is a problem with the proximity sensor.
But unfortunately that logic broke due to a change in the call path used to turn the screen
on from the power button (it previously called userActivity, now it uses a wake lock).
This change adds code to handle the new code path so the power button will wake the screen
while we are waiting for the proximity sensor to go negative after a call.
Bug: 5184524
Change-Id: I7d1e0f0d1f78680c552a05d68a392647823250ab
Signed-off-by: Mike Lockwood <lockwood@android.com>
Only combine /proc/net/dev and xt_qtaguid stats when iface is marked
as active. When inactive, only return xt_qtaguid stats. When iface
is unknown to xt_qtaguid, always pass through /proc/net/dev stats.
Bug: 5242730
Change-Id: I469fc6abe45309f794afebca814cbb39e4f13af5
...opening after selecting option "Youtube" as a luncher.
Also:
* Tweak window animations so that the wallpaper exist animations do not
stop too early (causing the wallpaper to suddenly disappear).
* Make sure no input is being processed while booting, to avoid
accidentally doing things especially in the upgrade dialog.
* Some other small cleanup.
Change-Id: I40a6b53731991d4e31ac4502e3d85f0e47507481
Applications shouldn't be able to change their window type after
the window is added to the window manager.
Change-Id: Iac63da65f96fb30683f68f8d89c3fd29199a750c
Useful for checking if on a wifi-only device.
Similar to asking for NetworkInfo for a network type and checking for
null, though here the intent is explicit.
bug:5087537
Change-Id: Ia3ddd09b6b735b8b3ceb7a347891e015fd96b218
Bug: 5156144
Input channels could leak or simply live longer than they should
in some cases.
1. Monitor channels (used by the pointer location overlay) are never
unregistered, so they would leak.
Added code to handle failures in the receive callback by closing
the input channel.
2. The DragState held onto its input window and application handles
even after the input channel was disposed.
Added code to null these handles out when they are no longer needed.
3. Input channels previously used as input event targets would stick
around until the targets were cleared (usually on the next
event).
Added code to detect when the input dispatcher is in
an idle state and to proactively clear the targets then
to ensure that resources are released promptly.
4. Native input window handles held onto the input channel even
after the input window was removed from the input dispatcher.
Consequently, the input channel would not be disposed until
the input window handle itself was freed. Since the input
window handle is held from managed code, this meant that the
window's input channel could stick around until the next GC.
Refactored the input window handle to separate the properties
(info) and identify (handle) state into different objects.
Then modified the dispatcher to release the properties (info)
when no longer needed, including the input channel.
7. The pointer location overlay does not actually use its
standard input channel, only the monitor input channel.
Added INPUT_FEATURE_NO_INPUT_CHANNEL to allow windows to
request that they not be provided with an input channel
at all.
Improved some of the error handling logic to emit the status
code as part of the exception message.
Change-Id: I01988d4391a70c6678c8b0e936ca051af680b1a5
Certain kinds of application update generate this broadcast regime rather
than the REMOVE / ADD sequence that results from e.g. using the -r option
when invoking 'adb install'.
We also push the agent classname lookup to the last moment before
actually running the backup, rather than caching it as part of the
record of what apps need a backup pass in the future. This was causing
a bug in which a package reinstall that renamed the app's agent class
would wind up with a crash at backup time, trying to load the wrong
class.
Fixes bug 5156094 / bug 4308977
Change-Id: I4e3e12d86e6ee40809f14fd12ab762116dbee0b5
5233826 when a live wallpaper starts, it does so regardless of its visibility
The WallpaperService is now very forceful about telling a wallpaper it is
not visible when it first starts.
5209847 Make launcher turn off the wallpaper in all apps.
Fix a bug in the window manager that would not correctly handle the wallpaper
flag changing.
Change-Id: Ie3314043a84664be72a1304a1705408efd789a15
Also do not blink for notifications received when the screen is on.
Bug: 5233071
Change-Id: I15675ca317007d4b900ef74e60d11a5bca3d7333
Signed-off-by: Mike Lockwood <lockwood@android.com>
New broadcast that is dispatched immediately after connectivity
changes have been handled by ConnectivityService, bypassing any
applicable CONNECTIVITY_CHANGE_DELAY.
Also protect CONNECTIVITY_CHANGE broadcasts, since they should only
be sent by system.
Bug: 5198167
Change-Id: I75f1fb44b21da1879f0ab960bcaa481126d70fde
