Make TimeDetectorService more aware of a time signal's origin by making
the time signal from telephony less generic.
When TimeDetectorService was written it was assumed that the TimeSignal
could be generic and there would just be a String source identifier to
indicate origin.
With multiple SIMs / phones on a device it makes sense to keep track of
the originating phone of the signal so that the time detector service
could implement stickiness if it wanted. This would avoid a device
alternating back and forth between two signals and help with debugging.
As new signals are added, new "suggestXxxxTime()" methods will be added
to TimeDetectorService. That is the point at which the strategy for
ranking different sources can be decided. e.g. should NTP always rank
higher than NITZ?
The main change here is that TimeSignal is renamed to
PhoneTimeSuggestion to indicate it's only for use by signals from
telephony, sourceId has been removed and it has been given a phoneId
instead. Extra free-form metadata (mDebugInfo) has been added to assist
with logging / debugging.
Bug:140712361
Test: atest android.app.timedetector
Test: atest com.android.server.timedetector
Change-Id: I5305c34516e5f4e254309193183f00e054801a46
To support mainline modules, adding the methods which
are used by wifi.
Bug: 139268426
Bug: 135998869
Bug: 138306002
Test: atest android.net.cts
atest android.net.wifi.cts
atest FrameworksNetTests
atest NetworkStackTests
./frameworks/opt/net/wifi/tests/wifitests/runtests.sh
Change-Id: I49856863c15b6b3b59aa867a77b0f137003149ef
We had accidental usages of the PermissionChecker for cases where no
private data was provided to the app but the checkPermission API on
the latter also did blame data access on the app. The PermissionChecker
was designed to handle IPC calls and not for generic API checks.
To avoid future accidental incorrect PermissionChecker usages this
change renames the existing APIs of the latter to clearly indicate
that they should be used for data delivery and also adds sibling
methods for doing the same permission checks for preflight purposes.
Also the documentation is improved to furhter assist developers.
In addition, this change fixes accidental permission checker usages
that blame when they should not by using the new preflight flavor
of the permission check APIs.
Test:
atest com.android.settingslib.location.RecentLocationAppsTest
atest CtsPermissionTestCases
added: LocationAccessCheckTest#notificationOnlyForAccessesSinceFeatureWasEnabled
added: LocationAccessCheckTest#noNotificationIfFeatureDisabled
added: LocationAccessCheckTest#noNotificationIfBlamerNotSystemOrLocationProvider
added: LocationAccessCheckTest#testOpeningLocationSettingsDoesNotTriggerAccess
Bug:141028068
Change-Id: I89f4add79a55c3c8d6fbe8d57decaa78fe12f0f9
Merged-In: I65c71569d0dd8a40bc6fecabb22c5373dd6e806e
We had accidental usages of the PermissionChecker for cases where no
private data was provided to the app but the checkPermission API on
the latter also did blame data access on the app. The PermissionChecker
was designed to handle IPC calls and not for generic API checks.
To avoid future accidental incorrect PermissionChecker usages this
change renames the existing APIs of the latter to clearly indicate
that they should be used for data delivery and also adds sibling
methods for doing the same permission checks for preflight purposes.
Also the documentation is improved to furhter assist developers.
In addition, this change fixes accidental permission checker usages
that blame when they should not by using the new preflight flavor
of the permission check APIs.
Test:
atest com.android.settingslib.location.RecentLocationAppsTest
atest CtsPermissionTestCases
added: LocationAccessCheckTest#notificationOnlyForAccessesSinceFeatureWasEnabled
added: LocationAccessCheckTest#noNotificationIfFeatureDisabled
added: LocationAccessCheckTest#noNotificationIfBlamerNotSystemOrLocationProvider
added: LocationAccessCheckTest#testOpeningLocationSettingsDoesNotTriggerAccess
Bug:141028068
Change-Id: I4a74d4906f92e323fbd30b9b25011129895afc9a
Merged-In: I89f4add79a55c3c8d6fbe8d57decaa78fe12f0f9
Merged-In: I65c71569d0dd8a40bc6fecabb22c5373dd6e806e
waitForService is used to lazily start AIDL services
Bug: 138756857
Test: Manual (tested starting gsiservice with this function)
Change-Id: I7ff16b014052d3845bd4b1baa8fc9843e7975a16
Make TimestampedValue Parcelable for simplicity.
TimetampedValue objects are not generally parcelable, depending on the
type of the value held. Previously, TimestampedValue did not implement
Parcelable to avoid committing to a general contract. Developers
parceling TimestampedValue objects were expected to call
TimestampedValue.writeToParcel() / TimestampedValue.readFromParcel()
explicitly when they knew it was safe to do so. This also meant that
TimestampedValues couldn't be used directly via AIDL.
This change makes TimestampedValue parcelable because it's more
familiar / convenient. Attempts to marshall a TimestampedValue that
contains a non-parcelable value will still throw a RuntimeException.
Bug: 140712361
Test: atest android.util.TimestampedValueTest
Change-Id: I8ca9c72f0433b380ce720cd813f650e743b3ddae
