* changes:
Move biometric setting observer from KeyguardUpdateMonitor to BiometricService
Change BiometricManager#hasEnrolledBiometrics to canAuthenticate
This is needed by system apps other than Settings, such as
PackageInstaller/PermissionController
Bug: 113128828
Test: CTS
Change-Id: I97cc9f90bb0978ce50ba0c10fcdd1b984028577c
Added two new APIs for getting network registration states
from domain and transport type. Deprecated the old APIs.
Test: Manual
Bug: 73659459
Change-Id: I3143df320f2942213aa0f10fe3cca9851bd82bb8
BiometricPrompt#authenticate and BiometricManager#canAuthenticate now
use the same logic to determine if the prompt can successfully be shown.
Before Android P, apps used FingerprintManager isHwAvail && hasEnrolled
before asking users to enable biometrics for their app. With
BiometricPrompt, which abstracts away individual biometric modalities,
developers need a way to determine if they should ask users to enable
biometrics for their app. Having separate checks is a nightmare due
to the untestable combinations of multi-biometric devices. This API change
makes it much more scalable since the logic will be done in the platform.
Fixes: 116823693
Test: manual test, returns status correctly
Change-Id: Ie0ecd139c9a39100b6dbc9bd85462400cb465f08
This adds a new framework user restriction that can be used by the DPC
to block installs from unknown sources on all profiles of a device.
Test: Manual test, disallowing installs in TestDPC disables installing
unknown sources apps.
Bug: 111335021
Change-Id: Ib9fb672c5e5dea2ac63bf8cbd1b04484b12b4056
This reverts commit ff88b14e62.
Reason for revert: API Council push back
Bug: 113696451
Bug: 116798156
Change-Id: I328d981b96d44e37c58625b48334891baf9a8487
These are either already exposed on other specialized collection variants or are exposed as public API on the androidx versions, or both.
With these APIs exposed, all of the unsupported app usage can be done through public API. As a result, all unsupported app usage is now locked to apps targeting API 28 or earlier.
Bug: 116877302
Test: none, no implementation change
Change-Id: I548d71319bffb0a6b529e380ea936df674dbf515
This CL adds a new privileged permission called POWER_SAVER that
will allow whitelisted packages to toggle battery saver on the
device. This can be done via PowerManager, where the API for
setting battery saver has been updated to accept calls from apps
with either DEVICE_POWER or the POWER_SAVER permission.
Additionally, we whitelist Turbo for the permission.
Test: Framework builds, Turbo can toggle EBS
Bug: 115524274
Change-Id: I49d9747b2d42f792a2f3ba90a15aa23c47e489b3
An application can declare that it must be installed with at least
one split using the manifest attribute "android:isSplitRequired".
Setting the attribute to 'true' [default is 'false'], the application
can't be installed with a base-only. It must be accompanied by at
least one split [either feature or config].
Change-Id: I42804af34a4209ba5d6726d681ca705ca2c21a39
Fixes: 111391719
Test: atest CtsAppSecurityHostTestCases:SplitTests
Bug: 102591313
Test: Compared settings in light & dark UI modes with
force_dark set to true. Observed that force_dark fixes
were not present when UI mode was set to dark, indicating
force_dark was appropriately globally-disabled
Change-Id: I5882829bb5871829fc8fc9911682f52a6ba5f445
This reverts commit 8a8832fd81.
Reason: most of the users in this new API are not in pi-dev so this change does
not make sense in this branch.
Change-Id: I73b7834916b4f45017010c45e96ea2538e952443
This reverts commit 8a8832fd81.
Reason for revert: Causing failures on git_pi-dev-plus-aosp for docs and aosp_sailfish.
Change-Id: I1801188e66420a67244b3223e26334c4650d56be
Merged-In: Ic108c484905f80783982a22e8152609257d684b5
InputMethodService#getInputMethodWindowRecommendedHeight() was added
with an assumption that some IMEs may want to call this API in
InputMethodService#onCreate() to adjust its IME window height to be
the same as the previous IME's window height [1], but in reality for
IME developers this API is quite difficult to use because relying on
this API means user-visible behavior is no longer deterministic.
Basically "Recommended" is too vague to rely on.
Let's deprecate this API before we end up having to define what is the
"recommended" height for more complicated scenarios such as
multi-displays and multi-profiles.
With this CL, IMS##getInputMethodWindowRecommendedHeight() always
returns 0. Basically doing this would not likely to cause
compatibility issues because the possibility of returning 0 has been
clearly mentioned in the API document. In practice this must have
returned 0 when the previous IME did not show the software keyboard
(e.g. AOSP keyboard with a hardware keyboard). Therefore IMEs that
have correctly used this API should be able to fall back to a safe
default behavior even if this API returns 0.
[1]: I0e920ee79c526c3aea6872b063cf294e2ab081c8
658c7b896a
Fix: 116502957
Test: atest CtsInputMethodTestCases CtsInputMethodServiceHostTestCases
Change-Id: Ia2cde031a0e67d45a3631e54226f9b5a0698dd61
