| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
I spent forever trying to figure out why one of my threads was losing its
interrupted flag, and eventually chased the problem to this. This change
keeps the behavior of blocking until the looper is intialized (i.e, any
InterruptedExceptions are still eaten), BUT it will restore the thread's
interrupted flag before returning, if needed.
Test: calling getLooper() from a thread with the interrupted flag set, then
verifying that the interrupted flag was still set after the call returned.
Change-Id: If1b1a0812fa672c02510b70faf4d813b82ae8589
Signed-off-by: Michael Hoogasian <michael.hoogasian@gmail.com>
|
| |
|
|
|
|
|
|
| |
Addresses concerns in b/63382879
Fixes: 63382879
Test: proofread
Change-Id: I4aaf543df86123d46b708f35c80c04df0f737989
|
| |
|
|
|
|
|
|
|
|
|
|
| |
1. On package removed -> remove all its associations
2. On package updated -> if had associations, update special access permission
in accordance with (potentially changed) permission entries in manifest
Bug: 30932767
Test: 1. Remove app, and ensure xml entries for it got removed.
2. adb install new version of app without special permissions in manifest, and
ensure whitelist removal method got called
Change-Id: I87261c05ddcf40a18332d160b44ee2f8284df5e4
|
| |
|
|
| |
Change-Id: Icc489a3f3fdab799de3f641c0a0e4f2635b42935
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It seems some applications rely on Looper.quit() terminating the
loop immediately without processing all messages. Rather than
risk breaking them, make the safer behavior optional.
Also take care to properly drain the message queue before quitting
so that all of the Message instances are recycled. This may
help release storage sooner in case the Looper doesn't get GC'd
promptly and its remaining queue of undelivered messages sticks
around.
Improve docs on runWithScissors.
Bug: 8596303
Change-Id: I8cbeb6f7a5f6b8e618b5109f87a03defc1486b9f
|
| |
|
|
| |
Change-Id: Ibbfee452cae76a379dcd360412de962e90f29da5
|
| |
|
|
| |
Change-Id: I4aeadfbaf8a4f6a459fa19937c21ac23d9e5fb64
|
| |
|
|
|
| |
and release the lock as soon as possible even if we run the loop
in background priority.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
First, fix some issues with the final wallpaper bitmap
we use: ensure it is always 16bpp, and make sure dithering
of its bitmap is turned off. We take of dithering
when loading, to make sure we don't use it when drawing.
Also add new APIs to return the wallpaper with the equivalent
of Launcher's old FastBitmapDrawable. As doing this, also load
the default wallpaper the same way as custom ones, taking care to
resize it as needed at load time.
Finally implement a mechanism for the window manager to wait
for the wallpaper to redraw at its new position before returning
from the application's call to change the offset. This ensures
that the wallpaper better tracks the application. Note that there
is a timeout in this wait that is relatively short, and if it
expires we will run for a while without waiting.
Change-Id: Ife449437746da85958bd447e0a6cf3d2223b398c
|
| | |
|
| | |
|
| |
|
