Several android.timezone classes have already been exposed for the
telephony module work, so these tests provide coverage for those.
Additional APIs have been exposed for MTS testing, i.e. to provide
greater confidence that the tzdata module data is correct / is
being read correctly.
Also, small changes to existing code to make them consistent with new
classes. Small docs improvements.
Bug: 147884233
Test: see system/timezone change
Change-Id: I047b29f17a41993f859947a6d6c3685896fe4cb6
This commit makes a number of changes:
1) Documents / enforces thread safety, removes or deprecates unsafe
check-then-do methods / adds a way to get the NTP query result
atomically.
2) Delays configuration lookup until point of use: the config can change
due to various possible config overlays, e.g. MCC-based config.
(1) is because the threading model is currently unclear / possibly
unsafe - it looks like NtpTrustedTime is supposed to be single threaded
but it's also a singleton so could be accessed from multiple threads.
If NtpTrustedTime were not a singleton things might be easier but the
@UnsupportedAppUsage makes it difficult to change now.
(2) is to address the same issue as https://r.android.com/1182530,
contributed by Luca Stefani.
Bug: 140712361
Test: build only
Merged-In: Ie09da9db5d853b59829886a020de21a88da5dd51
Change-Id: Ie09da9db5d853b59829886a020de21a88da5dd51
(cherry picked from commit 65f0f31bde)
* changes:
Add --supportQ flag to java StatsLog codegen
Support new socket schema in native codegen
Move statsd metadata from statslog to atoms_info
Fix StatsEvent memory usage for pulled events
Rename android.util.TimestampedValue to android.os to avoid dependency
from android.util onto android.os, which is disallowed by lint.
Bug: 147012511
Test: boot
Merged-In: I4b84db03c8ad24bbef63e45d6d15fb306a10364e
Change-Id: I4b84db03c8ad24bbef63e45d6d15fb306a10364e
(cherry picked from commit d159015e54)
Existing annotations in libcore/ and frameworks/ will deleted after the migration. This also means that any java library that compiles @UnsupportedAppUsage requires a direct dependency on "unsupportedappusage" java_library.
Bug: 145132366
Test: m && diff unsupportedappusage_index.csv
Change-Id: I288969b0c22fa3a63bc2e71bb5009fe4a927e154
Merged-In: I288969b0c22fa3a63bc2e71bb5009fe4a927e154
Add usePooledBuffer flag to the Builder which determines whether to reuse
the Buffer's byte array in StatsEvent or use a copy.
The build() function also calls release() on the Buffer
if a copy of the Buffer's byte array is passed to StatsEvent.
Also, for pushed events, release the StatsEvent object and consequently,
the Buffer in StatsLog.write(StatsEvent)
Fixes: 145026572
Fixes: 144126444
Test: bit FrameworksCoreTests:android.util.StatsEventTest
Change-Id: I1cdaf0027b69281cb7cb6f3c8ca923d03829b4dd
Merged-In: I1cdaf0027b69281cb7cb6f3c8ca923d03829b4dd
Bug: 143978873
Test: m -j
Test: flashes successfully
Test: DocumentsUI(a Mainline module) is able to successfully log to statsd
Change-Id: I9cdc6151d8feb29a712532e50f143af9d52c8d94
Merged-In: I9cdc6151d8feb29a712532e50f143af9d52c8d94
- Rename writeAttributionNode to writeAttributionChain
- Make Type Id, size limit constants public and @hide for testing
- Change visibility of StatsEvent package protected functions to public
Bug: 141696033
Test: m -j
Change-Id: Ia4818f621672d469390bf7654bdd317f0cd11692
Merged-In: Ia4818f621672d469390bf7654bdd317f0cd11692
- Expose atom id in StatsEvent.
- Sync constants with native stats_event.
Bug: 143079343
Bug: 143286399
Test: m -j
Change-Id: Icaa2d90b40d5da7571444182ead03b54b7b25867
Merged-In: Icaa2d90b40d5da7571444182ead03b54b7b25867
Use a builder to construct StatsEvent objects.
Make StatsEvent immutable.
Wrap socket byte array in a Buffer class with write methods for
primitives.
Implement socket schema at go/statsd-socket-doc
StatsEvent.java design doc at go/statsevent-java-doc
Bug: 141696033
Test: m -j
Change-Id: Ief4890882de66d5dcca71b3827ffa1f43ea628a8
Merged-In: Ief4890882de66d5dcca71b3827ffa1f43ea628a8
The actual APIs are subject to change once socket encoding is finalized
and StatsEvent needs to be marked as @SystemApi. This will be addressed
in a future CL.
Test: builds successfully
Bug: 141696033
Change-Id: I508fa3d2f84850438562d01c78155590819badca
Merged-In: I508fa3d2f84850438562d01c78155590819badca
Fix copy and paste errors from commit 4ab8a199de -
the API is new so does not need @UnsupportedAppUsage and
the debug log was incorrect.
Bug: 140712361
Test: build only
Change-Id: I123f76d011d7505d3dc053cb48c40353f0579d17
This CL is a partial cherrypick of ag/9686088. This is needed because new
changes to libstatssocket (that need to be cherrypicked into AOSP) wrap
#write_to_statsd() with #write_buffer_to_statsd().
Bug: 143978873
Test: m -j
Test: flashes successfully
Test: DocumentsUI(a Mainline module) is able to successfully log to statsd
Change-Id: I886331f728ccaa3d281b5683eb89179aa73596b6
Merged-In: I9cdc6151d8feb29a712532e50f143af9d52c8d94
This change moves some logic associated with time detection out of the
NetworkTimeUpdateServiceImpl and moves it to the TimeDetectorStrategy
called by the TimeDetectorService.
The TimeDetectorStategy implementation now decides when to use an
NTP-derived time instead. The logic implemented here is effectively the
same as it was: NITZ takes priority over NTP until the latest NITZ
signal becomes "too old".
The motivating reasons for the change:
1) The "what signal is used when several are available?" logic should be
in one place: the TimeDetectoryStrategy not scattered around the
platform. Centralizing will enable different strategies and time sources
to be introduced over time.
2) It will allow removal of the ACTION_NETWORK_SET_TIME intent in a
follow-up commit; this intent was used to coordinate the NTP vs NITZ
logic should no longer be required.
The "bonus" effect of this change is that NetworkTimeUpdateServiceImpl
becomes more general: It can now be the authority for the NTP time on a
device independently of how the system clock should be set. e.g. it
could be used in future to back the
AlarmManager.currentNetworkTimeMillis() API call. Anything that needs a
"what is the best time according to NTP?" answer could use this service.
Note: The NetworkTimeUpdateServiceImpl still observes the AUTO_TIME
setting and will perform an NTP lookup "on demand" (if required) when
the user enables the setting. This should be a temporary state and
likely to be removed in future; knowledge of AUTO_TIME shouldn't be
required for the NTP info to be correct and if
NetworkTimeUpdateServiceImpl is doing the right thing.
Bug: 140712361
Test: atest com.android.server.timedetector
Test: atest android.app.timedetector
Change-Id: I4b2936a42c552c4dd4cb55010306bb81bca0c712
To help with monitoring Mainline releases, log the reason
for a watchdog-initiated rollback. This may be due to
native crashes, app crashes, ANRs or explicit health check
failures.
Add a mapping from PackageWatchdog failure reason to the
new metrics.
Bug: 146415463
Test: atest PackageWatchdogTest
Test: atest StatsdHostTestCases
Change-Id: Ia3e73d955508297004591eac762555665c557b8a
Merged-In: Ia3e73d955508297004591eac762555665c557b8a
(cherry picked from commit dd1dabaef7)
Updated first sample with `Reference.reachabilityFence(this)`
to be consistent with the second sample.
Bug: 145831809
Test: none
Change-Id: I8c625de4f36a8cd52a3825021ff631db62f04662
Wrap dalvik.system.CloseGuard and expose it as a
public API from android.util.
Bug: 145831809
Test: atest CloseGuardTest
Change-Id: Ia44c84a69a5fb693fb8bb1a075c18a60253cedfc