The new DPM API allows DP/POs to set whether the keyguard needs to show a secondary lockscreen after the primary locking mechanism is dismissed. If enabled, the keyguard will check for a service handling ACTION_BIND_SECONDARY_LOCKSCREEN_SERVICE and request the secondary lockscreen content from it.
Bug: 136085151
Test: atest FrameworksServicesTests:DevicePolicyManagerTest
Test: atest KeyguardUpdateMonitorTest
Test: atest AdminSecondaryLockScreenControllerTest
Change-Id: If82921b4fc2d78c0522a20ef91b48f9a93dd8b61
Since not all Context Hub applications are location-related, the
use of the LOCATION_HARDWARE permission to control access to the Context Hub
System APIs can be misleading. Create a new permission to access it, and
adds the logic to enforce the permission.
Also clarifies usage of PendingIntent ContextHubClient.
Bug: 135951924
Test: Compile and flash
Change-Id: I5f22db7e57ef4a6c3718acb38c4f313d6a04839f
Adds an option to specify a bubble via a shortcutId. If the builder had
icon / intent previously specified, the shortcutId will clobber those
and vice versa.
Unfortunately, this means that BubbleMetadata#getIcon and #getIntent may
return null when previously they were non-null. I've deprecated these
getters and introduced new ones along with new setters so that the naming
remains consistent.
NoMan will check if that shortcut exists before applying FLAG_BUBBLE.
Update SystemUI to use BubbleMetadata builder with shortcut id for the
shortcut experiment.
Adds test to ensure the launcher apps callback is added / removed
appropriately & that notifs with shortcut bubbles are properly flagged
or unflagged.
Test: atest NotificationManagerServiceTest
Test: atest NotificationTest NotificationManagerTest (see CTS CL)
Bug: 138116133
Bug: 144352570
Change-Id: I2e8155edc7fd70d6978fc80310f071bf6510e0d2
allows the use to set the start and end automatic dark theme
activation within a day.
Fixes: 147649309
Test: atest UiModeManagerServiceTest UiModeManagerTest
Change-Id: Iaa3593d4e8863412e3703ce9f089b88dd4df1225
System features are build-time constants, so the cache is invalidated only
when the system server restarts.
Bug: 140788621
Test: A special build that puts the PropertyInvalidatedCache in
verification mode was loaded on the device. Then one iteration of MPTS was
executed. No cache inconsistencies were found and no SELinux violations
(associated with the binder cache) were found. The number of cache misses
was approximately 15% of the total binder calls. 98.5% of all binder calls
went through the cache.
Change-Id: Icd23283512ab648ed589d461d2a86e1c3807b45a
For ViewRootImpl on BLAST experiment, setting up namespace and flag to
turn on Blast adapter through P/H experiment
Bug: 147096935
Test: build, boot, adb shell device_config put
window_manager_native_boot wm_use_blast_adapter true/false
check that BLAST adapter is turned on/off as expected
Change-Id: Ie1b158721ac9b751fcf3954310259f14486d3bb8
- Fix up target SDK check
- Keep WindowInsets.CONSUMED concept to stop dispatch for
performance optimization. If the insets are handled at some point
in the hierarchy, we really don't need to dispatch it to all the
children. However, deprecate all the individual consuming methods
instead.
Bug: 118118435
Test: ViewGroupTest
Change-Id: I6b6627fb9c0a43444ee3f9dbeb978109f9138fbd
Deprecating custom toasts as discussed, the reasons are:
* We're blocking background custom toasts for security reasons
(go/toast-abuse).
* This means custom toasts are only possible if the app is in the
foreground. In the foreground the app has control over its own view
hierarchy and is capable of creating any visual elements it would
otherwise use custom toasts for.
* If we were to declare ongoing support for foreground toasts the
developer would be in a situation where they either check for
foreground status of the app before posting a custom toast or they
accept that the information they want to display may not be shown at
all. This is not great.
* There is also a desire to avoid custom toasts altogether since they
hurt UX consistency
(https://docs.google.com/presentation/d/1r5WEofZ_G3B9M65nS37uD4RqA4iV9HUmngyE6ZpBSsw/edit#slide=id.g7b69852da2_0_0).
Also added a recommendation to use Snackbars while the app is in the
foreground.
Bug: 128611929
Bug: 144754526
Test: Builds
Test: atest android.widget.cts.ToastTest
Change-Id: I4ed0bd671e308491590c28ff24087c76d0623f13
* Historically, only the device owner could prevent the user from modifying
networks that have been configured by the device owner.
* In New COPE mode, the COPE profile owner should now be able to prevent the
user from modifying networks as well as the device owner.
* This CL adds new APIs which are callable by the device owner or profile
owner of an organization-owned managed profile. These new API can be used
to toggle the global setting WIFI_DEVICE_OWNER_CONFIGS_LOCKDOWN, instead of
setting the global setting directly.
* This CL only affects networks configured by the admin, is does not prevent
the user from creating more network configurations.
Bug: 147476790
Test: manual testing with TestDPC
atest com.android.server.devicepolicy.DevicePolicyManagerTest
atest com.android.cts.devicepolicy.MixedDeviceOwnerTest#testAdminConfiguredNetworks
atest com.android.cts.devicepolicy.OrgOwnedProfileOwnerTest#testAdminConfiguredNetworks
Change-Id: Ia16e639922bb08cdacd9a3766d978ac150b693c5
In preparation for text toasts, which won't contain a
ITransientNotification object associated with them, indexing toasts
by an IBinder token provided by the app.
Bug: 144754526
Bug: 128611929
Test: atest android.widget.cts.ToastTest
Change-Id: I8ec649066154f59bc28bcb49bb6f156eadb796d8
