Test: I solemnly swear I tested this conflict resolution.
Merged-In: Idd73c9938592c5c4d67cfb9efefdffed0dd5f262
Change-Id: I3d1aeb30b755ca05f32dcd3c46335d1611e0bb50
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: Ic0d5b8fa631c2bd583b6fc52b2ee3708c8113f59
Merged-In: Idd73c9938592c5c4d67cfb9efefdffed0dd5f262
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
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
This change takes care of the flow from WindowManagerService to
PinnedStackController, all the way to PipTouchHandler. It also
introduces a WindowManager hook that allows Launcher to pass in
shelf visibility and height. A separate change is made to send
signals from Launcher to SysUI. (ag/3724896)
Bug: 73961893
Change-Id: I2ff54e78bc2dc35c806b902464048b051a4d6394
Test: atest CtsActivityManagerDeviceTestCases:ActivityManagerPinnedStackTests
Atom definitions for MobileConnectionStateChanged and
MobileRadioTechnologyChanged
Also cleans up batterystats.
Bug: b/72320589
Test: verified logs appear in adb logcat -b stats
Change-Id: I9feb258cf6dd4a8c8bf1cffc9566b5d0a851a9fa
Both STATSD and batterystats need to read uid cpu info. However, uid cpu
stats needs to be cleared from time to time to conserve memory. To
resolve this race condition, only batterystats will remove uid stats,
both from readers and from the kernel, also with a delay, so that STATSD
can access such info before it is removed.
Refactored readers to reuse some common code. Also removed string reader
from KernelUidCpuFreqTimeReader completely since binary reader has been
working fine for a while.
Change-Id: I209bdcec642e1a29a44b566ce98ebbfaaacb4e6a
Fixes: 72172569
Test: BatteryStatsCpuTimesTest
Test: KernelUidCpuActiveTimeReaderTest
Test: KernelUidCpuClusterTimeReaderTest
Test: KernelUidCpuFreqTimeReaderTest
It tracks binder calls into the system server and reports
statistics about CPU time spent per call on multiple dimensions,
e.g. uid or call description.
Usage: dumpsys binder_calls_stats
Overhead: ~0.5% per binder call (if enabled)
Test: manual
Bug: 75318418
Change-Id: I13b854f67f8fd1c9f985b8e45f74dcba2e73b9cb
When the user triggers lockdown the device is put into a secure state,
beyond disabling less secure unlock modalities this should also disable
notifications so that data is not leaked despite the device being
strongly locked.
Fixes: 74564088
Test: Entered lockdown, verified notifications are no longer displayed
on the lockscreen
Change-Id: I4188c36b11a1b0cd496b8032bd246f0413c911c5
In the kernel code, there is a constant FUSE_MAX_PAGES_PER_REQ which
limits the size of requests to 128KB.
Bug: 74725300
Test: atest android.os.storage.cts.StorageManagerTest
Change-Id: I6776a409ea68da946bb58e1a933f51c68cb1a99a
