Apps are told to query AccessibilityManager#isEnabled before
calling sendAccessibilityEvent. If accessibility is disabled
between the two calls, an app can crash. We can guarantee that
this won't happen on a process's main thread, but guaranteeing
it for all threads is messier. Rather than add the complexity
of tracking the state for all threads, only log an error in the
corner case that an accessibility event is requested on a
thread that doesn't have the process's main looper.
Bug: 28985452
Change-Id: I8369deefd83b0a6b04936ddfce55c53147756f1f
These appear as a new event in the battery stats history,
"longwake" in the long version and "Elw" in the checkin.
The power manager keeps track of which wake locks are held
for a long time and reports them to battery stats. Long
is currently considered 1 minute or more. Once it is long,
the start event will appear, and once if is released the
event will end.
In the case of a wake lock changing (typically its work
source changing), for purposes of this accounting this is
considering a pure release of the old state and start of
the new state... so the timer will reset back to one
minute until the wake lock is considered long. This is done
to prevent things that make lots of changes to wake lock
work sources from spamming the log.
Bug: 28753137
Change-Id: I33b6168c57a7ea6ea558273dec731704123124a5
starting a shortcut.
- Also add API surface to support launching multiple intents
- Also add SM.isRateLimitingActive() which was supposed to be
added but was not due to a bad rebase.
Bug 30218829
Change-Id: I82d60ec0df1e2b889538705f9f8870ee727dd55d
Symptom:
When sharing an image from Album, ChooserActivity can be shown.
But then the app to be located to the bottom part of the list may not
be started even if user tap it.
Root cause:
ChooserActivity uses ResolverDrawerLayout. And ResolverDrawerLayout
can display only some items on the list (known as "Collapse mode").
When the item clipping along the bottom edge is tapped by the user,
ResolverDrawerLayout tries to expand the list and scroll it to a
better position, instead of starting an application.
In this problem case, ResolverDrawerLayout continues to try to expand
the list whenever tapping, so an application will never start.
Solution:
Change a condition so that mOpenOnClick becomes true only when the list
has been collapsed (mCollapseOffset > 0).
Bug: 30153542
Change-Id: I576fb6c8b6a91d79c1e0d46d069146779f4dbd17
TwilightService now just reports the current twilight state, it's up to
clients to provide their own locking mechanism (e.g. always day or
night).
Bug: 29620105
Change-Id: I2a8bb544eab0f44d269c59f36a53fbdf842b423a
Also, standardize on a set of possible modes for the displays to
enter and separate the configuration of the color mode from the
configuration of the display mode.
Bug: 29044347
Change-Id: I6af0a7d1f11bc72d4cefc380f115c1fb00788864
If an application thread disables disk reads on the main thread,
isThreadInProcess will trigger a strict mode violation. This is bad if
the RenderThread is created after disk reads have been disallowed.
bug 30170339
Change-Id: I6918605d11f0c586c156f3168051376c3209b3f1
These methods were never meant to be public. Instead, developers
can use Context#createConfigurationContext().
Bug:30088019
Bug:29999297
Change-Id: I2b864136163deda0af99fa3bfe9ef4ee1077341a
Originally we always checked with PM for the default launcher,
which would take ~2ms.
Now we cache the result, and clears the cache when (any) preferred
activities change.
Bug 30126557
Change-Id: Iceef288cd372c8bb9b119aa493e5173d894f2302
It was possible for apps to put toast type windows
that overlay other apps which toast winodws aren't
removed after a timeout like toasts are.
Now to add a toast window one needs to have a special
token. The token is added by the notificatoion manager
service only for the lifetime of the shown toast and
is then removed including all windows associated with
this token.
This prevents apps to add arbitrary toast windows. The
token is passed in the app domain in the request to
construt and add the toast window which allows a bad
app to add arbitrary toast windows. However, this is
fine since the token will be invalided and all of its
windows removed after the toast for which it was
create times out.
We do not care of braking apps that add toast windows
directly due to the security and privacy implications
of arbitrary UI redressing. Also we have dedicated
Toast APIs which are the way to add this time of UI.
bug:30150688
Change-Id: I65372c81a791489de89fb2886cc96392c28680bb
