Rename APIs to reflect that they're storage-related. Also move
credential-storage APIs to be system API.
Return a null Context when device-encrypted storage isn't
supported. This is the easiest way to keep legacy apps working when
upgrading from M to N.
Reduce strictness of path checking so we don't crash when working
with special packages like "android".
Bug: 22358539, 26104027
Change-Id: I38c24fc003488186210a6ae3b64270f86e1efe56
This reverts commit 9c2f0d751d.
The original commit, 17b2b2d458, had
missed adding api/test-current.txt.
Change-Id: I26a6325b3cee4c2412ee599f002cc6addb35d36f
This reverts commit c55d5072ac.
There were several bugs related to incorrect handling of various
layout issues (layout not being run on containers/views that needed
it), reverting to take another run at it outside of master.
Issue #25980198 requestLayout() sometimes doesn't result in measure/layout for view
Change-Id: Ic0e159cbcf6171652d8fd1bee9ae44a3977cea04
The algorithm tries to find the first locale in the locale list
(usually from the user preference) that somewhat matches one of the
locales supported (usually from the list of locales supported by the
system or an app).
Locales match if both their language and their likely script is the
same. Otherwise they don't.
Bug: 25800576
Change-Id: I4fbc3f44ab16d41efebbf941e94a0bb30d598f82
There are far too many Context APIs with special directory paths
to replicate device-encryption versions of them all. Instead, add
methods to clone a Context that explicitly stores its data in either
credential- or device-encrypted storage.
Methods to test the behavior of a given Context.
Bug: 22358539
Change-Id: I6a6290a9b282605ce9a1f82742fc2c4c50536754
Add APIs for an ephemeral app to set a cookie which is a small
peice of data cached longer than the app itself. This is useful
for avoiding the user to login every time they use the ephemeral
app. The cookie is stored after an ephemeral app is uninstalled.
Normal apps or ephemeral apps upgraded to full apps can also use
these APIs with the difference that once they are uninstalled
the cookie is deleted.
The cookie size defaults to 16KB and is configurable by a global
settings which can be adjusted via gservices. Also eviction policy
is time based with a default of one month and is configurable by
a global setting which can be adjusted via gservices. If the cert
of the app cahnges (when ephemeral is installed, uninstalled and
installed again) the cooke is wiped to prevent data leaks.
This cahange also adds an API for apps to know whether they run in
an ephemeral mode since it this mode some APIs will not be available.
Another API exposed by this change is private for the system and
exposes all ephemeral apps - installed and uninstalled. Only the
system can call this API. When an ephemeral app is uninstalled the
system stores its name, icon, and permissions. When the app is
reinstalled or a full version is installed the permissions are
propagated.
Change-Id: Id4a73a7750bfbabda0bfcb9bf9018d2062e94367
The keypair is specified by alias and removed via a call to the
KeyChainService, which will have installed the pair in the first place.
Bug: 22541933
Change-Id: I37317e7c22e89816156e6e9a7abf4c5a59e8440a
Needed for apps that want to migrate SharedPreferences from CE to DE
storage. Note that a device will only ever enter a CE mode with a
factory reset, so apps should only be using these APIs when they
want to migrate files to a consistent location on non-FBE devices
for simplicity.
Bug: 25503089
Change-Id: Ic846215da1617d116a048e036415ac7ad523b770
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
