Also now pass the flags to the forked process through --runtime-flags instead
of converting to command line arguments and converting back to an integer.
bug: 30972906
bug: 63920015
Test: builds
Change-Id: I7f10c43dd916ca2d3b9b5141f17261eb7b64f49a
Clean up SystemProperties.java. Add annotations.
Clean up SystemProperties.cpp. Refactor for proper C++11.
Make sure C-string key construction is properly reused. Use
android::base functionality for actual reading.
Fix the test script to refer to the right location. Add some
test coverage.
(cherry picked from commit 2e6b9cb563)
Test: m
Test: frameworks/base/core/tests/systemproperties/run_core_systemproperties_test.sh --rebuild
Merged-In: I490577370da985f600fb1117e3c818d3f68bad5f
Change-Id: I490577370da985f600fb1117e3c818d3f68bad5f
Add a warning that calling get() is unsafe when the system property
may not contain a valid UTF-encoded string.
(cherry picked from commit 6bf1cff1dd)
Bug: 63177684
Test: m
Merged-In: I68e3096d770a32fe204be5c130a3ada9d3db7c0b
Change-Id: I68e3096d770a32fe204be5c130a3ada9d3db7c0b
Currently, we only count add tethering traffic to per-UID
stats, but not to total data usage (i.e., dev and XT stats). This
is correct for software tethering, because all software forwarded
packets are already included in interface counters, but it is
incorrect for hardware offload, because such packets do not
increment interface counters.
To fix this:
1. Add an argument to ITetheringStatsProvider#getTetherStats to
indicate whether per-UID stats are requested. For clarity,
define integer constants STATS_PER_IFACE and STATS_PER_UID
to represent these operations.
2. Make NetdTetheringStatsProvider return stats only if per-UID
stats are requested. (Otherwise tethering traffic would be
double-counted).
3. Make OffloadController's stats provider return the same
stats regardless of whether per-UID stats were requested or
not.
4. Make NetworkStatsService add non-per-UID tethering stats to
the dev and XT snapshots. The per-UID snapshots were already
correctly adding in per-UID stats.
(cherry picked from commit 5356a35c3b)
Bug: 29337859
Bug: 32163131
Test: runtest frameworks-net
Test: runtest frameworks-telephony
Change-Id: I325b13d50e88841dfb0db4c35e7e27f163ee72fe
Merged-In: I4e8e923d68dce1a4a68608dbd6c75a91165aa4ee
Add a new tetherLimitReached method to INetworkManagementService,
and call it when the HAL notifies OffloadController because the
limit has been reached.
Bug: 29337859
Bug: 32163131
Test: builds
Test: OffloadControllerTest passes
(cherry picked from commit d66cf56ba6)
Change-Id: I89719fe7ec8bfd3c85d6cdca9c0d449aea86ef9d
Merged-In: I026e6aa9e7b371f316c0d97c3cf5e78abc1f5263
HAL impls will depend hwbinder.jar instead of framework.jar on
build-time, but on runtime framework.jar will be used.
This is to cut the circular dependency when using configstore from
Android framework. Also added JNI call to HwBinder.java to cut
configstore's dependency on systemproperty in framework.jar.
Note that hwbinder.jar is LOCAL_UNINSTALLABLE_MODULE and so it won't be
installed in an actual image.
Bug: 35771640
Test: build & run
Change-Id: I2420298cf9df5d6bbcead3e4451b703ce9bc3e29
Currently, netd is the only source of tethering statistics.
In order to support multiple sources, define a new
ITetheringStatsProvider interface that can be registered with
NetworkManagmentService. Convert the existing code into the
first ITetheringStatsProvider.
(cherry picked from commit ef7b2a13ce)
Bug: 29337859
Bug: 32163131
Test: builds, boots
Test: tethering stats continue to be collected
Change-Id: Ie1b5a5e47ae4bf5af922365b09fa241e834236e4
Merged-In: Ie1b5a5e47ae4bf5af922365b09fa241e834236e4
There are a few AIDL-generated stubs that perform "destroy"
transactions and call "this.destroy()". Previously, this
resolved to the "destroy()" method from their interface on
ART while resolving to Binder.destroy() on the RI, though
this is a subject of a bug report against the JDK,
http://bugs.java.com/bugdatabase/view_bug.do?bug_id=8021581 .
Resolving to the private Binder.destroy, inaccessible to
the Stub, would lead to throwing IllegalAccessErrror.
As we're changing the method lookup to be closer to RI, see
https://android-review.googlesource.com/413119 ,
we should stay clear of the problematic cases whether we
make a decision to follow the RI precisely or not. Therefore
we rename the Binder.destroy() to Binder.destroyBinder().
Test: Nexus 6P boots.
Bug: 62855082
Change-Id: I43baf76b6f3c681d93b411cecf2bc00fccafecac
Causes too many GCs and related slowdowns.
Verified that assistant launch from holding down home button is now
faster than N.
Test: make and flash
Bug: 62769566
Change-Id: Ib0c1f7a45831b241d3376d1e56db3c6937913b1b
Wrong description of the "tid" parameter used by getThreadPriority():
the function does not "change" the priority of the thread associated to
"tid".
Defined also the meaning of setting tid parameter to 0.
Test: None
Change-Id: I8552f3b110eaab1aefa51477e82d3e295547be34
Signed-off-by: Alessio Balsini <alessio.balsini@gmail.com>
...can't hide themselves
Tune the policies for when we tell about apps running in the
background after their services have stopped.
- If it ran while the screen was on, the time we require for it
to be running is much shorter (a couple seconds) as well as the
time we tell about it having run (with another tunable for the
minimum time we tell about this).
- If it has only run while the screen is off and stops a sufficient
amount of time before the screen goes on (currently a second) then
we will not show anything when the screen goes on.
- If it stops when the screen turns on, we will make sure the user
sees about it for a short period of time (currently 5 seconds).
Also includes some improved debug output about handler message
queues.
Test: manual
Change-Id: Iab438410d7182b2dfe4f9c1cce7069b26b34834c
It has been discovered that for background values of
AggregatedWakelock, Sync, Job, and partial wakelocks,
the value of getTotalTimeLocked is wrong and often very
negative. getTotalDurationMsLocked, which should provide the exact same
value in all of these cases (since background data is never pooled),
does not have this problem. So while the source of the bug is sought
out, we should use getTotalDurationMsLocked instead of getTotalTimeLocked for
these data.
Bug: 62352334
Test: cts-tradefed run cts-dev -m CtsDumpsysHostTestCases -t android.dumpsys.cts.BatteryStatsDumpsysTest
Change-Id: I78e84368615578483ab8e9e5f0ee1d067491be08
This forces everyone to go through sdcardfs, instead of letting them
around the back door.
Test: builds, boots
Bug: 38231314, 27992761
Change-Id: I97b24d25599c7f86f9b535689e2f4ecf68261dac
We've seen some @SystemApi methods protected with non-system
permissions, so give Doclava the platform AndroidManifest.xml so it
can parse the actual permission protection levels to look for APIs
that are letting in non-system apps.
Also document more @SystemApi permissions.
This is purely a docs change; no logic changes are being made.
Test: make -j32 update-api
Bug: 62263906
Change-Id: Ie0f0a5fb0033817bcc95060f2183a52ae4ae7b06
Most @SystemApi methods should be protected with system (or higher)
permissions, so annotate common methods with @RequiresPermission to
make automatic verification easier.
Verification is really only relevant when calling into system
services (where permissions checking can happen on the other side of
a Binder call), so annotate managers with the new @SystemService
annotation, which is now automatically documented.
This is purely a docs change; no logic changes are being made.
Test: make -j32 update-api && make -j32 offline-sdk-docs
Bug: 62263906
Change-Id: I2554227202d84465676aa4ab0dd336b5c45fc651
When answering the question "how much space is free", use the same
logic for Settings UI and StorageManager.getAllocatableBytes(). That
is, the reported free space is usable bytes plus any cached data the
system is willing to delete automatically.
This does *not* include any reserved cache space, since we don't want
abusive apps to penalize other well-behaved apps that are storing
their data in cache locations. Callers freeing cached data need to
now explicitly request defiance of the reserved cache space. (Most
callers are already doing this by using FLAG_ALLOCATE_AGGRESSIVE.)
Rewrite the core logic of DeviceStorageMonitorService to understand
this new "reserved" cache space, and to be easier to understand. It
also now handles cached data on adopted storage volumes, which had
been ignored until now. Also fix bug where we had skipped "low"
broadcasts when the device skipped directly from/to "full" state.
Bug: 38008706
Test: cts-tradefed run commandAndExit cts-dev -m CtsJobSchedulerTestCases -t android.jobscheduler.cts.StorageConstraintTest
Test: cts-tradefed run commandAndExit cts-dev -m CtsAppSecurityHostTestCases -t android.appsecurity.cts.StorageHostTest
Change-Id: Icbdcf3b52775f7ada1ceaeff2f96094c8d8052f9
Allows tracking ble scan time (total and background) for unoptimized
scans. Whether the scan is unoptimized is provided by the bluetooth
code when calling batterystats.
Bug: 38461344
Test: runtest -x frameworks/base/core/tests/coretests/src/com/android/internal/os/BatteryStatsTests.java
Test: run cts-dev -m CtsIncidentHostTestCases -t com.android.server.cts.BatteryStatsValidationTest#testUnoptimizedBleScans
Test: cts-tradefed run cts-dev -m CtsDumpsysHostTestCases -t android.dumpsys.cts.BatteryStatsDumpsysTest
Change-Id: I814482ff663424170eac4b413464d24c14a5cf91
