am: 0c5a42fc6f
* commit '0c5a42fc6f04e8ef4efce246750e06a9be9676f5':
Make BlockSuppressalStatus constructor public so that it can be constructed by the provider.
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
Which really means, make background check much more
strict, with an option to revert to the more lenient
behavior.
In this strict version, an app can't have services
started or receive broadcasts at any point when it is
not foreground. Also, it doesn't matter the importance
of a caller trying to start a service, it only depends
on the state of the app whose service is being started.
A new activity shell command allows you to control
whether to use the strict or lenient behavior.
Change-Id: I660df480dd55575a38c9542210210ec53e34eca0
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
For the initial release of Marshmallow auto-launching was suppressed
for ChooserActivity if there was only a single choice in order to let
the user confirm what would be launched. In practice, many apps use
ACTION_CHOOSER when they should probably use implicit intents, but
still others have use cases where setting a default doesn't make sense
and the user should still be able to make a choice when one is
available.
As the user confirmation didn't buy much in terms of developer API
expectations (ACTION_CHOOSER being a forced choice) and it adds
speedbumps to existing apps in the ecosystem, revert this change.
Bug 27243827
Change-Id: Id8fd5385d5b1f459e80b0096efe7e2944264739a
