Synchronize only the methods that need to be, so that
the lock is not held for a few hundred milliseconds, blocking
other usagestats operations.
Bug: 27208519
Change-Id: I43bda0791dd8b2576a8af506bcdc67a09a5830f2
- Make sure to update when configuration changes
- Do not reset it to a deprecated icon we don't use
anymore.
Bug: 26451729
Bug: 27045882
Change-Id: I6c23a91fd9577ca836818fcd3ab6a0682880df1f
Backup requires both CE and DE storage to be available, so delay
spinning up the backup system until the user is unlocked, since
that's when CE storage becomes available. Note that devices without
FBE immediately transition USER_SYSTEM into the unlocked state,
since their CE is always available.
Offer to backup and restore files under both CE and DE. Since DE
is effectively the same as CE, most logic is simply duplicated for
now, but it could be simplified in the future. Since system apps
can force their default storage location to DE, we always build
explicit CE and DE paths.
Add getDataDir() to give clean access to the top-level private data
directory, but disclaim that apps shouldn't create files there.
Bug: 26279618
Change-Id: Ic34a4b330223725db93b1d0f5c9dffc88002c61f
There are still system internals making assumptions about component
details always being available when requested directly, so relax this
even further to only filter resolve results.
Bug: 27165374
Change-Id: I216fd362516064741e9b80636b99e2d0477d4a58
With this CL, InputMethodManagerService#resetDefaultImeLocked()
picks up the default selected IME with the same logic to find the
default enabled IMEs [1]. It should make sense because the default
selected IME should be one of the default enabled IMEs. The previous
code is problematic because it does not check whether the IME is enabled
or not. There was a chance that unusable IME could be picked up.
This CL also fixes the same problem to Bug 17347871 that only language
part of the locale is taken into account.
[1] See the following series of CLs.
- part 1: I831502db502f4073c9c2f50ce7705a4e45e2e1e3
ed20f8d750ef0b6347448265a14ef2a2c7e1af5c
- part 2: Ife93d909fb8a24471c425c903e2b7048826e17a3
745e7bca8a622ffdf0d0a8e8e2485eab98182ede
- part 3: I6571d464a46453934f0a8f5e79018a67a9a3c845
d0dbd81fe2cd34c9a83e2f5217374d3e1a79f950
- part 4: I871ccda787eb0f1099ba3574356c1da4b33681f3
b21220efae92a56ff7b4b781fa614a6e3a8a3007
Bug: 27197621
Change-Id: Ia0f52c1fb9f5a68230284a1ec4829a2337b60bdd
The main build hasn't swtiched to java 8, but lambdas are already used
in layoutlib. This fixes the build break.
Change-Id: I4dd69ebd736179067899f5d86d3608d5fdb03d93
App switching is a little janky, one of the causes seems
like we're doing a call into package manager to see if there
are more applications (to draw the arrow) and that is expensive
(around 10-160ms). Remove this call and maintain a cache and
query that instead.
Bug: 27232284
Change-Id: I9666073944e406b595a3486857f3fe44b2ae2039
It seems that some account authenticators call getData before account
is added, which initializes the cache for that account.
1. We now don't initialize the cache if the account is not on the device.
2. We now use locking.
Bug: 23018710
Bug: 20071745
Change-Id: Ie59ca6b4e575f524a9d3bf286c3bd95abce4a596
