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
Some things really need to be tuned in order to not annoy users, and
should otherwise be turned off. Let an effect state whether it should
fallback to a generic effect or should just be silent if there's no
hardware specific version of it.
Fixes: 65219268
Test: manual
Change-Id: I38fcbd6d80803cdf8f4ec04e8e1ac363b8d6361b
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
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.
Bug: 29337859
Bug: 32163131
Test: runtest frameworks-net
Test: runtest frameworks-telephony
Change-Id: I7a4d04ab47694d754874136179f8edad71099638
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
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
Change-Id: I0304e555544ee18c83244672766c767cbad650a1
Verified that nobody should be using these APIs, and they've been
deprecated long enough that we can remove them.
Bug: 62341924, 62263907, 62264550
Test: make -j32 update-api && make
Change-Id: I9a2333ca13e4984b71374aa7ffed081e5106c67e
Hides getFd & getFileDescriptor due to lifecycle concenrs.
Adds ASharedMemory_dupFromJava to allow sharing a shared
memory region between Java & Native as safe as possible.
Mis-use results in an FD leak instead of double-close.
Bug: 64394076
Test: SharedMemory CTS tests
Change-Id: I01a5eb978fc4e99559a79baac75754c32f13bdc4
Previously, wakeup alarms (for an app) were using the battery-on
timebase. Now they will instead use the battery-on-screen-off timebase.
In this way, apps won't be penalized for wakeups that occurred when
the device was being actively used anyway.
Also bumps up report version to 25.
Also bumps up parcel version.
Change-Id: I1b692a9137ff28d535e7a06b539f713b54a85ea9
Fixes: 64149996
Test: manually verified count doesn't increase when screen-on
Change from the previous attempt:
- Fixed the helper class. The original version had a few bugs.
- Bundle.readFromParcel() now handles a Parcel with a read-write helper
properly.
** Comparison **
The following charts are the actual measurement with and without the fix,
using "dumpsys system".
- The red bar is "total private dirty".
- The X axsis is time since boot.
Without fix:
- #1 First boot:
-- https://docs.google.com/spreadsheets/d/1CbmU8cQQQw7n7tyqbZi3beRHNuzqcmJgdvzDpi40Q1I/edit#gid=1971317391
-- Private dirty stabilizes at ~16.8M.
-- Loading system packages took 1.8 seconds.
- #2 Second boot:
-- https://docs.google.com/spreadsheets/d/1CbmU8cQQQw7n7tyqbZi3beRHNuzqcmJgdvzDpi40Q1I/edit#gid=982210726
-- Private dirty stabilizes at ~17.5M.
-- Loading system packages took 0.5 seconds.
With fix:
- #3 First boot:
-- https://docs.google.com/spreadsheets/d/1R6lL0AnAp93HnrqWujJFNgOjj6wvGicgDlbDAevbc3g/edit#gid=791764875
-- Private dirty stabilizes at around the same level as #1.
-- Loading system packages took 1.9 seconds.
- #4 Second boot:
-- https://docs.google.com/spreadsheets/d/1CbmU8cQQQw7n7tyqbZi3beRHNuzqcmJgdvzDpi40Q1I/edit#gid=1820894299
-- Private dirty stabilizes at around the same level as #1.
-- Loading system packages took 0.7 seconds.
Package manager start up time with and without the fix:
- (Ignored ones that are too fast; probably the thermal throttling didn't kick in.)
- https://docs.google.com/spreadsheets/d/1CbmU8cQQQw7n7tyqbZi3beRHNuzqcmJgdvzDpi40Q1I/edit#gid=499396796
- Before: 3.5 seconds (average of 5 reboots)
- After: 3.6 seconds (average of 5 reboots)
Package scan speed comparison:
- With the fix, first boot.
08-03 08:49:56.851 1000 779 779 I PackageManager: Finished scanning system apps. Time: 2133 ms, packageCount: 143 , timePerPackage: 14 , cached: 0
08-03 08:49:56.971 1000 779 779 I PackageManager: Finished scanning non-system apps. Time: 121 ms, packageCount: 11 , timePerPackage: 11 , cached: 0
- With the fix, second boot.
08-03 08:53:29.387 1000 779 779 I PackageManager: Finished scanning system apps. Time: 484 ms, packageCount: 143 , timePerPackage: 3 , cached: 143
08-03 08:53:29.424 1000 779 779 I PackageManager: Finished scanning non-system apps. Time: 37 ms, packageCount: 11 , timePerPackage: 3 , cached: 11
** Conclusion **
- This CL wil slightly slow down the boot time (0.2 seconds on a thermal-throttled bullhead), but
the system server's ram consumption will go down to the no-cache level.
- Using the package cache is still faster than not using it.
Test: build, boot, reboot, adb-install, reboot
Test: bit FrameworksCoreTests:android.content.pm.PackageParserTest
Test: bit FrameworksServicesTests:com.android.server.pm.PackageParserTest
Test: cts-tradefed run cts-dev --skip-device-info --skip-preconditions --skip-system-status-check com.android.compatibility.common.tradefed.targetprep.NetworkConnectivityChecker -a armeabi-v7a -l INFO -m CtsOsTestCases -t android.os.cts.BundleTest
Bug: 64112468
Change-Id: I30691a032cb1dd1c7f6c1966a096c2f0d07a09cb
The original operation creates new string everytime which is expensive
Bug: 64272195
Test: NA
Change-Id: Id93d588a7d5a6b6c192a057fcd4296bd1c508516
(cherry picked from commit 8529150860)
