Implement performBackup() with flags argument:
1. If FLAG_INCREMENTAL is passed and transport has no data for this
package or supports only non-incremental backups, request a non-incremental retry.
2. If FLAG_NON_INCREMENTAL is passed, but transport has data, discard
that data and continue.
Bug: 72212840
Test: GTS test in the same topic
Change-Id: I4c4a1dbfa1a807e4d4c523f42bb6a404a39731e9
Extend the existing hidden_api_blacklist_exemptions config to support a
list of API signature prefixes to exclude from hidden API enforcement.
Push this list down to the zygote process when that process is created,
and when the list changes. This minimizes overhead, but should also ensure
that all new processes get the latest whitelist.
Test: $ adb shell settings put global hidden_api_blacklist_exemptions \
Test: Landroid/view/RemoteAnimationDefinition\\\;:Landroid/app/ActivityManager\\\$TaskDescription\\\;
Test: Manually verify logcat output from app which uses named APIs
Bug: 73337509
(cherry picked from commit 2c6f97d4c9)
Merged-In: Ib1245b69da4dac50c6968f1be62f1a74591dc433
Change-Id: I7b590f272fdcfcda5f18e216788ac34bc58beaed
This CL clears the pattern immediately once it's completed. This
ensures that a half-drawn pattern doesn't remain as an artifact on the
lock-screen while we display an error message.
This behavior is gated on pattern fading, so if that's disabled, then
we retain the previous behavior (of showing the incorrect pattern
along with the error message).
Test: Draw an incorrect pattern.
Bug: 74531517
Change-Id: I41569e3fe10f91b787ef22600beb66d44f98cd90
Ble scan logging in statsd has a few problems:
1. We want finer-grained detailed than just 'unoptimized'. What defines
unoptimized should be done at the config level, not be hard-coded.
2. The current mechanism is actually incorrect. When reset is called,
each ble scan is only told *once* that it stopped, but if the nesting
level is higher than that, statsd will think it is still nonetheless
running.
Test: cts-tradefed run cts-dev -m CtsStatsdHostTestCases -t android.cts.statsd.atom.UidAtomTests#testBleUnoptimizedScan
Test: cts-tradefed run cts-dev -m CtsStatsdHostTestCases -t android.cts.statsd.atom.UidAtomTests#testBleScan
Fixes: 71607284
Fixes: 69478888
Change-Id: Ied44f79aa569daab2acc85e90627a9736d0689a3
This CL changes FingerprintDialog into the more generic
BiometricDialog, which OEMs will be able to extend as necessary to
provide support for alternate biometric modalities.
Bug: 74831038
Test: m -j50 FingerprintDialog (from the associated CL on this topic)
The app works and authenticates successfully.
Test: make update-api -j56
Change-Id: Ic398ef0a0b448be68dbe3330b30779f93f567243
Record USB data link state in addition to plug & charging state, since
modern USB controller can keep USB data link connected with minimum
current. Device is not acutally charging at those times.
Test: manual
Fixes: 76209292
Change-Id: I0710d547399a631d594488a524682ccc32a25ce6
Several statsd atoms are not logged correctly from batterystats, due to
possible nesting issues (batterystats only reports a single stop at the
end, whereas statsd expects each stop, resulting in statsd thinking that
the event is still continuing). This cl fixes those.
Bug: 69478888
Test: current ones still pass
Change-Id: I3ae8d7cc3d2eec7d4ab2721c83d208384adbf690
This CL adds the basics to set black, dark gray or light gray list
enforcement, rather than just black as before. It's not possible to
actually set the policy per-package yet.
PackageDexOptimizer still uses a single bit, for API checks on/off, rather
than the new enum. It assumes blacklist enforcement internally. This can
be improved in a follow up CL.
(cherry-picked from commit e52130ae4c)
Test: m
Test: Boot device
BUG: 73337509
Change-Id: Ieb4bd9cc439c6a5b8fb9424d8902d8b46aec309f
Merged-In: Idd73c9938592c5c4d67cfb9efefdffed0dd5f262
This change adds a way to make ActivityManager#isHighEndGfx() return
false at runtime by inspecting the value of ro.config.avoid_gfx_accel.
This is useful for running Android on Chrome OS devices, since a single
image can be made to run in both physical hardware and an emulator.
Bug: 65602168
Test: Added `ro.config.avoid_gfx_accel`, isHighEndGfx() returned false.
Change-Id: I1599ad9b385f9ef43f923886e6d5358ae07632e0
Debuggable apps enable mini-debug-info after fork, however, this does not
work with apps with wrap.sh script since they follow different code path.
Enable mini-debug-info generation for those as well.
Bug: 74070426
Test: check that app with wrap.sh generates debug info for JIT now
(cherry picked from commit 28a89370f0)
Merged-In: I489ac3c82bcced8fc0448ed5666f67009cbb043d
Change-Id: I22db2e889e918eb4b64c722289f7c046bb499d1d
The current model for setting up a functionfs
function is:
UsbDeviceManager#setCurrentFunctions() ->
intent is sent to MtpReceiver to write the descriptors ->
init/hal waits for descriptors to write, then pulls up gadget ->
Gadget is configured, a USB_STATE intent starts MtpServer
The main downside of this is a lack of reliability because
the Mtp process could be killed at any point. Normally, a
gadget is unbound if its control endpoint is closed. no_disconnect
works around this, but is still a little janky. In addition, the
extra intent delays the startup of the gadget.
With the new model, UsbDeviceManager writes the descriptors
on initialization. Since it is a system service, it won't be killed.
UsbDeviceManager#setCurrentFunctions() ->
init/hal pulls up gadget ->
Gadget is configured, a USB_STATE intent starts MtpServer
MtpServer calls UsbManager#getControlFd to get a dup of the control
endpoint.
Also modify permissions so system server can access mtp files.
Bug: 72877174
Test: Change usb configurations to ptp/mtp
Change-Id: Id17d2b5930f4e1f37ec1b4f00add9d594174ad49
The new notifications now have different font weights
and colors to make the shade more readable.
Fixes: 69168591
Test: runtest systemui
Change-Id: I0b635724fa122d292841e56efa84aa57fa364300
updateBluetoothStateLocked does not check for null values, causing
NPE. This patch reverts part of the change in 3445570. Instead, an
update method is added to LongSamplingCounter, which accepts
cumulative values.
Fixes: 75963520
Test: LongSamplingCounterTest
Change-Id: I89eba8e20f8f055c60f4ff250653345a22536189
If a notification is marked with category message, then
it is sufficient enough to be deemed a "message" notification.
However, to be considered an important message, we still
check if the message is from the default messaging app and has
category = message.
Change-Id: I4f2b502634b805919bdf8b82e3bdf475c0992bdd
Fixes:76019310
Test: AttentionManagementVerifierActivity
Test: atest services/tests/uiservicestests/src/com/android/server/notification/NotificationComparatorTest.java
Bug: 73299306
Fixes: 73299306
Test: Call LockPatternUtils.clearLock() with wrong password,
make sure device still unlocks after reboot
Change-Id: I640fc62cbe0c0c57e980455d4f499df02dee0832
This imports the keys directly into the keystore of LockSettingsService,
allowing them to be accessed via the RecoveryController getKey method.
This is better as it does not expose raw key material to any app.
Bug: 74345822
Test: runtest frameworks-services -p \
com.android.server.locksettings.recoverablekeystore
Change-Id: I4991b0cff1d2fa2e5bd0b53a71c096499e93e98b
Imagine the scenario where three IMEs are installed, and only the last
two are enabled:
IME A:
* a pre-installed IME
* has a subtype [mode="keyboard" && isAuxiliary=false]
* disabled by user (hence not included in ENABLED_INPUT_METHODS)
IME B:
* a pre-installed IME
* has a subtype [isAuxiliary=true]
* currently enabled (included in ENABLED_INPUT_METHODS)
IME X:
* not a pre-installed IME
* has a subtype [mode="keyboard" && isAuxiliary=false]
* currently enabled (included in ENABLED_INPUT_METHODS)
In this scenario, when the IME X is uninstalled, the current
implementation of InputMethodManagerService (IMMS) does not try to
hard reset enabled IMEs because there is still one enabled IME, even
though it is an auxiliary IME.
This can, however, be problematic because an auxiliary IME is just a
supplemental IME and user may not be able to easily access the UI to
re-enable non-auxiliary IME such as IME A. For instance, on the lock
screen there is no way to manually re-enable the IME A.
With this CL, every time the available IME list is updated, IMMS
ensures that at least one non-auxiliary IME is enabled. If no
non-auxiliary IME is enabled, then IMMS tries to pick up one from the
pre-installed IME by using the same logic when choosing the default
enabled IMEs for the hard-reset scenario.
Bug: 71509065
Fix: 71509065
Test: atest FrameworksCoreTests:com.android.internal.inputmethod.InputMethodUtilsTest
Test: Manually verified in the above scenario
Change-Id: I88c69f548526b35f0e4ba37489365b2433373b04
This CL also adds an alias param to the RecoverySession#start method.
Bug: 76033708
Test: runtest frameworks-services -p \
com.android.server.locksettings.recoverablekeystore
Change-Id: I870f4f89bd6e319e1687a981aa04af0d23f3c922
The service is meant to replace the PendingIntent based API. Once all
users of the PendingIntent based API switched the PendingIntent based API
will be removed.
To have as little as possible impact on the whole SoundTrigger framework
the RemoteSoundTriggerDetectionService class implements the same
interface as the PendingIntent based class. Hence the exising code has
very little change. Further once the old code can be removed the amount
of changed (and added) code is limited.
The RemoteSoundTriggerDetectionService -> SoundTriggerDetectionService
is a vanilla as possible service implementation. The special behaviors
are:
- The system holds a wakelock while service operations are in progress
and the service is bound as foreground. Hence the service can e.g.
listen to the microphone.
- Service operations have a certain amount of time they are allowed to
run. Once every operation is either finished or the the operation
exceeded the allotted time, the system calls onStopOperation for each
still pending operation. This is a similar model as for the commonly
used JobService.
Please note that if the time allowed for an operation is 15s and
op1 was run as 0si, and op1 was run at 5s, the service is allowed to run
until 20s. Hence _both_ onStopOperations will happen at 20s. This is
done for ease of implementation but should not give the service more
power than calling onStopOperation exactly 15s after each operation is
triggered.
- If an operation is done before the allotted time is reached, the
service can declare the operation as finished manually by calling
onOperationFinished. This is a call back into the system, hence a
'client' binder is sent to the service. If the operation is finished
by calling this method onStopOperation will not be called.
- As the service instance might be killed and restored between
operations we add a opaque bundle 'params' to each operations. The users
of the API can use this to send data from the start command to the
operations. It can also just be set to null. The params are not meant to
store changing state in between operations. Such state needs to be
persisted using the regular methods (e.g. write it to disk)
- A service can be used for multiple recognition sessions. Each
recognition is uniquelity defined by its sound model UUID. Hence each
operation gets at least tree arguments: Operation ID, sound mode UUID, params
- As a small optimization the params are cached inside of the service
instance.
The time allowed for each operation is in a @SystemAPI global setting,
so the service can make sure it finishes the operations before they are
stopped. It might take some time to deliver the operations via the
binder, hence it is not recommended to try to use every last ms of
allotted time.
Test: atest SoundTriggerDetectionServiceTest (added in separate CL)
atest android.provider.SettingsBackupTest
Change-Id: I47f813b7a5138a6f24732197813a605d29f85a93
Fixes: 73829108
