Quiet mode means the user will be free from visual and audio interruptions
from apps inside the managed profile, including notifications, widgets and
others. This CL adds the underlying state bit to users and exposes various
APIs to control and query the quiet mode state.
Bug: 22541941
Change-Id: If5f8e5a897843050e83b6ec26cb39561098f12b9
Added APIs that allow activities to ask the system if they are currently
in multi-window or picture-in-picture mode and also get notified when
their modes change.
Bug: 25509834
Bug: 25683717
Change-Id: I4b8c316a49940bd6a8b31a93b345f9fd725a4721
What this CL actually does is just copying the existing concept
"subtypeId" from InputMethodSubtype to SpellCheckerSubtype.
To recap, the underlying problem is that the system has stored only the
return value of SpellCheckerSubtype#hashCode() to track the set of
enabled subtypes, and SpellCheckerSubtype#hashCode() has been
implemented as Arrays.hashCode(new Object[] {locale, extraValue}), which
is problematic because:
- Spell checker developers cannot change "locale" and/or 'extraValue'
if they want to keep enabled subtypes enabled.
- Android Framework developers cannot change the hash function even
when new fields are added if they want to keep enabled subtypes
enabled.
InputMethodSubtype has had the same issue, and what we did was
introducing a concept "subtypeId", which allows IME developers to
specify the return value of #hashCode().
For instance, suppose that a subtype X has already been used in
production with the following attributes:
- locale: "tl_PH"
- extraValues: "key1=value1,key2=value2"
With "subtypeId", you can change the attributes of subtype X without
losing the enabled state of subtype X on devices as follows.
- locale: "fil_PH"
- extraValues: "key1=value1,key2=value2,key3=value3"
- subtypeId: Arrays.hashCode(new Object[] {
"tl_PH", "key1=value1,key2=value2"})
This CL also deprecates existing public constructor of
SpellCheckerSubtype, which was probably published as a public API by
mistake. Note that the constructor of SpellCheckerInfo class is @hide.
Also there is no public API that receives SpellCheckerSubtype object
instantiated by developers with custom data. Making developers to be
able to instantiate SpellCheckerSubtype does not make sense right now.
Bug: 11736916
Bug: 22858221
Change-Id: I98f05c1e9421c47a93769bc4a6fe11b678bc2509
The system can now boot in a "locked" state where only encryption
aware (EA) components can be safely started. When in this state,
PackageManager already filters away non-EA components, but system
services like AccountManager and SyncManager need to carefully handle
these temporarily "missing" components.
As a guiding principle, all known Accounts are still present when
the device is locked, but communication with underlying non-EA
authenticators is blocked.
To keep things simple for now, all SyncManager requests are kept
dormant until the user enters the unlocked state.
The core of this logic is that RegisteredServicesCache now works
with all components regardless of EA status, which prevents us from
accidentally thinking a service was removed when the user is locked.
Bug: 25945136
Change-Id: I8714121f6236b00821769023c4df7de1c8a99944
The primary goal of this CL is to enable application developers to
provide more context-based language (locale) information for IME
developers so that users can be benefited by more natural text input
experience.
As of API Level 23, there are several APIs that allow IMEs to retrieve
locale/country related information.
- Locale#getDefault()
- Configuration#locale
- LocaleSpan#getLocale()
- SubscriptionInfo#getCountryIso()
However, only LocaleSpan#getLocale() can be used to pass application
specific languge (locale) context from applications to IMEs. Also
LocaleSpan is not designed to be used per input-context. We want to
have something in EditorInfo and LocaleList would be the right thing.
Although default implementation of TextView#onCreateInputConnection()
starts filling EditorInfo#localeList with TextView#getTextLocales() by
this CL, application developers are encouraged to provide its own
LocaleList when they are confident that the user want to use a
certain (set) of language(s).
For instance, a chat application may be able to guess what language will
be used in the conversation before the user start typing. At least it
should be able to remember the last used language for each conversation.
Another instance would be "From" and "To" EditText fields in a
translation app. Those fields should have different LocaleList based on
the languages that the user want to translate from and to.
Bug: 22859862
Change-Id: I77db5b99a7cf745d800db75baf135bb60ad04820
This is a preparation work to pass LocaleList from TextView to IMEs via
EditorInfo.
Marshalling and unmrshlling LocaleList via Parcel is actually not so
difficult. We can reuse its internal data representation "localeTags"
as a canonical serialization format.
As for implementation, there are two choices. One is making LocaleList
Parcelable and the other is having a utility method to do that.
This CL uses Parcelable approach so that not only Framework but also
application developers can reuse the code.
Bug: 22859862
Change-Id: Ib28363bd5ff74228d2abeaa95004ec8bed72bddd
- add config to lock UI mode change: When this is enabled,
request to change car mode will be ignored. Apps can check
the config using UiModeManager.isUiModeLocked()
- add config to lock day / night mode: When this is enabled,
apps cannot change day / night mode without having
MODIFY_DAY_NIGHT_MODE permission.
Apps can check the config using UiModeManager.isNightModeLocked()
- add config to disable car dock intent launch for home key
and mode change
- All new configs have default values which keeps the current behavior.
Car products should override the configs to get desirable behavior.
bug: 22700993
Change-Id: Ic0e58f3428151e0b1c19a2e9a7d6ded32ff962a6
When a user is first started, we assume that they're "locked" meaning
that credential-encrypted data is unavailable. Once credentials have
been supplied, we can transition the user to a fully running state.
To facilitate this lifecycle, UserState now has two separate
RUNNING_LOCKED and RUNNING states. To ensure consistent events are
sent on all devices, we always step through RUNNING_LOCKED before
arriving at RUNNING. This consistency means that apps processing
data based on the new ACTION_LOCKED_BOOT_COMPLETED broadcast and
system services using the new onUnlockUser() event will be less
bug-prone over time.
If the user storage is unlocked (which is the case on the majority
of legacy devices), we immediately transition from the RUNNING_LOCKED
into the RUNNING state.
Add logging for all state transitions.
When we "recover" a user in the process of being shut down, return
to the last known state.
Bug: 25943941
Change-Id: I5fec980f10b0d0fb2c272a662d193dc15136f9b9
This API allows a single assistant on the device to help the
user manage their notification stream by taking actions on
individual notifications:
- modifying their priority up or down when they are posted
- possibly changing if and how the notification interrupts the user
- adding annotations under notifications
Bug: 22455414
Change-Id: Idf47972bb71c83f1dc1c9ec68a6fa92ac4fc522f
Add a TYPE_QS_DIALOG window type, that is in the same layer as
apps and dialogs and such. It is guarded by having a token
that is granted by SysUI after a click has occured. If the
app shows a dialog before listening finishes (QS closes) then
the token will stay granted until the tile is removed by the
user, otherwise the token will be removed immediately to avoid
later dialogs.
Also fix a couple tiny TileService issues:
- Stop/Start listening reversed
- Fix javadoc referencing wrong action
Change-Id: Iedcdd5fd9a2af2b33eb7f6f17bb0e6c997879876
This is required to expand metadata capabilities of DragEvent.
Apps receiving ACTION_DRAG_* events have access to
ClipDescription, but not ClipData.
Adding extras to ClipDescription allows for a richer behavior of apps
responding to these events.
Bug: 25788641
Change-Id: I07e374f71d16f8441dc3a0b02c7d833e0139b74b
The status has always been there in error cases, it is now also visible
in non-error cases.
If the progress is not set, no progress bar is shown.
Bug: 24135025
Change-Id: Iea23f45d236365433c6f6739597833d236ed6d19
Needed to support storage of SharedPreferences on both credential-
encrypted and device-encrypted storage paths.
Bug: 22358539
Change-Id: I576b696951b2a9de817d5be63d31b06f7e166a19
When the correct lock pattern is presented, ask the system to also
unlock credential-encrypted storage, if enabled. The token passed
along is empty for now, but can be wired up to gatekeeper in the
future.
During each system boot, ask vold to lock all users keys to give us
a known starting state. This also has the effect of chmod'ing away
any CE data when in emulation mode.
Define and send a new foreground broadcast when the CE storage is
unlocked for the first time. Add stronger last-ditch checking for
encryption-awareness before starting an app.
Bug: 22358539
Change-Id: Id1f1bece96a2b4e6f061214d565d51c7396ab521
One intent notifies the new and previous default sms app when the user
changes which app is the default sms app. The second intent is sent to the
default sms app when some other white-listed app, such as Android Auto or
the phone, modifies the Telephony db behind the default sms app's back.
Change-Id: Iee1e1c4a4c299846f382bd8247c295cf7aaa040e
