* changes:
Atom: initPortInfo when receive hotplug from tx for audiosystem device[1/3]
handle manual port switching
Claim Active Source during System Audio Mode init by AVR when the device also has playback type and can't get Active Source.
Switch away from ARC input when ARC is terminated.
Request Active Source when ARC is enabled in ArcInitiationActionFromAvr.
Refactor the Active Source updating logic in CEC devices.
Fix tests failure on com.android.server.hdmi
Making functions visible for testing com.android.server.hdmi
Back out unneeded ag/4808863. Standby has been handled in ag/4881453.
For experiment flag testing, add input_native_boot flag in DeviceConfig
Test: presubmit
Bug: 120794829
Change-Id: I1ee76cb1210379bd5c04c19de71c777948c2dad3
With this CL we add a new key-value pair to
smart_replies_in_notifications_flags to control whether smart
suggestions should be turned on for heads-up notifications. By default
the suggestions are turned ON.
Bug: 122351821
Test: atest SmartReplyConstantsTest
Test: Run "adb shell settings put global
smart_replies_in_notifications_flags show_in_heads_up=false" and ensure
heads-up notifications do not contain smart suggestions.
Change-Id: I84292c10a4545112b0e993af33bb01a8cc18ce23
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
This change is the main check in for the historical app op feature.
The idea is to store a historical data about past app op rejections,
accesses, and durations per op for any UID state indefinitely.
Keeping all operations on record is not practical as app ops are
very frequently performed. To address this we are storing aggregated
data as snapshots where we store for every UID and its packages
how many times each op was accessed, rejected, lasted as an aggregate.
To allow history scaling indefinitely we are taking a logarithmic
approach with only the most recent state stored in memory and all
preceding state stored on disk. State on disk is stored in separate
files where each preceding file, i.e. for an older period, would
cover X times longer period with X number of snapshots covering
X times longer period. Initially X is ten but can be tweaked. For
example, the first file could contain data for ten days with daily
snapshots, while the file for older period would have data
for a hundred days with snapshots every ten days, etc.
The implementation is optimized for fast history update and no impact
on system runtime performance and minimizing memory footprint. We
are lazily persisting state to disk on a dedicated thread as this is
slow. We are also reading the relevant historical files on a query
as this is very rare as opposed to state updates.
The base snapshot interval, i.e. snapshot time span, in the initial
iteration and the logarithmic step are configurable. These can be
changed dynamically and the history would be rewriten to take this
into account.
Test: atest CtsAppOpsTestCases
bug:111061782
Change-Id: I55c32c79911ba12b2ace58d2a782b8df1e6bff60
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
This should make adding new methods that shouldn't be public easier.
Bug: 119261320
Test: atest com.android.server.power.PowerManagerServiceTest
and com.android.server.power.batterysaver.BatterySaverPolicyTest
and com.android.server.power.batterysaver.BatterySaverStateMachineTest
Change-Id: I8fdba4257be3d5602a738d2fffd55385775c3f81
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
