Involves pushing most of the logic down out of StatsPullAtomService
and into KernelAllocationStats.cpp, as well as changing some method
signatures along the way.
At the end of this work, two new fields in atoms.proto will be
populated; these will allow us to tell how much of SurfaceFlinger's
dmabuf memory usage is due to buffers shared with other processes
and how much is due to private internal buffers.
Test: statsd_testdrive 10105
Test: adb shell dmabuf_dump
Bug: 220084049
Change-Id: Ia41cfd693d3db2bd06083801075cae290f67221f
On devices which use flattened APEX, treat the allowlists as part of the
system image.
Test: m # lunch wembley_2GB-userdebug
Bug: 221862988
Change-Id: I1971a686aa111b396f9e694a74be70d758078423
This is so the soures can be accessed both fom framework and modules.
The implementation needs the local StatsLog, so cannot be reused.
Test: m
Test: atest SystemUITests
Test: make statsd_testdrive $ANDROID_HOST_OUT/bin/statsd_testdrive 90
Bug: 218862369
Change-Id: I27ebffa6817575f1377beb80f4092287d9b12c49
Merged-In: I27ebffa6817575f1377beb80f4092287d9b12c49
This is so the soures can be accessed both fom framework and modules.
The implementation needs the local StatsLog, so cannot be reused.
Test: m
Test: atest SystemUITests
Test: make statsd_testdrive $ANDROID_HOST_OUT/bin/statsd_testdrive 90
Bug: 218862369
Change-Id: I27ebffa6817575f1377beb80f4092287d9b12c49
Mark deferMonitoring/begin/end/cancel/abandon events of FrameTracker.
Bug: 220281996
Test: See trace
Change-Id: I3d3eace0048c523c94311432cb96db8301015c0c
On ODPM enabled devices, the total mobile radio power consumption was
being used when reporting the idle/suspended power. This means app
mobile radio power consumption was effectively being double counted.
Bug: 209525694
Test: atest MobileRadioPowerCalculatorTest
Change-Id: Ibc1a504014ac10c285b71273ba50493ba237f6a9
Revert submission 17083643-large-icons-tm
Reason for revert: Speculative revert for android.app.cts.NotificationManagerTest breakage.
Reverted Changes:
Ib66933a8f:Size restrict right notification icon size
If3d871e78:Downscale large bitmaps in CachingIconView
I504694cb2:Support downscaling of Drawable icons in LocalImag...
Bug: 224768026
Change-Id: Icae8dfdfb89544f76a43a141b5f93271a03db360
Revert submission 17083643-large-icons-tm
Reason for revert: Speculative revert for android.app.cts.NotificationManagerTest breakage.
Reverted Changes:
Ib66933a8f:Size restrict right notification icon size
If3d871e78:Downscale large bitmaps in CachingIconView
I504694cb2:Support downscaling of Drawable icons in LocalImag...
Bug: 224768026
Change-Id: Iabb2d26899979aff25afa095baacd6bae12f6fde
ServiceConnector does not call unbindService when requested to unbind if
the service isn't currently connected. This causes issues like leaving
zombie Trusted Hotword processes bound forever if the process is stopped
('restarted') immediately after being created (say if audio server
crashes twice in quick succession).
Fix: 223845998
Test: manual - locally comment out code that immediately connects the
service, then `for i in {1..10}; do adb shell cmd voiceinteraction\
restart-detection; done` - without fix results in an extra process
Change-Id: I6a8c01390130bcec9aff1460004343ca2b207031
* changes:
Size restrict right notification icon size
Downscale large bitmaps in CachingIconView
Support downscaling of Drawable icons in LocalImageResolver
If ModemActivityInfo is available on a device, smear the provided
transmit and received times across RadioAccessTechnology and frequency
(for NR RAT).
Bug: 207697945
Test: atest BatteryStatsNoteTest
Change-Id: Ifb4e30dc3fa5ac5dd4824a87a7a86c4a0d14d019
(cherry picked from commit e85ac3239e)
CachingIconView is used to displayed (smallish) icons in Notifications. Those can accidentally be made very large if big resources are used.
This makes CachingIconView use LocalImageResolver to load those images with limited size. This fixes large memory use of notification header icons.
Bug: 210690571
Bug: 218845090
Test: Manually on small and large Pixel device with Notification tester APK
Added Unit Tests to cover this case.
Change-Id: If3d871e788608c1702461d563673560fa18fc53f
LocalImageResolver only enforced downscaling for Uri-based Icons at this point. This still allowed app developers to provide large bitmaps as a resource or as a bitmap payload itself. This change also verifies these new types of bitmaps.
Also adds an external size parameter to image resolver so different widgets can use it - right now the upper limit was hardcoded in pixels.
Bug:218845090
Bug:210690571
Test: Manually on device - tested on Raven and new Pixel with multiple
notification sizes via notification test apk.
Unit tests
Change-Id: I504694cb27953bc7950669b1b48f90d2e9c6a68d
We would like to make relayoutWindow a non-blocking call,
and of course why not, who likes blocking. However it functions
as a critical path of BLASTSync. To understand why examine the
Guarantee described in BLASTSync.md.
In order to implement this guarantee we need to know
“Which frame has the client finished drawing” when it calls
finishDrawing. The current answer to this question is
“The frame reflecting the state observed in the last call
to relayoutWindow”. The comments on mPending and mCurrentDrawHandlers
also have a lot more context on how this works currently. Since
relayoutWindow has a critical section, it also ensures that changes
to syncable state and preparation of sync will be observed atomically
(since they are both observed over relayoutWindow, which is always
called before any frame drawing updated syncable state).
We design a new protocol described in BLASTSync.md, which uses a seqId
to track which call to finishDrawing reflects which syncable state.
We implement this seqId based system. Unfortunately the WindowManager
doesn’t quite conform to the requirements specified by the protocol,
and a follow up CL ensures that syncable state changes will
always be sent with the seqId.
This CL simply adds the protocol specification and makes some required
interface changes. It can be seen to be a no-op.
Bug: 161810301
Bug: 175861051
Bug: 175861127
Bug: 200285149
Change-Id: If2dea07121fe7de5d2524c5b63678dddf955d4b7
Now that FDE is no longer supported, checking the FDE password cache
will never accomplish anything. Remove this check from Keyguard, and
remove the supporting code from LockSettingsService.
Bug: 208476087
Change-Id: If1bb80dfcc015aeea19916a88c89a4067e6ada32
(cherry picked from commit e9b69111b2)
Merged-In: If1bb80dfcc015aeea19916a88c89a4067e6ada32