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
Change-Id: I489ac3c82bcced8fc0448ed5666f67009cbb043d
This reverts commit 1bc41d4c7d.
Reason for revert: Re-submitting after fixing tests.
Test: See original change
Change-Id: Idd73c9938592c5c4d67cfb9efefdffed0dd5f262
Useful for clients such as BatteryStats which currently rely
on NetworkStatsFactory. Data at that stage is incomplete as
it does not account for tethering, VT data and corresponding
464xlat corrections.
Test: runtest frameworks-net, CTS tests pass.
Change-Id: I763b77f601c827fd2963204694fb5b45425cc791
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
