This CL expands the existing UiModeManager APIs to allow users activate
dark mode at their configured bedtime schedule on supported devices,
i.e. devices with Digital Wellbeing preinstalled.
The CL added granular types for NIGHT_MODE_CUSTOM. There are two types
1. MODE_NIGHT_CUSTOM_TYPE_SCHEDULE
This is the type for a schedule set up by users via the Settings
app.
2. MODE_NIGHT_CUSTOM_TYPE_BEDTIME
This is the type for a bedtime schedule set up by users via the
Digital Wellbeing bedtime settings. Unlike
MODE_NIGHT_CUSTOM_TYPE_SCHEDULE, Android framework doesn't have
any information of the bedtime schedule. The activation of dark
theme lives inside Digital Wellbeing
Test: unit tests: atest FrameworksUiServicesTests:UiModeManagerServiceTest
CTS: atest CtsAppTestCases:UiModeManagerTest
Manual testing via a system app integration
Bug: 210975231
Change-Id: I3b16e649a048f8a485b9e9d6464d4f251839320d
This facilitates exposing the Parsed_ classes as
@SystemApi(client = SYSTEM_SERVER) while keeping everything inside
services.jar rather than having it split across both jars.
This reverts getPackageArchiveInfo to use legacy PackageParser, since
framework.jar can no longer access the moved classes.
Bug: 214038417
Test: presubmit, no logic changes
Change-Id: I152d70fb4f643d32efb012cfb20b0fbc5f88f2d8
This system service is no longer needed, as there is no longer a shared
lockscreen.
Test: locally on device
Bug: 206054365
Ignore-AOSP-First: cleanup
Change-Id: Ib2db06c377cf632da77dc41c629debfe658bfc48
Change the api from system to public api so that 3p installers can also use it.
Bug: 210981031
Bug: 193787310
Test: atest FrameworksServicesTests:LocaleManagerServiceTest
Test: atest CtsLocaleManagerTestCases
Change-Id: I98137941749725fbf2fe57d4a33d6abd8f99fffa
Add APIs to update and retrieve enterprise-related system drawables,
the APIs are guarded by a new permission that will be granted to the new
device management role holder.
Bug: 203548565
Bug: 188410712
Test: manual
Change-Id: Iab29db23a87e1481ba7e2996a704dcb2702444be
As CL[1] introduced WindowTokenClient for WindowProviderService (aka the
parent class of InputMethodService starts from CL[2]) as a token that
IME context can associate with the windowContainer of
the InputMethod window in server side. Like the activity context,
IME context can adopt configuration/resources update when the IME
window changed by display/window changes.
And, the IME context caller can also create another type of context
with wrapping IME context (i.e. calling createDisplayContext to create
a display context), that makes this context can be mixed the window
token of WindowProviderService since it's the base context.
However, the finalization of the context mixed WindowTokenClient
will detach the token when the attached context type is non-window
context, this action will mis-detach the token when it managed by
WindowProviderService.
So like SoftKeyboard previously using
createDisplayContext in CL[3] to workaround context resources issues,
will in-directly expose this mis-detach token issue as the above.
Beside, the handling of WindowTokenClient#{onConfigurationChange,
onWindowTokenRemoved} does not thread-safe since this is called from
IPC.
As the result, the fix is to ignore the check in ContextImpl#finalize
to not detach the token when it managed by WindowProviderService,
also make sure to post to the main handler when received
onConfigurationChanged/onWindowTokenRemoved in WindowTokenClient.
Note that this fix could help to resolve "The Window Context should
have been attached to a DisplayArea." exception if the token has been
detached as the above case that happens before the next
WindowProviderService#attachToWindowToken invoked.
[1]: I64a1614f32d097785915f6105b1813a929e0fe32
[2]: Ie565e30ed5dd3f2cfe27355a6dded76dc3adc14b
[3]: Ic592a1d2fb2da149220c8b503b522b3e864bcc77
Bug: 213118079
Bug: 211062619
Test: manual as steps:
1) adb install -r EditTextVariations.apk
2) adb install -r SoftKeyboard.apk
3) adb shell ime enable com.example.android.softkeyboard/.SoftKeyboard
4) adb shell ime set com.example.android.softkeyboard/.SoftKeyboard5
5) Enable screen auto-rotation
6) Launch EditTextVariations from launcher's shortcut
7) Tap the first EditText field to show IME
8) Rotate the device to the landscape mode
9) Expect the IME should not be shrunk
Change-Id: I7beb7a122af93e596239a36db62073233cea0726
Currently, notification-seen event will promote an app to
Working set bucket. This change adds a knob to allow changing
the bucket that the app gets promoted to on a notification-seen
event.
This change also updates AppStandbyController logic to allow
setting timeouts for buckets other than Active and Working set.
Bug: 206518483
Test: atest --test-mapping apex/jobscheduler/service/java/com/android/server/usage/TEST_MAPPING
Change-Id: Ic818c3871a34107b86b97c983285214beea220a5
This can lead to a rapid unlock -> lock -> unlock cycle while keyguard is showing.
Bug: 210897417
Test: manual (unlock with fingerprint and verify adb logcat | grep keystore2::authorization shows 1 entry)
Change-Id: I318aaf52a3540f7209f3622e877f8935cffc7f6c
Parse the contents of LocaleConfig's XML to obtain the app-specific supported locales
Bug: 203015582
Bug: 193787310
Test: atest LocaleConfigTest
Local test APK
Change-Id: Ie9314e4c09f881f834bf7ea3cc0780d1545e6ce7
Currently, 'dumpsys activity' can dump the state of some managers:
- AutofillManager
- ContentCapturemaanger
- UiTranslationController
But the support for these custom dumping is hardcoded into
Activity itself, which makes it harder to extend. For example,
automotive builds provide an app-side Car object, which currently
cannot be dumped.
This CL makes the mechanism more flexible by providing a couple new
public / SystemAPIs that let Automotive (or other mainline modules)
extend it.
Examples:
$ adb shell dumpsys activity com.android.car.carlauncher/.CarLauncher --list-dumpables
$ adb shell dumpsys activity com.android.car.carlauncher/.CarLauncher --dump-dumpable CarUserManager
$ adb shell dumpsys activity service com.android.systemui/.SystemUIService CarUserManager
NOTE: this CL only adds the new APIs; a follow-up CL will change the
existing managers to use them.
Test: see above
Test: m update-api
Bug: 149254050
CTS-Coverage-Bug: 149254050
Change-Id: I6920ff3542d3d75edd667c2c7658e9d0a7af534f
If apps have conversations but not bubbles, we still show bubble settings
for them which is confusing for users. This change exposes whether an app
has sent a notification with valid bubble metadata, this allows us to hide
the setting until a bubble is actually sent.
If the app directs the user to bubble settings via the public intent,
they are still available.
Test: atest PreferencesHelper
Bug: 178387292
Change-Id: I7d3d92df49e7f4ed1d2c05cbba5f6f7786789d32
Revert submission 16468379
Reason for revert: Feature development is moving to T.
Reverted Changes:
Id9b9a8930:[3/n] Camera Compat UI: Add a camera compat contro...
Id6be4a954:Enable a camera app compat control on Large screen...
I083aa6718:[2/n] Camera Compat UI: Add interfaces for client-...
Bug: 206602997
Change-Id: I9ad876043fd61f708a8f468fffd1ef371bfa0866
This reverts commit f6a946bbcd.
Reason for revert: will deliver a better fix for that, ag/16580245.
Change-Id: I9c401b4cbded8753fc89df25a2c4f88a2fe72087
Previously we allowed bindServiceAsUser in the following situations:
* caller has INTERACT_ACROSS_USERS_FULL
* caller has INTERACT_ACROSS_USERS and is in same profile group
* caller has INTERACT_ACROSS_PROFILES and is in same profile group and is the same app as the service
We now additionally allow:
* caller has INTERACT_ACROSS_USERS and is the same app as the service
(regardless of whether it is in the same profile group)
Bug: 209989958
Test: tested locally that granting the permission allows access to bindServiceAsUser
Test: atest UserControllerTest
Change-Id: I47d6f86fd159aa993971366ee9d7d334644d391e
