These are APIs that have @UnsupportedAppUsage but for which we don't
have any evidence of them currently being used, so should be safe to
remove from the unsupported list.
Bug: 170729553
Test: Treehugger
Change-Id: I4c8fd0006f950de9955242e93968fb0996ceb372
Previously ListenerMultiplexer attempted to be perscriptive about when
individual listener invocations should be allowed, but this is not
proving flexible enough. So, we allow registrations to invoke listeners
at any time without being perscriptive about it instead.
Test: manual + presubmit
Change-Id: I6ff8c6bd4f3e3af15d6ebc4b484b971df5a8c0e2
* changes:
Apply fixes for EfficientStrings.
Apply fixes for EfficientStrings.
Apply fixes for EfficientStringsChecker.
Apply fixes for EfficientCollections.
Trivial refactor for consistent naming.
Expand formatSimple() to support widths.
Refinement of EfficientStringsChecker.
The recently-built Error Prone checker has found many instances where
we're always paying the cost of StringBuilder concatenation, even in
the typical cases where preconditions are successfully met.
Benchmarks have shown that even when replacing these with varargs
formatter strings, the default case is 20x faster.
Bug: 170978902
Test: none
Exempt-From-Owner-Approval: trivial refactoring
Change-Id: If8c00bc73467bfb91ec16c162969c9d26ca53646
Expose quality APIs publically after refactoring them to match external
usage of quality constants. Removes list of location requests from
provider request, as there is no client that really uses this, and it
feels like too much information to give to providers.
Bug: 168624248
Test: presubmits
Change-Id: Icf8a9f6096da0071d97190d3f7196948492e52a1
This API is no longer necessary for testing, and inappropriately exposes
internals. Also updates battery saver TEST_MAPPING to include location
tests.
Bug: 170224294
Test: presubmits
Change-Id: I1322f21ced86d3622650ecf02dfa959a484660d0
-Prevent PendingIntents from using LocationRequest SystemApis. We don't
track permission removal, so we don't current reset the request if the
permission is lost.
-Make LocationRequest.getWorkSource() NonNull. Small quality of life
change to reduce null checks all over.
-Don't spend CPU coarsening location until we actually need to. The vast
majority of locations will never need to be coarsened. Don't bother
doing so until we actually need to.
Bug: 169887240
Test: manual + presubmit
Change-Id: I7ad6fe886eaede3ed9f46cebe4246d29d6b6e187
Log a much wider variety of important events in memory for bugreports
and dumpsys. This will make debugging much easier, hopefully at a
minimal memory cost. Memory cost could be improved in the future as
well.
Test: manual + presubmits
Change-Id: Iab867575f783f1c5f41a405da66f72d5f52691bf
This is a breaking change so that providers are no longer disabled for
non-current (ie background users). Instead, location requests from
background users are now considered inactive. This brings provider
behavior more in line with other APIs (such as GNSS and geofencing),
and allows us to special case requests from the system UID.
Without this change, the system UID would see incorrect provider
enabled/disabled notifications. Impact on clients is expected to be
minimal, as by far the vast majority of android applications run on
single user devices. For multiuser devices, applications will no longer
see enabled/disabled notifications in response to current user changes.
Bug: 157682495
Test: manual + presubmit
Change-Id: I0edb15f0792bf1426855baefcda8477ba3a32b28
Prevent applications from bypassing background location throttling by
adding/removing requests. This allows provider managers to delay
requests in the event the interval has decreased so that power can be
saved. Clients that target S and above may now receive historical
locations in exchange, so that they are not losing locations overall.
Locationp providers can optionally implement delays themselves in the
event of an interval increase.
Also updates jitter calculation to be a capped percentage of the
request interval, rather than a flat cap.
Bug: 73144566
Test: manual + presubmits
Change-Id: I243e813f0c0c504850e2a3e777787f49fc6f7a57
Expose the LocationTimeZoneProvider and associated classes in the
location lib API.
Bug: 152744911
Test: build only
Change-Id: Ib577bbdee10d7778e28fc1c6003cc97fdb15acb3
Ensure that when getCurrentLocation() times out locally, remote work in
system server is also canceled.
Bug: 168666216
Test: manual
Change-Id: Idde2156323c3fca0ed94ff886a4277122c598753
This commit introduces a LocationTimeZoneEventUnbundled, as
LocationTimeZoneEvent will not be on another API surface so cannot be
reused. (The equivalent from LocationProvider is Location, which is
public API so there is no LocationUnbundled.)
Add an initialization timeout to LocationTimeZoneProviderRequest so that
providers can make intelligent choices about (for example) how long to
spend waiting for geolocation to happen passively.
Test: atest services/tests/servicestests/src/com/android/internal/location/timezone/
Test: atest services/tests/servicestests/src/com/android/server/location/timezone/
Bug: 152744911
Change-Id: Id3e9e6916e8c3a132d8fc892338578ab9d2ff574
Cancellation was not being propagated to the system server due to a
misunderstanding on how CancellationSignal functions. There is no
noticable impact for the user, as cancellation did properly prevent any
further locations, however this would have resulted in extra
power draw since the system server would not have canceled the
associated provider location request. This would have left
getCurrentLocation() as equivalent to requestSingleUpdate() where it was
supposed to be an all-around improvement that could save power.
Bug: 168666216
Test: manual + presubmits
Change-Id: I5c77db4cc56cce1b984587f65d2bcfb488436bb8
Cancellation was not being propagated to the system server due to a
misunderstanding on how CancellationSignal functions. There is no
noticable impact for the user, as cancellation did properly prevent any
further locations, however this would have resulted in limited extra
power draw since the system server would not have canceled the
associated provider location request. Impact is limited since
getCurrentLocation() was limited to a 30s duration anyways.
Bug: 168666216
Test: manual + presubmits
Change-Id: I5c77db4cc56cce1b984587f65d2bcfb488436bb8
Fix a bug where we were overstrict in validating legacy location
requests, and didn't cover all possible legacy inputs. Specifically,
clients that pass in Long.MAX_VALUE as the interval - unclear why any
client would want to do this, but nevertheless, it was allowed.
Bug: 168927418
Test: presubmit
Change-Id: Iaa604da6dee9e860f13abe0a74853579f757e249
-Store tag string in multiplexer rather than duplicating in every
registration.
-Add support for failure callbacks at listener operation submission
time, in addition to within the listener operation itself.
-Extract request out of ListenerRegistration and into subclass, so that
the multiplexer does not need to have any knowledge of requests.
-New multiplexer specific execute and failure callbacks within
registrations objects, with strongly typed listener operation objects.
-Fixed resetService() to work properly even if the service is still
registered.
-Added registration info as an argument to registerWithService() so that
this doesn't need to be duplicated if a client wants access to this
information.
-Narrow exception handling so that only the proper exception
(RemoteException for binder calls for instance) results in registration
removal, and other unexpected checked exceptions should still crash the
process.
-Various other minor fixes.
Test: manual + presubmit
Change-Id: I6fdec313222ff1ef01a1aa4d27d8ee56b4be25d4
-Encapsulate various fields
-Bring naming in line with API guidelines
-Minor refactoring
Bug: 168621146
Test: manual
Change-Id: I55681a3d84d7833c98569a13a57e6c4f0b728a67
LocationRequest and associated APIs have historically always been
SystemApi, for no real reason. In keeping with the Android-wide push to
clean up API surfaces like this, we make LocationRequest a public API.
Bug: 166692379
Test: manual + presubmits
Change-Id: I6a93fca1a5613c96bf35da158bc542e47864dbff
Small fixes to basic classes and refactorings noticed while preparing a
later change. These changes are fairly "obvious" fixes and refactorings,
removed from the later change to make it smaller.
Test: atest services/tests/servicestests/src/com/android/server/timezonedetector/
Bug: 149014708
Change-Id: If9bcb567778d82f49b3481c50a64c0d739ce2ace
Both null and non-null GnssRequest objects may be present in the list of
requests to merge.
Bug: 165375330
Test: presubmits
Change-Id: I13284b1c32f1ad1fce39ad1ca2e4298194197015
These changes have been broken out as they stand alone and should be
relatively uncontroversial.
The LocationTimeZoneEvent is having UserHandle added, mostly for
logging at this point so we can debug issues with multi-user providers.
Bug: 152744911
Bug: 149014708
Test: atest services/tests/servicestests/src/android/location/timezone/LocationTimeZoneEventTest.java
Change-Id: Iafbd5bc9778d68bc9c3046244e7dca6d9892519e
This extracts LocationProviderManager as a completely stand-alone class,
substantially reducing the complexity in LMS, and in
LocationProviderManager. Core AOSP location code is now unit testable
for the first time, and we begin adding unit tests.
Test: extensive manual tests + presubmits
Change-Id: I0fb17ddbf91bdd26ed7855110026b3dd09612a5c
Will minimize future changes:
-Never return null GpsStatus to avoid breaking legacy clients
-Allow null location callback complete callbacks
-Return void from sendExtraCommand
-Combine appops and permissions checks into a single helper
-Allow passive provider to remember last locations even when there is
no active passive request.
-Add a couple new injectable helpers to support future changes along
with fakes for testing.
Test: presubmits + manual
Change-Id: If22bee787c5ab5c8c09d20e4742a8b5d1b7f0b59
Even though getGpsStatus is marked Nullable, some applications expect it
to always return non-null.
Bug: 161311411
Test: presubmits
Change-Id: I8d58621588253af1dc917711e230cfd176afec37
Currently, Java clients are manually creating the StatsEvent objects
which can lead to errors. Now that there is support for pulled atoms for
stats-log-api-gen for Java clients, use the appropriate buildStatsEvent
method that was auto generated by stats-log-api-gen.
Bug: 160368804
Test: Ran `m` and completed successfully
Test: Ran `atest statsd_test` and all CTS tests passed
Test: Ran `atest UidAtomTests` and all CTS tests passed except for the CTS tests related to a SIM card because the device does not have a SIM card
Change-Id: Id229ba5ca94203135a8a5e2607de9844e0432ce1
The package name from the service watcher may be inconsistent with the
package name of the currently bound service.
Test: none
Change-Id: Iede437d2e61a0da0b853fdbb133a29add04f6bf3
