We've finished all the underlying work to support adoptable storage
on FBE devices, so remove the code that was disabling it by default.
Introduce feature flag to make it easier to detect devices that
support adoptable storage.
Test: cts-tradefed run commandAndExit cts-dev -m CtsAppSecurityHostTestCases -t android.appsecurity.cts.AdoptableHostTest
Bug: 29923055, 25861755, 33252673, 37289651
Change-Id: I3630d690c9e66c7e41e316a4263ea2eb1e752ad3
These changes are slightly different than the ones for Wifi etc.
We need to keep track of the list of WorkChains attributed to a given
UID in order to log stop events for each of them if the BT process
crashes (or goes away) and we receive a call to noteResetBluetooth..[].
Test: BatteryStatsTests
Bug: 62390666
Change-Id: I4aaa2260cdc509ca08c4fa4838df77cda870ef75
The changes are straightforward, the only change outside of BatteryStats
is to use the new WorkSource.isEmpty API to account for WorkChains in a
given WorkSource.
Bug: 62390666
Test: BatteryStatsBackgroundStatsTest, BatteryStatsNoteTest, WifiLockManagerTest
Change-Id: I1dff43b6f2a09877e3af4442bfe8a8fd80b1ba74
In current implementations the WiFi MC statistcs are calculating by
aggregating the per uid statistics accross all UIDs. This does not
result in the correct values in case of time overlapping acquisitions of
MC wakelocks by same or different UIDs
This commit creates a separate Timer instance that tracks the actual
time spent with MC Enabled.
Bug: 69854369
Test: Manual Test
Change-Id: I78533f48300bc9faccc374d684698dae647bde5d
Signed-off-by: Ahmed ElArabawy <arabawy@google.com>
.. those passed down via the AlarmManager.set() variant that takes
a WorkSource. This required a minor re-arrangement of code in
the ActivityManager. We now treat WorkSources as opaque in the
AlarmManager and simply push them down to the AM (and eventually
to BatteryStats) where they are picked apart.
Test: BatteryStatsNoteTest, AlarmManagerTest
Bug: 62390666
Change-Id: I118f1a1d16aafa41b4f401f1a6a3ba4d2d5eca8f
Previously did not allow stacking on small screens, which resulted in
buttons clipping at the ending edge of the dialog.
Change-Id: Iaa36cb657556197018b192c24c4043e6395c74a2
Fixes: 37507002
Test: manual
Suggested language list alignment should be as per the default locale.
Test: 1. RTL language
2. Settings>System>Languages & input>Languages>Add a language>English
3. Check the alignment
Bug: 70360392
Change-Id: I934b1061fb897ac69270a493562defba4a5a1a35
Signed-off-by: susanta.patra <susanta.patra@lge.com>
Log WorkChains associated with a given WorkSource to statsd whenever
a wakelock is acquired / released or changes.
Test: WorkSourceTest, manual.
Bug: 62390666
Change-Id: I1720ba8b1778d38067398caac7cf92c4d375f816
For now just returns raw key material. In the future we will need to
change this to use the KeyStore move api. (Once that has been
implemented.)
Test: adb shell am instrument -w -e package com.android.server.locksettings.recoverablekeystore com.android.frameworks.servicestests/android.support.test.runner.AndroidJUnitRunner
Change-Id: I8aee4da81f0f853503f570dae8d74e1d29f124cc
This is a temporary solution, while the KeyStore team works on adding a
move API to KeyStore. (At which point this will be updated to instead
return 'move tokens', allowing the user to move the key from the system's
keystore to their own, without ever seeing the raw material.)
Test: adb shell am instrument -w -e package com.android.server.locksettings.recoverablekeystore com.android.frameworks.servicestests/android.support.test.runner.AndroidJUnitRunner
Change-Id: I2241a6da15d50c26a7b384d4e5b6f78366fb9300
1) Methods to get key status.
2) Register pending intent to get notification about new recovery
snapshots.
Test: none
Bug: 66499222
Change-Id: I4d5f8c1a6581b5e08f4589e19961d93c499689e1
Together with checking isObservableEventType this will result in a11y events
not being generated for packages that are excluded form a11y-service(s)
package whitelist
Test: cts-tradefed run singleCommand cts -d --module CtsAccessibilityServiceTestCases
Change-Id: Id65607aaccc7af7d870d009d609917ff3c6d0712
BatteryStatsImpl will track this data by reading from
/proc/uid/<uid>/time_in_state whenever process state changes
and will include this data as part of batterystats dump.
Bug: 66953194
Test: atest core/tests/coretests/src/com/android/internal/os/BatteryStatsTests.java
Test: atest hostsidetests/incident/src/com/android/server/cts/BatteryStatsValidationTest.java
Test: atest core/tests/coretests/src/com/android/internal/os/BstatsCpuTimesValidationTest.java
Change-Id: Ibb3e07f518aaf7eea2a00bb95b95dc5f7e09552e
When an app is on the top of the activity stack but the screen
is not on, this doesn't really count as a top app in the normal
sense. In particular, we'd really like to apply the normal
restrictions we have on background and cached apps: no network
access, no ability to use wake locks, etc. (In other words, in
this state the app's activity is stopped, so from its perspective
it is no different than the user leaving it to go to another app.)
To do this, we change the order of the TOP_SLEEPING proc state
out from the range of foreground states down to between the
cached and background states.
Test: ActivityManagerProcessStateTest
Bug: 70808931
Change-Id: I994caba8c27553a452de75efa358be0e683d046f
1) Updates to ILockSettings.aidl
Since we can't pass arbitrary exception using IPC, Serrvice
converts them to ServiceSpecificException with an error code.
2) Added RecoverableKeyStoreManager class which is used as interface
between RecoverableKeyStoreLoader implementation and
LockSettingsService.
Test: none
Bug: 66499222
Change-Id: I03b695bc0ced1a91ea7ca5de179e121053dfe416
This allows us to generally treat heavy-weight processes in
the background as cached processes, applying all of the limitations
we want for such things -- disable wake locks, etc.
Test: run-am-test ActivityManagerProcessStateTest
Bug: 63937884
Change-Id: I7c140c8f48188f6aa9c09731e83e3db4e4405e77
This CL is a generalized version of my previous CL [1], which addresed
Bug 31056744 where InputMethodManager (IMM) fails to recover from
failure mode when IMMS#startInputOrWindowGainedFocus() failes because
the app's window is no longer eligible to be the IME target.
This CL finally addressed one TODO in that CL. InputBindResult now has
the error code, which allows us to force restart input upon the next
window-focus-in event. This should make IMM much more robust for
that kind of failure modes. For instance, Bug 70629102 is fixed as
demonstrated in a newly added CTS test case [2]. Hopefully this may
also fix Bug 31056744, which we still do not know how to reproduce.
[1]: I60adb38013b063918b074c7b947649eada77b2c8
8e9214b4bd
[2]: I4ea24c87cbbd05e4e68ad7dfafb774c8520188e2
Bug: 31056744
Fixes: 70629102
Test: Added a test case for Bug 70629102
atest CtsInputMethodTestCases
Test: Manually made sure that Bug 28281870 is still fixed:
1. Open app that has EditText.
2. Start Input.
3. Long press the task switch button to start multi-window mode.
4. Tap the EditText that is used in step 2.
5. Make sure that the IME still works as expected
Test: atest CtsViewTestCates
Change-Id: I7572d4b9d678f3669ca54d55718877b145015777
This is the first step to introduce a public API to toggle work mode.
All the callers actually have the similar bit of logic like this:
if (workModeOn) {
trySetQuietModeDisabled(..)
} else {
setQuietModeEnabled(...)
}
So, let's merge them into one API.
Test: Quick Settings -> Toggle work mode
Test: Settings -> Work profile settings -> Toggle work mode
Test: Turn off work mode -> Settings -> Turn on work mode in the suggestion
Test: Turn on work mode through tapping on work app
TODO: Allow foreground default Launcher to call the API
TODO: Allow privileged apps to call the API
TODO: Remove @hide
TODO: Write a CTS to toggle the work mode once it is public API
BUG: 70212757
Change-Id: Ibcdd43458c236eca929c5f934fea61be2e2be863
