To com.android.internal.compat.IPlatformCompat. This solves a java9
issue because libcore exported api has the same package android.compat.
Test: EXPERIMENTAL_JAVA_LANGUAGE_LEVEL_9=true make framework
Change-Id: I0918344f670669cecb04f1e9e54dbcb471b587d5
This CL topic moves the default MimeMap implementation to frameworks.
Libcore starts with a minimal implementation sufficient to pass
CtsLibcoreTestCases, but frameworks can inject the real implementation.
Before this CL topic, the data files and logic (MimeMapImpl) were part of
core-*.jar on device; after this CL, they instead live in framework.jar.
Tests from MimeMapTest that check behavior of that default
implementation also move to a non-libcore CTS test.
Specifically, the logic and android.mime.types now live in
frameworks/base/mime. The default implementation is injected
into libcore from RuntimeInit. I chose to use a separate directory
(frameworks/base/mime/) and build java_library target ("mimemap")
in order to keep this as separate as possible from the rest of
frameworks code, to make it as easy as possible to factor this
out into a separate APEX module if we ever choose to do so.
Planned work for follow-up CL:
1. Make CTS more opinionated, with a plan to assert that all of
the default mappings are present. How exactly the expectated
mapping will be bundled in CTS is still TBD.
2. Add a vendor.mime.types file (defaults to empty) where vendors
can add additional mappings; I plan to make it such that mappings
in that file are parsed last but never override any earlier
mappings, as if each mime type / file extension was prefixed
with '?'.
3. Perhaps enforce that public APIs android.webkit.MimeTypeMap
and java.net.URLConnection.getFileNameMap() behave consistently
with MimeMap.getDefault().
Test: atest CtsLibcoreTestCases
Test: atest CtsMimeMapTestCases
Bug: 136256059
Change-Id: Ib955699694d24a25c33ef2445443afb7c35ed9e7
Both Display.STATE_DOZE and Display.STATE_DOZE_SUSPEND returns true in
func isScreenDoze(int state),so if state change from STATE_DOZE to
STATE_DOZE_SUSPEND or the other way round, mScreenDozeTimer.startRunningLocked
may execute many times, then StopwatchTimer.mNesting++ executes
many times, mScreenDozeTimer.stopRunningLocked runs less than
mScreenDozeTimer.startRunningLocked. The bad result is even we
close ambient.display or stopRunningLocked, the return value from
StopwatchTimer.computeRunTimeLocked() always rises, then Estimated power
for ambient.display in batterystats always rises, it's obviously wrong.
After modifying, startRunningLocked and stopRunningLocked could be
one-to-one correspondence, and the return value from
StopwatchTimer.computeRunTimeLocked() is right.
Problem background: When we turn on AOD(Alway On Display), the display state
may change from STATE_DOZE to STATE_DOZE_SUSPEND or the other way round, then
we find that in BatteryStatsHelper.addAmbientDisplayUsage(), ambientDisplayMs
always rises even after we turn off AOD. ambientDisplayMs equals
mScreenDozeTimer.getTotalLocked(elapsedRealtimeUs, which). At last, we find
that because of the mismatching startRunningLocked and stopRunningLocked,
mNesting is greater than zero even we turn off AOD, then the return value
from computeRunTimeLocked(long curBatteryRealtime) always rises. The appearance
is the ambient.display value in BatteryStats always rises even we turn off AOD.
Test: manual- use modifying version for daily use two days,
the Estimated power for ambient.display is right now.
Change-Id: I7731a60c3bc8be331eebfcd923bb70ecbc661a77
Signed-off-by: zhuguangqing <zhuguangqing@xiaomi.com>
If /sys/class/wakeup is available, get both kernel and native wakelock
stats from SystemSuspend, else we get native wakelock stats from
SystemSuspend and fallback to /d/wakeup_sources for kernel wakelock
stats.
Bug: 128923994
Test: atest FrameworksCoreTests:KernelWakelockReaderTest
Test: Compare dumpsys suspend_control against
dumpsys batterystats --checkin | grep kwl
to verify BatteryStats is getting wakelock stats
from SystemSuspend.
Change-Id: I08e56c984b903285bb965dd853dae4a63fdeb824
Some apps rely on not updating the window format when changing the
background of the DecorView. To keep the compatibilty with these app we
add only call DecoreView.drawableChanged() when the window background is
changed on app targetting Q and above.
Test: Manually test by lunching Instagram TV and pressing return twice.
The window should aninate with no flickering.
Bug: 136987724
Change-Id: I3593d30dc6f10519008151974e475f0dad86fc64
(cherry picked from commit 843f9dee8b)
This is a CP of http://ag/8687829
Bug: 138308096
Test: atest SystemUITests
Change-Id: I9e2b22b157c45da1606466acdfff3c5de7f182e1
Merged-In: I9fa4d1344bb184dea00f92f8d265667f0be11466
(cherry picked from commit e38da07841)
Read wakelock stats from SystemSuspend if possible else fallback to
/d/wakeup_source, /proc/wakelocks.
Bug: 128923994
Test: KernelWakelockReaderTest
Change-Id: I859092d53d7697a4940f9369480e203181f0c370
It's difficult to identify native crash/error of 3rd party app.
Because they can control their app with own signal handling.
Therefore I would like to support the way to ignore signal
registration in 3rd party app with the specific property.
To enable this, do just setprop "debug.ignoreappsignalhandler 1".
Test: test app to hook signal, then setprop debug.ignoreappsignalhandler 1
Change-Id: I2af98a0f58e5ac039eab0ebe9c3780357aca7820
Merged-In: I2af98a0f58e5ac039eab0ebe9c3780357aca7820
Signed-off-by: randy.jeong <randy.jeong@samsung.com>
It's difficult to identify native crash/error of 3rd party app.
Because they can control their app with own signal handling.
Therefore I would like to support the way to ignore signal
registration in 3rd party app with the specific property.
To enable this, do just setprop "debug.ignoreappsignalhandler 1".
Test: test app to hook signal, then setprop debug.ignoreappsignalhandler 1
Merged-In: I2af98a0f58e5ac039eab0ebe9c3780357aca7820
Exempt-From-Owner-Approval: Cherry-pick
Change-Id: I2af98a0f58e5ac039eab0ebe9c3780357aca7820
Signed-off-by: randy.jeong <randy.jeong@samsung.com>
(Goodbye, hypno-P and your '90s tech magazine color palette.)
Bug: 123903304
Test: adb shell am start -n android/com.android.internal.app.PlatLogoActivity
Test: adb shell am start -c com.android.internal.category.PLATLOGO -a android.intent.action.MAIN
Test: adb shell am start -n com.android.egg/.paint.PaintActivity # still works
Change-Id: I4865024a14b6a78e7a043c56d2330b5f9dd214c6
Merged-In: I4865024a14b6a78e7a043c56d2330b5f9dd214c6
(cherry picked from commit 8c7b8cbd39)
Define a traffic tag for dns so that apps know that the traffic
is not sent by them but is sent by the system on their behalf.
Test: Build
Bug: 132125333
Change-Id: I273112c5384999f3155a47f9e7e7cecdd33baa1a
Users are incorrectly being directed to the settings app when
selecting 'Always', making them unable to actually open an app through
the resolver.
Bug: 132071949
Test: Steps are reported in b/136451610
Change-Id: I11775d7b0b780195f08273ad2b90b8ecd2ee1db4
When mutiple apps share shortcuts and are given to the UI to display,
the ranked order from both the App Prediction Service and the legacy
ranker is inadvertently being discarded. This means that targets the
user almost never uses will now be shown as high priority, causing
confusion and pretty horrible user experience.
Address the issue by adding in a score for shortcuts, based on the
index in the ordered list.
Bug: 136201796
Test: atest ChooserActivityTest and manually compare results from
AppPredictionService to verify order is consistent
Change-Id: I1fe2c2d2e13195f6f6c3a5818fade4844c15488e
