When an app starts becoming Direct Boot aware, it can be difficult
to track down all the places they're reading data from credential
protected storage.
When a user is locked, credential protected storage is unavailable,
and files stored in these locations appear to not exist, which can
result in subtle app bugs if they assume default behaviors or
empty states. Instead, apps should store data needed while a user
is locked under device protected storage areas.
Bug: 110413274
Test: atest cts/tests/tests/os/src/android/os/cts/StrictModeTest.java
Change-Id: Ia390318efa6fefda8f10ac684d0206e67aa1d3dc
APN id is similar to ApnSetting.ApnType. We can just use the apn
type. No need to use APN id anymore.
Test: Telephony sanity tests + unit tests
Bug: 77511388
Change-Id: If41845604ea14f36272262da110d682eea0d5451
Increase alpha from 15 to 30% for the track and use Google Material
Grey 200 for the thumb. Fix the geometry so that the track and thumb
don't extend off the edge of the screen.
Bug: 80258942
Change-Id: I43e603e5fffb8a05f486af35194c801060dd0b51
(cherry picked from commit 97b00cbc039a090659aed75e47a172a70222b02f)
- Keep track of foreground services.
- Keep track of associations between processes.
The big part of this is the second, tracking associations.
We have have procstats keeping continual track of associations
between processes, much like the "am track-associations"
command. Currently the data kept on them is very minimal
(just the count and total duration, not separated by other
states) due to the potential number of them that there can be,
but we can look in to trying to maintain more data going
forward if it is feasible.
The way this is incorporated into the activity manager makes
it a little different than "am track-associations," with
potentially some new interesting data available. These
associations are tied with the connection objects in the
activity manager, so they only count while the target
process is actually running (so their duration should match
with the lifecycle of the target). They are tied to the
target package, since that is what we know all of the
information we need for rooting data in procstats (package
name, uid, and version code of that package); only the process
name and uid are available for the source of the association
Since these are tied to the connection components, it is
possible that we could even maintain data on the duration per
proc state that is flowing from that association in to the
target process. That would be very useful, but would add
a fair amount more overhead in data being tracked.
English output of the new association data looks like:
* com.android.providers.downloads / u0a17 / v28:
* Prc android.process.media / u0a17 / v28:
TOTAL: 0.45%
Imp Bg: 0.26%
Service: 0.18%
Receiver: 0.01%
(Last Act): 0.78%
(Cached): 37% (5.2MB-5.8MB-8.2MB/3.9MB-4.4MB-6.0MB/3.9MB-7.0MB-50MB over 18)
* Svc com.android.providers.downloads.DownloadIdleService:
Process: android.process.media
Running count 3 / time 0.01%
Bound count 3 / time 0.01%
Executing count 6 / time 0.00%
* Svc com.android.providers.downloads.DownloadJobService:
Process: android.process.media
Running count 6 / time 0.21%
Bound count 6 / time 0.21%
Executing count 12 / time 0.00%
* Asc com.android.providers.downloads.DownloadIdleService:
Process: android.process.media
<- system / 1000:
Count 3 / time 0.01%
* Asc com.android.providers.downloads.DownloadStorageProvider:
Process: android.process.media
<- com.android.documentsui / u0a10:
Count 1 / time 0.00%
* Asc com.android.providers.downloads.DownloadProvider:
Process: android.process.media
<- com.android.vending / u0a11:
Count 39 / time 2.6%
<- system / 1000:
Count 3 / time 0.00%
<- com.google.android.gms / u0a36:
Count 8 / time 0.01%
* Asc com.android.providers.downloads.DownloadJobService:
Process: android.process.media
<- system / 1000:
Count 6 / time 0.21%
And the corresponding checkin:
pkgproc,com.android.providers.downloads,10017,28,android.process.media,0nf:717,0nb:71332,0ns:48335,0nr:3652,0nl:218034,0ne:10103500,0mf:21,0ms:614,0me:185,1ne:100236
pkgpss,com.android.providers.downloads,10017,28,android.process.media,0ne:18:5310:5950:8434:4036:4522:6140:4036:7127:51056
pkgsvc-run,com.android.providers.downloads,10017,28,.DownloadIdleService,3,0n:1849
pkgsvc-bound,com.android.providers.downloads,10017,28,.DownloadIdleService,3,0n:1794
pkgsvc-exec,com.android.providers.downloads,10017,28,.DownloadIdleService,6,0n:89
pkgsvc-run,com.android.providers.downloads,10017,28,.DownloadJobService,6,0n:58224
pkgsvc-bound,com.android.providers.downloads,10017,28,.DownloadJobService,6,0n:58154
pkgsvc-exec,com.android.providers.downloads,10017,28,.DownloadJobService,12,0n:187
pkgasc,com.android.providers.downloads,10017,28,.DownloadIdleService,system,1000,3,1790
pkgasc,com.android.providers.downloads,10017,28,.DownloadStorageProvider,com.android.documentsui,10010,1,80
pkgasc,com.android.providers.downloads,10017,28,.DownloadProvider,com.android.vending,10011,39,1067022
pkgasc,com.android.providers.downloads,10017,28,.DownloadProvider,system,1000,3,96
pkgasc,com.android.providers.downloads,10017,28,.DownloadProvider,com.google.android.gms,10036,8,1951
pkgasc,com.android.providers.downloads,10017,28,.DownloadJobService,system,1000,6,58149
Bug: 110957691
Test: manual
Change-Id: Id466b085303527e7bf7354f7f33a0fbaa768fb7b
Documentation is pretty vague:
https://developer.android.com/guide/topics/data/autobackup#XMLSyntax.
But there were a couple of issues:
* It was prematurely returning false without consuming the rest of the
includes (cause of the bug linked).
* It was using string comparison for checking if a file is in a
directory, which ended up flagging directories such as "a/b" as
containing files "a/b.txt".
Reviewers,
* Please, pay full attention to test cases.
* Since this is code move + code change, set diff as 2..latest to check
changes to the function.
Bug: 110720194
Test: atest BackupUtilsTest
Test: Backup and restore app w/ multiple directory includes, verify
everything restored
Change-Id: Ic0fea43156ce8fb641af69ae73679289a20c291c
This commit adds the metric for counting failures in registration of
SAR sensor listener.
Bug: 65174506
Test: Unit tests
Change-Id: I8d13336aa9c433128f500063819081cfcc43d2cc
Signed-off-by: Ahmed ElArabawy <arabawy@google.com>
Update docs to clarify that plugins are in fact not supported from K
onward and that enabling them doesn't do anything.
Test: m offline-sdk-docs
Change-Id: I8678ea716be0adc4cd3a6fae1b4776e312ec29e0
Using the Settings App-Developer Options-Feature Flag, allow the user to
enable or disable the Hearing Aid Profile.
Test: Manual testing using Settings App
Change-Id: I58a9d339941e235242c443c85b6f4194b5a296c9
In O and before, KeyguardSecurityVew#reset was always called
before showing the view. In P it's not possible since reset()
will make a series of binder calls and generate jank during
swipe gesture.
Because of this, reset() is called after inflation and only
after the view isn't visible anymore.
Fixes: 109972705
Test: go/sysui-bouncer-tests
Test: receive notification from AOD, double tap it.
Change-Id: I9016924398930d470135851ba40c85f637a2c0d1
Logs could have been misleading if the alarm thread was switched out and
did not get to process alarms for some time.
Test: Builds, boots, existing tests CtsAlarmManagerTestCases pass
Bug: 78560047
Change-Id: Ib450c3f7a936ab127cbd9d87eff78f1c589d9701
