In the previous code, updateTrackingAssociationsLocked() was called too early.
There's still code that changes procstates, so let's move
updateTrackingAssociationsLocked() to the end of updateOomAdjLocked().
Also change Slog.w() to Slog.wtf() so we can monitor it on APR.
Also rate limit the WTF to at most one in ten seconds.
Bug: 118826162
Test: Boot with and without the fix and make sure the number of the warnings
reduces.
(We still have a couple WTFs from during a boot with this CL, which requires
further investigation.)
Change-Id: Ifa1fe85de82fa1d1d8f843372c54c1248966a62a
IntelligenceService is a @SystemApi, and hence not available from non-system.
Test: echo "in TH we trust"
Bug: 111276913
Change-Id: I4c28de49334bdf100a26963e47df9630804730df
A.K.A: "The thing's hollow — it goes on forever — and — oh my God! —
it's full of TODOs!"
Bug: 117944706
Test: m update-api && m
Change-Id: I0774a0df4f4ea0810a8c5f72a1fbcd4eef5cd09b
Add feature flag to launch Safety Hub app instead of Emergency Info
app for teamfood in the future.
Test: Manually
Bug: 118809382
Change-Id: I2fb6ca18419a542159eb070876e01c6130038daa
MediaStore has long suffered from race conditions around creation
of new media. For example, if developers write raw files before
inserting the MediaStore item, an in-progress media scan might pick
up the file before they could insert it. Conversely, if developers
insert the item before writing the files, backup apps get confused
about the file not existing yet.
In addition, the new storage model in Q means that apps can't write
raw files directly to disk, so they need to insert the MediaStore
item first.
To solve this collection of issues, this CL introduces first-class
APIs for contribution of new "pending" media, which includes hiding
the pending media until explicitly published. Apps can safely
resume pending sessions if they crash and restart, which is useful
when the media item is coming from a flaky network. Apps can also
publish progress information about pending media, such as when a
panorama is taking several seconds to process.
Bug: 115377970
Test: atest MediaProviderTests
Test: atest cts/tests/tests/provider/src/android/provider/cts/MediaStore*
Change-Id: I6adee3c4ad1fb9db94906dd1293caaa1a09c6da0
This reverts commit 7d6dbb2b0b.
This change causes a subtle deadlock. Will upload a correct patch in a bit.
Change-Id: I8cb14000943338fb8c2c9049c2d85a4ce8cf6fcd
Bug: 110380403
Test: Manual test in ARC++, prototyped a way that reset reaches ARC++
service.
Change-Id: Icc7dcc8b5c726ed9f61226569227c4d47f44b386
Merged-In: Icc7dcc8b5c726ed9f61226569227c4d47f44b386
- Make ActivityMetricsLogger the single source of truth for activity metrics and
use it to provide data for Tron, logcat, event logs and {@link android.app.WaitResult}
- Remove LaunchTimeTracker
- Remove workaround added for b/80084651
- Remove thisTime from WaitResult and logs
- Remove am_activity_fully_drawn_time EventLog Tag
- Update WaitResult parsing logic in AppLaunch
- Discard metrics if a launching activity is already visible.
- original bug: 67683350
Compatibility Changes:
- thisTime removed from logcat and eventlog. Only totalTime will be displayed.
- Change in activity visiblity during launch will invalidate totalTime. am start -w
will only report WaitTime in this case.
- am_activity_fully_drawn_time is removed from event log.
Bug: 117235762
Test: atest google/perf/app-startup/third-party-apps/cold-dropcache-stable-test -v
Test: manual tests
Test: check applaunch.txt matches test run
Change-Id: Ib033594b961be9227256eba2a519dd6c2e3db573
(cherry picked from commit 132ee83808)
(cherry picked from commit 017cddcbcb)
(cherry picked from commit f8accc5b30)
(cherry picked from commit af0ea31549)
This change adds new APIs for querying historical app ops
for a time period in the past. Since app ops are performed
quite often in some cases keeping track of every app op is
prohibitively inefficient. Therefore, we are exposing
aggregated counts for past ops.
Test: atest android.permission.cts.AppOpsTest
bug:111061782
Change-Id: I59bbf906d62cd6dcd751f2e8089242dcecd55a6c
Dynamically registered BroadcastReceivers are only valid through
the lifecycle of a process, so clients should use static
BroadcastReceivers.
Bug: 117612105
Test: None
Change-Id: Id1a13b0f54aa138685bf8cb57ffe9f176d55e6e0
