Shared prefrences loads thir content from disk on a separate
thread to improve performance, however it holds the lock
the whole time while reading from disk which as a result blocks
operations that don't rely on reading data from being performed
intil load completes, e.g. reguistering a prefernces change
listener does not depend on having the data loaded.
bug:5254577
Change-Id: I5ad67b285631c34d5aadac7138ba8bfaa728cf94
This class uses reflection to find accessible static integer
members in a specified list of classes and returns a SparseArray
mapping the integers to their names. This will allow us to
replace various 400-line switch statements with a simple
array access.
Change-Id: I3607e6389a423cde0bd83270c00b3c863ae1bb29
am: 5042001350
* commit '5042001350bcc74fc58a77eb1122dc4a64a703df':
Make BlockSuppressalStatus constructor public so that it can be constructed by the provider.
Fix a bug where calling setUserVisibleHint(true) before adding a
Fragment to a FragmentManager could cause a crash.
Bug 27250018
Change-Id: Id192ae31bab95f15d32de9f105e707bdb8691641
Clients can now set a lock-only wallpaper that Keyguard can
observe and choose to draw as appropriate.
Bug 25454162
Change-Id: I3fc30e02919e814b55dfded2a1a36ad9d2e55299
Make printlns in Log public-@hide so it can be used.
Print uncaught exceptions that will terminate the process in
RuntimeInit using printlns, so that long exception traces are not
being truncated.
Bug: 27245306
Change-Id: Ib24635f0ebdd80bd125e367302cab6a78e6a210a
The new sdcardfs kernel driver needs to know this mapping for
deriving UID permissions, so push the data through /config when
supported by the kernel. This also has the nice benefit of letting
us push only the deltas of what actually changes, instead of
re-parsing the entire "packages.list" file.
The mappings for newly installed apps are pushed before the app is
allowed to run, removing some latent race conditions. Also cleans
up stale mappings when packages are uninstalled, and whenever the
system server reboots.
Bug: 19160983
Change-Id: Iace92efb69616c96b34c0d9d911e4b54e5fd8a67
Interop database entries are stored in the system settings entry
"BluetoothInteropDatabase". The format is a list of entries separated by
";". An entry consists of a BDA fragment, followed by a comma and an
integer representing a feature from interop.h.
Example:
To disable LE secure connections for devices starting with BDA 11:22:33,
use "11:22:33,0".
Bug: 26548845
Change-Id: I6a9fd34f6af4d3bdfcaa0e051eafebdfbf2a4949
(cherry picked from commit 3bc623be8d)
This partially reverts the previous commit [1], which allowed special
components to be granted some pre-configured default permissions.
With this CL, we no longer grant Contacts permissions to pre-installed
IMEs. Rationals are:
1. Even without this CL, not the all pre-installed IMEs are granted
Contacts permission by default, because it was done during the boot
time where InputMethodManagerService is not yet completely
initialized. The current behavior is confusing not only for users
but also for developers.
2. In almost all the cases, IMEs are supposed to be able to work
without Contacts permission. Hence it is not too late to ask users
to grant the permission to the IME after the initial setup is
completed.
3. It is difficult to add new features such as File-Based Encryption
(FBE) with keeping the current implementation, because currently we
dynamically call mSettings.setCurrentUserId(userId) just to
enumerate what IMEs will be enabled for a given user. Adding
another condition (whether the user has already unlocked the device
or not) would make things more complicated.
Note that LatinIME has already support the case where Contacts
permission is not granted by default. It does not ask users for
anything until Setup-Wizard is completed, and requests Contacts
permission only when the user taps a message in the suggestion strip
that suggests users to use contacts name for typing suggestions.
[1] If8b8cadbd1980ffe7a6fc15bbb5f54a425f6e8f9
adc1cf4604
Bug: 24756974
Bug: 26743676
Change-Id: Ief2a40b5971b3eb97d765f934d20ce7f2ef25665
And set the drawable's callback to null during drag-resizing, since
we use multi-threaded renderer, will do not want to schedule draws
to the ViewRootImpl's thread.
bug: 26729953
Change-Id: I6e5f94a5a6ba15edc2d391dd11d8fee3c657d337
(cherry picked from commit 1cc95075e8)
An app can now declare that it really needs to be backed up
whenever possible even if it is currently engaged in foreground-
equivalent work. Only applies to full-data backup clients: key/value
backups are not intrusive on normal lifecycle so they can already
happen in such circumstances.
Bug 26790411
Change-Id: Ia0ebcc7a53da888ae9ae4d63cd4bcab6e3a2e866
