The metrics are persisted in /data/system/shutdown-metrics.txt file
property and logged after reboot. MetricsLogger API cannot be directly
used during shutdown since event log is cleared on reboot/power off.
Test: manual reboot/shutdown and verify that metrics are logged
Bug: 64815357
Change-Id: I7fa1af8be58a80a3d5bae26d55c1ed40bf98f4c0
When launching to quicksettings, the camera icons showed
above the camera, clashing with their UI
Test: launch camera (locked) and click on galery
Fixes: 64317909
Change-Id: I4ef68963af11f6d0be739c79cdf352ba35d9ece0
Since otherwise they would be illegible with the color
tranformation.
Change-Id: I5c1fa085fc3d6f682012c267d489a95fc7073f32
Fixes: 64810767
Test: manual, add decoratedMediaCustomView
The current implementation is using the anchor view's getWindowToken to
construct the TooltipPopup instance. This does not work if the anchor
view is in a popup window.
Using getApplicationWindowToken fixes the problem.
Bug: 64595364
Test: android.view.cts.TooltipTest#testTooltipInPopup
Change-Id: I1a887c9ae6ac00f2412891f316367acfc56cef94
This change stops relying on the ro.boot.container property for dropping
a subset of capabilities and instead relies on the effective capability
mask of the Zygote process, prior to forking.
When Android is running in a pid/mount/net/user namespace, even if a
particular capability is present, some operations that require that
capability check whether it is allowed in the init namespace (instead of
in the current namespace), so they would fail even with the capability
granted within the namespace. So, explicitly dropping the capabilities
from the beginning allows for clearer signalling of which operations can
be expected to work instead of failing silently for mysterious reasons.
Bug: 63579953
Test: aosp_bullhead-eng still boots
Test: Running Zygote without CAP_SYS_MODULE makes it such that
system_server does not request it.
Change-Id: I1d18d13341bcc04e701fd14092e7e94961728620
Colors specified manually using the public WallpaperColors
constructor should not be blacklisted.
Test: runtest -x tests/Internal/src/android/app/WallpaperColorsTest.java
Test: runtest -x tests/Internal/src/com/android/internal/colorextraction/types/TonalTest.java
Change-Id: I96faf413e3629c247220d825bb7c3480ed2f1003
Fixes: 64361146
Renamed BootTimingsTraceLog to TimingsTraceLog. It is now used for
boot and shutdown logging.
Added measurements for main stages of shutdown in the system server:
ShutdownTiming: SendShutdownBroadcast took to complete: 734ms
ShutdownTiming: ShutdownActivityManager took to complete: 203ms
ShutdownTiming: ShutdownPackageManager took to complete: 17ms
ShutdownTiming: ShutdownBt took to complete: 533ms
ShutdownTiming: ShutdownRadio took to complete: 534ms
ShutdownTiming: ShutdownNfc took to complete: 1536ms
ShutdownTiming: ShutdownRadios took to complete: 1538ms
ShutdownTiming: ShutdownStorageManager took to complete: 906ms
ShutdownTiming: SystemServerShutdown took to complete: 3918ms
Bug: 64569080
Test: shutdown/reboot and check logs
Change-Id: I636c045852cd1ed6be1c58af6608f70e95756389
This cl writes currentDuration to Parcel, so in battery settings we could
use this data in anomaly detection.
Also note that in getTotalDurationMsLock(aka method1), the logic is:
result = mTotalDurationMs + getCurrentDurationMsLocked(aka method2)
Since now method2 is not zero, we also tweaked the value for
mTotalDurationMs to make method1 return the same value compared with
before.
Since getMaxDurationMsLocked depends on mNesting, which is always zero,
so we don't need to tweak value for mMaxDurationMs
All these methods are covered in BatteryStatsDurationTimerTest
Bug: 64255589
Test: runtest -x BatteryStatsTest
Change-Id: I9168be099d00bb68fedbc5bfbb7bf7f0d9aae85a
