The old implementation remains in its place for now.
IndentingPrintWriter is still hidden - it will be made public
separately.
Test: atest FrameworksUtilTests:android.util.IndentingPrintWriterTest
Bug: 142281756
Change-Id: Idd2bfa027733ef384b5a676866a89fb3c35b06cb
The target shouldn't be a directory, but if it is, it would be
deleted (as long as it's empty). This became some kind of API and we
need to remain compatible with it.
Bug: 151959443
Test: Reboot and ensure ShortcutService can persist its state
Change-Id: I11a80cd4252128b025912b7aab86b113935e549a
The target shouldn't be a directory, but if it is, it would be
deleted (as long as it's empty). This became some kind of API and we
need to remain compatible with it.
Bug: 151959443
Test: Reboot and ensure ShortcutService can persist its state
Change-Id: I11a80cd4252128b025912b7aab86b113935e549a
Merged-In: I11a80cd4252128b025912b7aab86b113935e549a
Although it may seems a left-over from a previous interrupted write,
actually there are callers who call startWrite(), openRead() and then
finishWrite(), and this was okay in the previous implementation, so we
have to keep supporting it.
The new file is virtually ignored in the new implementation, and we
have no good way to know if it's actually a left-over or one that's
being written, so simply leaving it there is also okay.
Fixes: 157092639
Test: atest AppIdleHistoryTests#testFilesCreation
Change-Id: I4dc7fde99d2b8e04356f082a6e6ad61c2835022e
The previous implementation of backing up beforehand doesn't handle
the case where the file is created for the first time, and might leave
a corrupted file in case of failure.
This new implementation creates a new file for writing data into, and
renames it into the place of the original file after writing
finished.
Fixes: 151959443
Test: atest android.util.AtomicFileTest
Change-Id: I5c4c438526a2aecdd2af18f71e16b41a05817c61
Merged-In: I5c4c438526a2aecdd2af18f71e16b41a05817c61
The previous implementation of backing up beforehand doesn't handle
the case where the file is created for the first time, and might leave
a corrupted file in case of failure.
This new implementation creates a new file for writing data into, and
renames it into the place of the original file after writing
finished.
Fixes: 151959443
Test: atest android.util.AtomicFileTest
Change-Id: I5c4c438526a2aecdd2af18f71e16b41a05817c61
These were previously being suppressed by doclava but with this change,
all failures are fixed and the suppression logic has been removed.
To fix the issues, there were a few possible changes made:
- broken reference to a public API (such as incorrect parameters): fixed
- unnecessary @link inside an @see tag: fixed
- @see referring to an @hide or @SystemApi: reference removed
- broken references to inner class constructors
- worked around by fully qualifying the constructor
Bug: 6963924
Test: make doc-comment-check-docs
Exempt-From-Owner-Approval: cherry-picked from master
Change-Id: Ifbdce2de96cdffa560bd90f549fa7184d1f9af85
Merged-In: Ifbdce2de96cdffa560bd90f549fa7184d1f9af85
(cherry picked from commit e0624c7a40)
Added a new flag "--statsd" to dumpsys procstats, it'll dump
the identical protobuf data as the one being sent to statsd;
these data is aggregated/reduced. The tradtional "--proto"
is still supported in case the full data is needed.
Align the ProcStats's proto message definition with the statsd.
Fixed various other issues with ProcStats's dumping.
Bug: 148542701
Test: atest ProcStatsValidationTests
Change-Id: I5a22603bfbc97bfac93179289df839710364677d
So we can show it in developer options. Also fix a bug
where the setting wasn't being respected in systemui.
Test: atest
Bug: 152907434
Change-Id: I1eaed93a0c8a1ec4486c7072972e2f924402bb94
-Use more idiomatic and efficient parceling
-Cleanup LocationRequest a bit
Bug: 151026407
Test: presubmits
Change-Id: I3865421a128417a5096e39ee110139a13ab9ab3b
This CL doens't change println_native() because:
- To avoid potential risks (jank?) because it's kind of late in the RVC
cycle.
- The JNI overhead is unlikely to be a major problem in logging. If apps
are making *that* many log calls, that itself would be a bigger
problem.
Test: treehugger / boot
Bug: 152217649
Change-Id: I86aeb62b217e5331e6bbd02a0ba592fd050a41b2
Use the same ordering of digest algorithms as the apksigner and
the general v3 checking do.
Test: adb install --incremental <apk> with v4 signature
Bug: b/151241461
Change-Id: I5c4c8339d7fd2ba127bd0f453efc9c04a8be7ac7
