StylusListener detects first usage of a stylus, and
updates the STYLUS_EVER_USED Settings flag.
Bug: 251206662
DD: go/stylus-first-usage-options
Test: StylusListenerTest
Change-Id: I165481d1166e31b5b8560da5c695003d105068ef
WearableSensing framework APIs are intended to be used to interact and
manage the WearableSensingService. The WearableSensingService provides
an isolated service environment for an application to provide a remote
data stream to and run sensing workloads on the data stream. Clients
that want to use this API must hold the permission
MANAGE_WEARABLE_SENSING_SERVICE. The permission protection level is signature|privledged.
API overview: go/wearable-sensing-api
Design doc: go/trusted-glasses
A follow up CL will implement the integration between
WearableSensingService and AmbientContextManager. A subsequent follow up
will also add unit and cts testing.
Bug: 244181656, 249135378
Test: Builds.
Ignore-AOSP-First: to prevent new feature leak.
CTS-Coverage-Bug: 259453662
Change-Id: I0c5e3c5aa01dda9d3289733abd22abfcccc15f96
As part of moving DeviceConfig.java to packages/modules/ConfigInfrastructure.
Need to move activity thread dependency to setting.config as the new
module will not have access to hidden apis (ActivityThread).
Test: m
Bug: 258220607
Change-Id: Ib7b20caaec128d64908349918ec7bce9a53cc2e6
Also add a new API in JobScheduler to check if apps hold the permission.
Bug: 255821578
Test: manually
Change-Id: I4beeb7eb40b5e19fc95784b4a54031467e9bc780
Dreams and docking often refers to "user zero" or "system user".
But more generally, the special user for dreams or switching-to-on-docking
need not be user 0, and in fact won't be in certain modes. So this needs updating.
Test: the files mentioned in the topic
Bug: 257333623
Change-Id: Ic671c91c32e9bf24695b067ff97cf9fa65534b1e
Merged-In: Ic671c91c32e9bf24695b067ff97cf9fa65534b1e
Dreams and docking often refers to "user zero" or "system user".
But more generally, the special user for dreams or switching-to-on-docking
need not be user 0, and in fact won't be in certain modes. So this needs updating.
Test: the files mentioned in the topic
Bug: 257333623
Change-Id: Ic671c91c32e9bf24695b067ff97cf9fa65534b1e
Creates new setting on SFPS to require screen on before unlocking a
device. Also sets up toggles for this setting at the end of fingerprint
enrollment and on the fingerprint settings page, and adds test to verify
expected behavior.
Test: atest KeyguardUpdateMonitorTest#testStartsListeningForSfps_whenKeyguardIsVisible_ifRequireScreenOnToAuthEnabled
Fixes: 249169615
Fixes: 245343077
Fixes: 248530806
Change-Id: Ibc55dfa6667ec281add11a2665fceb073974ccb0
Merged-In: I4aa716fb5b288ef6f92a5c403a1fd5e586e889d0
Creates new setting on SFPS to require screen on before unlocking a
device. Also sets up toggles for this setting at the end of fingerprint
enrollment and on the fingerprint settings page, and adds test to verify
expected behavior.
Test: atest KeyguardUpdateMonitorTest#testStartsListeningForSfps_whenKeyguardIsVisible_ifRequireScreenOnToAuthEnabled
Fixes: 249169615
Fixes: 245343077
Fixes: 248530806
Change-Id: Ibc55dfa6667ec281add11a2665fceb073974ccb0
DevicePolicyResourcesManager.getString() was added in T and called in
many places inside system server. However, it uses
DeviceConfig.getBoolean to determine if a feature is enabled or not. In
the places where it is called from inside system server,
`clearCallingIdentity` was not always called, which can result in
DeviceConfig.getBoolean throwing SecurityException due to mismatched
AttributionSource (calling uid is the caller from the binder client,
while the context is "android" which should have calling uid 0). Context
is "android" because it is inside the system server where the
DevicePolicyManager instance is created. This bug might lead to
unexpected behavior such as packages failing to be uninstalled by admin.
The easiest fix is to place a bypass in SettingsProvider and manually clear
the calling uid there. This fix also allows for the cleanest backporting as
it can be cherry-picked into T without touching all the places where
DevicePolicyResourcesManager.getString() is called in the system server.
BUG: 252663068
Test: manual
Merged-In: I37a6ceb29575593018b93093562c85d49770a43c
Change-Id: I37a6ceb29575593018b93093562c85d49770a43c
(cherry picked from commit b127850fda)
DevicePolicyResourcesManager.getString() was added in T and called in
many places inside system server. However, it uses
DeviceConfig.getBoolean to determine if a feature is enabled or not. In
the places where it is called from inside system server,
`clearCallingIdentity` was not always called, which can result in
DeviceConfig.getBoolean throwing SecurityException due to mismatched
AttributionSource (calling uid is the caller from the binder client,
while the context is "android" which should have calling uid 0). Context
is "android" because it is inside the system server where the
DevicePolicyManager instance is created. This bug might lead to
unexpected behavior such as packages failing to be uninstalled by admin.
The easiest fix is to place a bypass in SettingsProvider and manually clear
the calling uid there. This fix also allows for the cleanest backporting as
it can be cherry-picked into T without touching all the places where
DevicePolicyResourcesManager.getString() is called in the system server.
BUG: 252663068
Test: manual
Change-Id: I37a6ceb29575593018b93093562c85d49770a43c
These will be used by the ANGLE Developer Options GUI to process the
deferlist
Test: logcat + various flash/wipe + system-driver scenarios
Bug: 224558229
Change-Id: I47f940612f8be0c83f0be04c2cc1af7908e37382
Merged-In: I47f940612f8be0c83f0be04c2cc1af7908e37382
ENABLED_INPUT_METHODS and DISABLED_SYSTEM_INPUT_METHODS reveals
a list of input methods apps, which violates the rules of package
visibility. This cl restrict the setting key to be readable for
apps targeting in T and below.
Bug: 253164661
Test: atest AccessibilitySoftKeyboardTest
Test: atest CarRotaryImeTest
Change-Id: I48aa7b05cd0dbde70fc6d53eee455959264a6867
New AppOp to be used for near-field file-based audio transfer
(ie. TV Remote Service) to allow audio recording
regardless of sensor privacy state, because it is considered
an intentional user interaction: hold-to-talk
And new Global Settings and SensorPrivacyManager APIs for the
opt-out toggle - as agreed with PWG.
Bug: 235618473
Test: manual
Change-Id: I95cdf8fa362b937609bdf834a82b05ec8375ac26
