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
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>
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
collection to SystemSuspend (ISuspendControl::getWakeLockStats())
Native wakelocks obatined via SystemSuspend when useSuspendCounter is
enabled, will not be reflected in the information available from
/d/wakeup_sources or proc/wakelocks. This information has been
made available via the ISuspendControl AIDL interface of SystemSuspend.
Kernelwakelock stats however are still being collected in the
/d/wakeup_sources.
Change-Id: I208d004aa0fabcf367016faae77ad51388cdf0ea
Bug: 135680393
Test: Observe SystemSuspend service wakelocks in dumpsys batterystats (for
instance, "PowerManager.SuspendLockout"):
`dumpsys batterystats --checkin | grep wl | grep PowerManager.SuspendLockout`
This reverts commit 95aa6d446f.
Reason for revert: This change has been implicated in 4-way deadlocks as seen in b/134244752.
Bug: 134244752
Change-Id: I2f1839d7776a613ca571af8a542755ddc5fc8760
Merged-In: Ibdaad3a4cbf0d8ef1ed53cfab1e454b9b878bae9
This avoids loading constructors with reflection for well-known View classes.
An average of 1300 app startups with and without this change shows the special
casing improves app startup time by about 2.5ms.
The classes listed here are taken from examining several app traces as well as
the similar list in AppCompatViewInflater.
Bug: 131421854
Change-Id: I676a50eec50b86fa0b385add4bc092a657d8e8bb
As per API council feedback, these constants should live in
a place that is private to the network stack, only with a
range defined in system API.
Bug: 129433383
Test: m
Change-Id: I84a90f84a9af6fef4667ee4d512ebd0413222086
Merged-In: I4882686a86e7c6d42f4b0619b921d02619ed6d4c
Merged-In: I9b648ed6c687d56db61a54570c7880c51c1bae51
Apps may (and do) assume that libraries are readable. To avoid app
breakage, mark execute-only sections of as read+execute
for apps with targetSdkVersion<Q.
Bug: 128907672
Test: Check libc for app with targetSdk==current
cat /proc/25950/maps | grep libc.so
77c01e3000-77c028b000 --xp 00041000 07:20 106 /apex/com.android.runtime/lib64/bionic/libc.so
Test: Check libc for app with targetSdk<current
cat /proc/26355/maps | grep libc.so
77c01e3000-77c028b000 r-xp 00041000 07:20 106
/apex/com.android.runtime/lib64/bionic/libc.so
Change-Id: I90b5c91923c8008ae4b4818985842fe3e354a850
Merged-In: I90b5c91923c8008ae4b4818985842fe3e354a850
(cherry picked from commit 739c0b5193)
In order to notify netd to swap eBPF maps before pulling the
networkStats from eBPF maps, NetworkStatsFactory need to use the
NetdServices to issue binder calls. So it need to be moved from
framework/base/core to framework/base/service since object in
framework/base/core cannot get any system services. This change is also
necessary for setting up a lock inside NetworkStatsFactory to prevent
racing between two netstats caller since the lock need to be hold before
netd trigger the map swap.
Also fix the compile problem caused by moving the NetworkStatsFactory
and the related tests. Rename the packages and the jni functions to a
more proper name.
Bug: 124764595
Bug: 128900919
Test: NetworkStatsFactoryTest
android.app.usage.cts.NetworkUsageStatsTest
android.net.cts.TrafficStatsTest
Merged-In: Ifcfe4df81caf8ede2e4e66a76552cb3200378fa8
Change-Id: Ifcfe4df81caf8ede2e4e66a76552cb3200378fa8
* changes:
Move BatteryStats and StatsCompanionService to use NetworkStatsService.
NetworkStatsService: Fix getDetailedUidStats to take VPNs into account.
Take all VPN underlying networks into account when migrating traffic for VPN uid.
This CL is a manual merge of http://ag/c/6015966/3.
Bug: 113122541
Bug: 120145746
Test: atest FrameworksNetTests
Test: manual test: verified that BatteryStats are correctly accounting
for VPN traffic.
Change-Id: I5b07ce70ac58bdcbebc3114bfe9fd411469d57af
Merged-In: I230c1edbf64cfeb3dbb560db368b5e420f7b79a4
This API is similar to one provided by NetworkStatsFactory with the
difference that NSS also migrates traffic from VPN UID to other apps.
Since traffic can only be migrated over NetworkStats delta, NSS
therefore maintains NetworkStats snapshot across all UIDs/ifaces/tags.
This snapshot gets updated whenever NSS records a new snapshot
(based on various hooks such as VPN updating its underlying networks,
network getting lost, etc.), or getDetailedUidStats API is invoked by
one of its callers.
Bug: 113122541
Bug: 120145746
Test: atest FrameworksNetTests
Test: manually verified that battery stats are migrating traffic off of
TUN (after patching above CL where we point BatteryStats to use this
API).
Change-Id: Ib0f0c2d4d41ee1d7a027ea9da457baaf198d649e
VPN uid.
Bug: 113122541
Bug: 120145746
Test: atest FrameworksNetTests
Test: Manually verified on device that stats from VPN UID are moved
appropriately based on its declared underlying network set.
Test: vogar --mode app_process --benchmark NetworkStatsBenchmark.java
Change-Id: I9d8d0cc58d18002c1c96f8ddff780ef8dc452d21
For packages:
com.android.internal.app
com.android.internal.database
com.android.internal.http
com.android.internal.os
com.android.internal.policy
com.android.internal.util
com.android.internal.view
com.android.internal.view.menu
com.android.internal.widget
com.android.server.net
com.android.server
com.google.android.collect
com.google.android.util
This is an automatically generated CL. See go/UnsupportedAppUsage
for more details.
Exempted-From-Owner-Approval: Mechanical changes to the codebase
which have been approved by Android API council and announced on
android-eng@
Bug: 110868826
Test: m
Merged-In: Ia5306f4713298b46ae3aba6fc9d87fae41f8a593
Change-Id: Ie26033d486033289ad3e010a534a921d29c3b2ca
This is specifically for HIDL but is applicable to other libs.
Classes on the bootclasspath are implicitly used by apps. For this
reason, many classes should not go there. However, there are some
libraries which are used by many apps/processes which are still
nice to preload the ClassLoaders of.
Now, cacheNonBootclasspathSystemLibs in ApplciationLoaders keeps
a map of jar -> ClassLoader in zygote to be retrieved by child
processes.
Bug: 128529256
Bug: 127406460
Test: boot Pixel 2, verify libs are preloaded and used, try apps that
use these libraries.
Test: grep for ClassLoaderContext errors, for instance:
- ClassLoaderContext shared library size mismatch
- ClassLoaderContext classpath element mismatch
Test: showmap on various processes which use the preloaded libs.
Change-Id: I351bf1679e9a928c10dca860b6cd6cb414c3bb8e
In an effort to allow loading integrity-checked artifacts from
the dalvik-cache, attempt to create and cache the system server's
classloader early, while still being in the system_server_startup
selinux domain.
The advantage of this approach is that allowances for loading
from the cache are restricted to startup.
Bug: 128688902
Test: m
Test: Device boots, picks up /system artifacts
Test: Device boots, picks up integrity-checked /data artifacts
Merged-In: If4a75fa106db09f1bd666d6d8df7ac3ac3e35a8c
Change-Id: If4a75fa106db09f1bd666d6d8df7ac3ac3e35a8c
