In order to support BYOD (Bring your own device) use cases, Android
phones can associate multiple users into a single profile group so
that other system components such as launcher can help users
seamlessly switch user identity without doing a heavy-weight
device-level user switching.
For instance, an Android device can be configured to work for two
different users Alice and Bob, while Alice also has two different
identities: one as her private account and the other for her
work-related account.
Profile group X == Alice:
Parent user X (user id: 0)
for personal account, under her control.
Child user 1 (user id: 10)
for work-related account, partly under system-admin's control.
Profile group Y == Bob:
Parent user Y (user id: 11)
private account, under his control.
The above configuration allows system-level data separation not only
between Alice (user 0) and Bob (user 11) but also between Alice's
personal account (user 0) and Alice's work-related account
(user 10). For instance, Calendar app that runs under user 0 cannot
see any data for other users including user 10.
IME is one of known exceptions in the above design. For instance, when
Alice is using the device, the system launches InputMethodService,
which is the code-level representation of IMEs, only for the user 0
then gives it a special ability to interact with all the applications
that run under the same profile group.
Profile group X == Alice:
IME works as user 0 but interacts with apps that run under
user 0 and 10.
Profile group Y == Bob:
IME works as user 11 and interacts with apps that run under
user 11.
Of course there are non-trivial imprications by sharing the same
instance of InputMethodService across profiles but this was basically
the only option when we initially introduced in Android 5.0 [1]
because of multiple challenges (schedule, complexity, performance
concerns, and so on). To to mitigate the risk, we also introduced APIs
that allow system administrators to whitelist what IMEs can be enabled
for the entire profile [2]. Even with such a whitelist feature, we
have received multiple feature requests to completely separate IME
instances by profile boundaries, like other applications behave.
This is why this CL was authored.
With this CL, a new runtime mode "per-profile IME" is introduced
behind the flag. When the flag is enabled:
* InputMethodManagerService (IMMS) may calls IMMS#switchUserLocked()
from IMMS#startInputOrWindowGainedFocus() every time when a
different profile's IME client gains IME focus.
* SpellCheckerService also enables per-user mode, which has been
temporarily disabled [3].
* DevicePolicyManagerService no longer disable packages that contain
system IMEs when creating a new profile user.
* Following IME APIs start returning result based on the caller's
user (profile) ID.
* InputMethodManager#getInputMethodList()
* InputMethodManager#getEnabledInputMethodList()
* InputMethodManager#getEnabledInputMethodSubtypeList()
There are still multiple known issues though. Hopefully we can address
those issues in subsequent CLs.
* Inline-reply from non-primary profiles is still dispatched to the
main profile's IME because SysUI is always running under main
profile (Bug 120744418). This probably can be addressed by
allowing the IME clients that have INTERACT_ACROSS_USERS_FULL to
specify the target user ID in some @hide parameter.
* IMMS#switchUserLocked() is not yet fully optimized (Bug 28750507).
New client app's UI thread can be blocked more than 100ms,
depending on the number of installed IMEs and the number of IME
subtypes implemented by those IMEs.
* Even after IMMS#switchUserLocked() is fully optimized, IMEs'
cold-startups are known to be slow. One way to optimize this is
keeping binding to those IMEs, but doing so would require 1)
non-trivial amount of code changes and 2) doubles RAM consumption.
* Virtual keyboard settings page for profile users are not yet
available (Bug 120748696).
* Migration from shared-profile IME mode to per-profile IME mode is
not yet supported (Bug 121348796). By default, IME packages will
be automatically disabled when a profile user is created. This
means if the device switches from shared-profile IME mode to
per-profile IME mode, IME packages continue to be disabled hence
the user cannot type anything for those profiles.
Anyway, there should be no behavior change unless the debug flag is
explicitly flipped.
[1]: I3bd87b32aec69c3f8d470c8b29b144f4e849c808
734983fff3
[2]: I921888660d29a5370395db87adf75d4d106660c9
9c9cbac5b71a23ed0dbab0f44cb78a820514cfc6
[3]: Ic046f832f203115106409a53418a5746eb6d4939
3f8c568883
Fix: 120709962
Test: atest CtsInputMethodTestCases CtsInputMethodServiceHostTestCases
Test: Made sure that there is no behavior change if the debug flag is
not set as follows.
1. Install Test DPC
2. Enable managed profile with Test DPC
3. make -j EditTextVariations
4. adb install -r $ANDROID_TARGET_OUT_TESTCASES/EditTextVariations/EditTextVariations.apk
5. Open two EditTextVariations instances in split-screen mode
5.1. One is for the main profile
5.2. The other is for the managed profile
6. Make sure that main profile's instance of AOSP Keyboard is used
for both applications.
7. Make sure that main profile's instance of Android Spell Checker
is used for both applications.
8. adb shell ime list -a -s --user all
-> Only "com.android.inputmethod.latin/.LatinIME" is shown.
9. adb shell dumpsys textservices
-> Only result for user #0 is shown.
Test: Made sure that basic text input can be done with
"per-profile IME" mode enabled as follows.
1. adb root
2. adb shell setprop persist.debug.per_profile_ime 1
3. adb reboot
4. Install Test DPC
5. Enable managed profile with Test DPC
6. make -j EditTextVariations
7. adb install -r $ANDROID_TARGET_OUT_TESTCASES/EditTextVariations/EditTextVariations.apk
8. Open two EditTextVariations instances in split-screen mode
8.1. One is for the main profile
8.2. The other is for the managed profile
9. Make sure that AOSP Keyboard will be re-launched to correspond to
the focused IME client's user profile.
9.1 When EditTextVariations for the main profile is focused,
AOSP Keyboard for the main profile is shown.
9.2 When EditTextVariations for the work profile is focused,
AOSP Keyboard for the work profile is shown.
10. Make sure that different instances of Android Spell Checker are
used based on target application's profile
11. adb shell ime list -a -s --user all
-> "com.android.inputmethod.latin/.LatinIME" is shown for both
user #0 and user #10.
12. adb shell dumpsys textservices
-> Both user #0 and user #10 have results.
Test: atest DevicePolicyManagerTest#testSetPermittedInputMethods_failIfNotProfileOwner
Test: atest com.android.server.devicepolicy.OverlayPackagesProviderTest
Change-Id: Ied99664d3dc61b97c919b220c601f90b29761b96
Completely deprecate LOCATION_PROVIDERS_ALLOWED (but still support it).
Adds additional locking and @GuardedBy annotations where appropriate,
and some minor code cleanup is copied from previous CLs.
Bug: 118885128
Test: Manual + CTS
Change-Id: I3c0b4b2354a4c2b6a120fc467af60cb3409dd671
Synchronize settings between sound and accessibility menus
Bug: 116172311
Test: See accessibility vibration settings - ring and notification
settings sould be separate. Try changing vibration settings in sound and
accessibility menus - the settings should stay in sync.
Change-Id: Ia0276dfdd0efafe211c14cda140831b57f8c42b1
Add a new key-value pair to smart_replies_in_notifications_flags that
controls the default tap-to-edit behaviour.
Bug: 111437455
Test: atest SmartReplyConstantsTest
Test: Try "adb shell settings put global smart_replies_in_notifications_flags edit_choices_before_sending=true" and observe
Change-Id: Ida90b98c28f4183697e84a6722768d41c72dd9cf
cherrypick ag/4808863
Bug: 112553298
When press power key on soundbar, CEC type is 5(audio system),
it will send command to tx and rx devices to let them go to standby mode
Test: Tested with a TV
Change-Id: I242fb1028b5ae003e6054fe9b54e10d1f433374c
Entries from DownloadProvider are added to MediaStore Downloads
collection. COLUMN_MEDIASTORE_URI will be used to track corresponding
entries in MediaProvider. We can't re-use COLUMN_MEDIAPROVIDER_URI
for this purpose because it is updateable by apps.
Bug: 120876251
Test: atest DownloadProviderTests
Test: atest cts/tests/app/src/android/app/cts/DownloadManagerTest.java
Test: atest MediaProviderTests
Test: atest cts/tests/tests/provider/src/android/provider/cts/MediaStore*
Change-Id: Ifd252c54f4ee739a31be2866896efac6696a088e
The "delete" operation is immediate and permanent, and users may wish
to instead mark content as being "trashed", so they can recover
accidentally trashed items before they're permanently deleted.
The default trash timeout is 48 hours, which should be enough time
to recover items the user cares about. Apps can also use a custom
timeout if desired.
This is implemented by recording an "expiration" time for trashed
items, and deleting expired items during the next idle maintenance
pass. Also use this expiration time to clean up pending items that
haven't been published; by default apps have a day to publish
pending items.
Bug: 121227045
Test: atest MediaProviderTests
Test: atest cts/tests/tests/provider/src/android/provider/cts/MediaStore*
Change-Id: I2e371b308dc135ad5363709a6f5385e4456bcb96
The existing buckets work well for first-level clustering of related
media, but it's common for multiple media items within a directory
to form a conceptual unit. To support this, we're creating a
second-level of bucketing which is formed using the first part of
the file name.
This supports common industry-standard patterns like:
IMG1024.JPG
IMG1024.CR2
While also opening the door to further flexibility in the future:
IMG1024.JPG
IMG1024.HDR.JPG
IMG1024.BURST001.JPG
IMG1024.BURST002.JPG
IMG1024.BURST003.JPG
IMG1024.DNG
IMG1024.DEBUG.BIN
We're currently advocating that the default representation of one of
these secondary clusters is the shortest .JPG filename contained
inside, with length ties broken alphabetically.
Clean up database management so that upgraded schema always matches
pristine schema, with tests to verify. Generate views using the
actual projection mappings used at runtime.
Bug: 115377970
Test: atest MediaProviderTests
Test: atest cts/tests/tests/provider/src/android/provider/cts/MediaStore*
Change-Id: Ic679055ab6c884d2048626f51670a5dd370281c0
Also update SettingsProvider to resolve calling packages based on uids
when receiving calls to put or reset values in the config table. This
was necessary because the command line tool calls the DeviceConfig API,
which calls through to SettingsProvider. That was resulting in a
shell uid with an android package prior to this change.
Test: atest SettingsProviderTest:DeviceConfigServiceTest
Bug: 122304633
Change-Id: Ic80c734eb75dcaac688507c241b0995b7488a84f
We updated the development opt in mechanism for GUP. Now we have
GUP_DEV_OPT_IN_APPS for applications selected to use GUP and
GUP_DEV_OPT_OUT_APPS for applications selected not to use GUP.
Bug: 119221883
Test: Build, flash and boot, verify with prototype
Change-Id: I52869ecf9e411a8dbdc1146f00c82023ba41bebf
We have rebranded this project to Game Update Package, and GUP for short.
BUG: 119221883
Test: Build, flash and boot. Verify by going to developer options.
Change-Id: If284bd3e0b29cb025833be29fa33179011c151d7
It's an index of data scanned from disk, and it's been misleading to
let people mutate that data directly in MediaStore, since those
edits aren't durable in any way. We never updated the metadata in
the underlying files, so any changes would be lost when moving
between devices.
This change moves to always re-scan files after they've been edited,
to ensure we pick up metadata changes. It also ignores direct edit
attempts from apps.
Bug: 120711487
Test: atest android.media.cts.MediaScannerTest
Test: atest cts/tests/tests/provider/src/android/provider/cts/MediaStore*
Change-Id: I4cc3ae24d6c6b5f01fe4bb47610ccf162c81ce83
For display white balance and grayscale
Bug: 111215474
Test: atest FrameworksServicesTest:ColorDisplayServiceTest
Change-Id: I5c7b6543665e520b4e167ac8e6719f337018f172
We provide a way for OEMs to kill-switch Content Capture, but it currently
does not work in the first boot (which uses default settings).
This CL changes the mechanism:
- If the property is not set, it assumes it's disabled (before it was only
disabled when explicitly set to "false").
- To always enable it, it must be set to "always" (before it was "true").
- To check for the overlaid resource, it must be set to "default" (before it
had to be unset).
Test: manual verification
Fixes: 121144410
Bug: 121153631
Change-Id: Ie669e43d9dce947a7bb31bc3b1768774f724675f
The existing APIs were pretty limited by only accepting a "kind"
value, so improve them to accept an arbitrary size, and offer a way
to cancel requests when no longer needed.
The older APIs were a mix of both public and @UnsupportedAppUsage,
so mark them all both public and deprecated so we can clearly steer
developers towards better options. (The deprecated methods are
implemented using the new APIs internally for sanity.)
Use modern ImageDecode internally, which is more robust than
BitmapFactory. Add CTS to confirm that we generate thumbnails of
reasonable sizes.
Bug: 119887587
Test: atest android.media.cts.ThumbnailUtilsTest
Change-Id: I4ca35569ad5c661b327a0cb24a48ebc21f6087b7
Moving forward as we start enabling isolated storage in various
dogfood groups, we'll need to maintain separate values for the
feature flag for both "local" and "remote" opinions. Any strongly
expressed local opinion will always take precidence over any remote
opinion.
Any changes to these feature flags means that we need to invalidate
any PackageManager parsed APKs, since PackageParser changes it's
output depending on the flag state. Since other feature flags are
likely to need this type of invalidation in the future, define the
PackageManager cache using a SHA-1 hash of a collection of values
that should invalidate the cache.
Bug: 112545973
Test: atest android.os.SystemPropertiesTest
Change-Id: Ifafcdf15e40e694eb4126e06981aeb82df51da33
Update DeviceConfigService to call DeviceConfig API directly for get,
set, and reset. Remove the duplicated content uris from various places
in favor of the single constant exposed in DeviceConfig.
Test: atest FrameworksCoreTests:DeviceConfigTest
atest FrameworksCoreTests:SettingsProviderTest
atest SettingsProviderTest:DeviceConfigServiceTest
Bug:109919982
Bug:113100523
Bug:113101834
Change-Id: I46d110c4fd29a89af383629d26de4ee39ca852a6
Initial prototype disabling location/sensors and enabling airplane mode.
Camera/Mic will come in a followup.
Test: manual
Bug: 110842805
Change-Id: I26132fcc9ffea83e3e78a0e54882d23c99ee590c
This change adds a mode that changes how trust is used by the
platform. In this mode, a trust agent that reports the device to be in
a trusted state is only able to extend how long the device stays
unlocked (before needing credentials or biometrics), but cannot
actually unlock a locked device.
The change is off by default, and comes with secure settings variables
to control the behavior. This is a temporary convenience for
dogfooding and we expect extended access mode to become the default
for Q.
Bug: 111435975
Test: Tested with SmartLock modules to confirm extend unlock behavior
works as expected.
Change-Id: Ie63a4235f5ad144d4ffb5dd308cc2cef886cb8ef
A Settings Panel is a dialog that contains a fixed subset of
settings to address a particular user problem. The ultimate
goal is that users can solve problems in-app rather than going
into settings. This is limitted to to "safe" settings which do
not need the full context of the settings.
The Settings are hosted in a Settings activity, which prevents
scraping from the calling app.
Test: make -j40 RunSettingsRobotests, manual app
Test: atest SettingsPanelTest
Fixes: 117804442
Change-Id: I3afb9e235959d0e4bc889747c4518de89918674c
The package name will be used by Permission Controller to properly
handle permissions for location history package.
Bug: 119226131
Test: manually tested on device
Change-Id: I522517272c132a054c44489d16626509cf2b42ee
