- More unit tests
- LauncherApps.startShortcut() now supports sourceBounds
(again)
- Updated the javadoc.
Bug 30218829
Change-Id: Iae208ffd4911d149246ccfd0c4380544c2aafffc
Also fix b/30230996.
TODO: Support the sourceBounds argument to LauncherApps.
startShortcut().
Bug 30218829
Bug 30230996
Change-Id: Ibb6c59d5b7c0a320c21d09436d016d0eac94644f
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
The total storage size was calculating by reading and multiplying the
contents of /sys/block/mmcblk0/size and
/sys/block/mmcblk0/queue/hw_sector_size.
On some devices, such calculation doesn't work because:
1.The primary block is not /sys/block/mmcblk0 .
2.The sector size is not the right value to use.
These 2 issues are temporarily addressed by providing alternative
primary blocks and hardcoding the size (512 bytes). In the long term,
the size should be calculated by vold, so each device could provide its
own calculation if necessary.
BUG: 30216622
Change-Id: I8f9a9f4f753d3c92bab9257062b61ed2b9d665c5
Fixes: 24128505
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
