InspectionHelper has been renamed to InspectionCompanion for clarity
about its lifecycle. The APIs needed to be accessed from the context of
an inspection agent injected by the profiler have been made public.
With a tightend focus on platfrom views and XML resource IDs, the
@InspectableProperty annotation now has affordances for specifying an
attribute resource ID and for defining @IntDef flag and enum mappings.
@InspectableChildren has been removed, as this will be special cased in
the injected inspector. Additionally, support for attribute ID is now
provided in all PropertyMapper methods.
Additionally, PropertyMapper and PropertyReader now have support for
Gravity ints, @ColorInt, @ColorLong, and Color objects.
Test: mmma frameworks/base
Bug: 120224687
Change-Id: If455e2d1d9693eac39c33fc35f892baf75671ba4
This name is too generic, so we split it in 2 parts:
- ContentCaptureManager: the public API used by views and apps to report their
structure.
- SmartSuggestionsServiec: the system service use to consume these events and
provide autofill suggestions.
This CL also:
- Optimizes ContentCaptureManager allocation so they are not created on contexts that are not
capturing events (such as views from the system server).
- Uses a generic ContentCaptureEventsRequest (rather than a list of events) to make it easier
to be extended.
- Fixed IntelligencePerUserService so it clears the sessions when the
implementation changes.
Test: manual verification
Bug: 119776618
Bug: 117944706
Bug: 119638877
Change-Id: I069bcd23dda94afe18b2781fd3981b8b555afa56
* changes:
3/n: For passive modalities, add plumbing for "try again"
2/n: Multi-modal support for BiometricPrompt
1/n: Move BiometricDialog management to BiometricService
When "try again" is showing, authentication is canceled internally.
BiometricService caches the client's info so that authentication can
be restarted when "try again" is pressed. Because authentication
is not running when "try again" is showing, BiometricService also needs
to have a TaskStackListener so that BP can be dismissed and an error can
be sent to the client when the app loses focus.
IBiometricServiceReceiver has been split into two. One for BiometricPrompt
to receive messages from BiometricService, and another for BiometricService
to receive messages from SystemUI/<Biometric>Services.
When we get locked out, don't send the last onAuthenticationFailed
to the client, since "Authentication failed" will be shown briefly
and be replaced by "Device locked out" which is janky
Bug: 111461540
Test: Tested with requireConfirmation enabled/disabled
Test: Tested onConfigurationChange corner cases, e.g. when "try again"
or "confirm" buttons are showing, rotate the device. Buttons
persist correctly and don't appear when unexpected
Test: Tested task stack corner cases, e.g. when "try again" is showing,
press home button. BP dismisses and client receives ERROR_CANCELED
Test: BiometricPromptDemo receives all callbacks
Change-Id: I62126708ce8db8b358c666a07aa7c39607642c9d
Add the PhoneNumberRange and NumberVerificationCallback classes. Add a
method in TelephonyManager to activate the API, but it does nothing for
now.
Bug: 119675160
Test: todo
Change-Id: I3ccd62b47f02a3aa324b675fdb16c8e7a1e9feec
Copy the gps_debug.conf from the device-specific folders to
a place closer to the code that uses it.
Bug: 112879252
Bug: 120066492
Test: make
Change-Id: I937e699cb9e891c511ca7b9f4740d45e19668c54
Merged-In: I937e699cb9e891c511ca7b9f4740d45e19668c54
Exempt-From-Owner-Approval: cp from internal
(cherry picked from commit 11905c6b2c)
The BiometricDialog management was done in AuthenticationClient, but
this is not great for the following reasons
1) The dialog lifecycle should not be 1:1 tied to the client monitor,
since this restricts flexibility
2) Devices with multiple biometrics implemented on BiometricDialog
will require extra work. Moving the dialog management up one layer
should solve this limitation
BiometricService now sends both its own receiver and the client's receiver
to the appropriate <Biometric>Service. When the client is actually started
by the <Biometric>Service, it will forward the client's (BiometricPrompt's)
receiver to BiometricService. Lifecycle management is currently still in
<Biometric>Service since the platform still uses <Biometric>Service
directly. AuthenticationClient for BP is now started with the wrapper
receiver, which allows BiometricService to handle messages before deciding
if it should forward the message to the client.
Moving lifecycle management to BiometricService is currently not a great
idea since framework doesn't always go through BiometricService.
Also merged IBiometricPromptReceiver with IBiometricServiceReceiver
Bug: 111461540
Test: Negative button works (error received by demo app)
Test: Cancelling via back or tapping gray area works (error received
by demo app), and hardware is no longer authenticating
Test: Dismissing BP via negative button or gray area returns only a single
error and is not followed by ERROR_CANCELED (as expected)
Test: Error messages are delayed when BP is showing, not delayed
when BP is not showing (pre-auth check errors e.g. no hardware)
Test: Lockout works
Test: Lockout counter resets upon successful auth
Test: Keys are unlocked properly for both implicit and explicit modes
TODO: Figure out multi-modal BiometricService / <Biometric>Service
synchronization. Likely we keep the bundle in BiometricService
and send random numbers (identifier) to <Biometric>Service. When
each <Biometric>Service is ready, it should return the number. Once
BiometricService receives all identifiers, it can then notify
all <Biometric>Service to start authenticating.
Change-Id: I2b6fa57ed3c3cbccc7b0be30279f80fa46a8e917
Copy the gps_debug.conf from the device-specific folders to
a place closer to the code that uses it.
Bug: 112879252
Bug: 120066492
Test: make
Change-Id: I937e699cb9e891c511ca7b9f4740d45e19668c54
To better test CBRS, we want IRadio 1.3 to be Android P plus CBRS
HAL interfaces, while 1.4 will be 1.3 plus all other Android Q
interfaces. So we are moving everything currently defined in
android.hardware.radio.V1_3 to android.hardware.radio.V1_4.
Bug: 117805040
Test: build and telephony unittest
Change-Id: I2c9bcf77ebfbda144bf184b43e196c1dd1ca466b
Merged-In: I2c9bcf77ebfbda144bf184b43e196c1dd1ca466b
The ext target needs to be switched from core_current to depending on
core.platform.api.stubs (the default when no sdk_version is specified
and no_frameworks_libs = true) as it statically includes
libphonenumber-platform which itself needs to depend on
core.platform.api.stubs as it needs access to the
dalvik.annotation.compat.UnsupportedAppUsage annotation.
Without this change modifying the libphonenumber-platform target to
depend on core.platform.api.stubs causes a build failure.
Tested by changing libphonenumber-platform target to depend on
core.platform.api.stubs and running make checkbuild.
Bug: 117818301
Test: see above
Change-Id: I2b9154d22b67aafb57493b41b527818c37212c34
Augmented Autofill is a mechanism that will let a system-provided service
provide autofill suggestions when the stardand autofill can't.
Because the Augmented Autofill service is a system app, it has less restrictions
than the standard service; in particular, this service will be responsible for
drawing the autofill UI, although the framework will provide a mechanism to host
the window. Right now, it's creating a TYPE_APPLICATION_OVERLAY window in the
service process roughly below the focused view, but in the long-term it will
use the IME suggestion window to display it.
This CL provides the initial APIs and end-to-end workflow for the simplest
scenario, but it's still full of TODO's.
Test: atest CtsAutoFillServiceTestCases # to make sure it doesn't break it
Test: atest FrameworksCoreTests:SettingsBackupTest
Test: mmm -j150 packages/experimental/FillService &&\
adb install -r ${OUT}/data/app/FillService/FillService.apk &&\
adb shell settings put secure intel_service foo.bar.fill/.AiaiService &&\
adb shell settings put global autofill_smart_suggestion_emulation_flags 2 &&\
adb shell pm grant foo.bar.fill android.permission.SYSTEM_ALERT_WINDOW
Bug: 119638877
Change-Id: I8d59b4eab3e530cd89b81456681a72fdab532756
To better test CBRS, we want IRadio 1.3 to be Android P plus CBRS
HAL interfaces, while 1.4 will be 1.3 plus all other Android Q
interfaces. So we are moving everything currently defined in
android.hardware.radio.V1_3 to android.hardware.radio.V1_4.
Bug: 117805040
Test: build and telephony unittest
Change-Id: I2c9bcf77ebfbda144bf184b43e196c1dd1ca466b
Adding API to install a system update from a file on the device.
Test: manual in TestDPC, CTS tests for negative cases: atest com.android.cts.devicepolicy.DeviceOwnerTest#testInstallUpdate
Fixes: 116511569
Change-Id: I34b5c6344301a9d2d64c98dedc4ed5e4a75c57d1
Test: Manually on Thermal HAL 2.0 device
Test: Manually on Thermal HAL 1.1 device
Test: Manually on no Thermal HAL emulator
Test: atest $ANDROID_BUILD_TOP/frameworks/base/services/tests/servicestests/src/com/android/server/power/ThermalManagerServiceTest.java
Bug: 111086696
Bug: 119413961
Change-Id: I6723406123d12339e82e9e87eec14b7f9a301897
This change fixes the RcsManager setup and adds an empty RcsThread class. Please see go/rcs-in-telephony-doc for details.
Test: Builds fine
Bug: 109759350
Merged-in: Ie3fe476ab11d515ffab6dcc6ccf5ec801a4c9057
Change-Id: Ie3fe476ab11d515ffab6dcc6ccf5ec801a4c9057
Add asynchronous calls to request CellInfo updates.
-Add a request for CellInfo
-Add a request for CellInfo that allows system apps
such as the LocationProvider to bill the work to
the app that initiated the location fix.
-Update the behavioral language for getAllCellInfo
to indicate that depending on the API level of the
caller, this API will only provide cached info, which
means that apps can always request an update without
possibly triggering a call to the modem. This also
means that the binder will not block due to modem
delay.
Bug: 37100068
Bug: 63737292
Bug: 26569588
Test: manual (via SL4A)
Change-Id: I25cbc3cecd5d396fc3baa21457c05cd6e273c9c3
