After API council feedback, use List<Location> in public APIs rather
than LocationResult.
Bug: 173712888
Test: atest CtsLocationFineTestCases
Change-Id: I02caa1f9c7164b52ef55c71ca14fb2bd7e311a85
This allows third party location providers to link against the standard
API surface. This replaces the LocationProviderBase implementation in
the com.android.location.providers API. Both will temporarily coexist
until third party applications can be migrated, and then old version
will be removed. Only the LocationProviderBase API is migrated right now
as its the only API that has undergone changes.
This also restores some old, unused classes which should not have been
remove from the API surface. Clients that support older API version will
still need to link against these classes.
Bug: 176115245
Test: builds
Change-Id: I2d688447e1f59e441f5c48ff36d3f0dd8b5dc7f6
Delete location.timezone.provider API classes and associated internal
classes that are no longer used.
Bug: 175633818
Test: build
Change-Id: I66319e63e3150e3b71f31f8d9404e4114f802662
LocationProvider cannot represent unknown properties, which is currently
causing problems with getProvider() which may return null even when a
particular provider exists. Instead provide isProvider() to query
whether a provider exists, and getProviderProperties() to query a
provider's properties.
Bug: 176232308
Test: atest CtsLocationNoneTestCases
Change-Id: Ic42cc953624be116616b0b997e18356247fdf288
Switch LocationTimeZoneEvent to elapsedRealtimeMillis from nanos. This
makes it more consistent with other usages of the elapsed realtime clock
in time zone detection. This information is currently only used for
debug so there will be no functional change.
Also change LocationTimeZoneEvent toString() to additionally report
mElapsedRealtimeMillis value using Duration.toString(); this is done
elsewhere in debug output for time zone detection so makes understanding
log output easier.
Bug: 169304499
Test: build only
Change-Id: If307c9b27d64ca49a4fcc0d9bb6e36f362990b3e
LocationTimeZoneEvent was originally supposed to fulfil the same role as
Location does in the LocationProvider. Since Location is public SDK, it
was in android.location. LocationTimeZoneEvent is not public SDK (or any
form of API), so it can be moved to com.android instead.
LocationTimeZoneEventUnbundled is in the API in its place.
Bug: 169304499
Test: treehugger only
Change-Id: I5d382362383000b16852928895a18ac4e4269a8f
-Moves batching APIs from SystemApi to Public, and makes them
multi-client safe.
-Adds equals/hashcode to Location.
Bug: 171512333
Test: manual + presubmit
Change-Id: I6ee28f8229fdf49386cd370ea785de63b97e7cde
It causes problems with permissions in testing and isn't strictly
required so it can be removed.
Bug: 152744911
Bug: 149014708
Test: atest services/tests/servicestests/src/android/location/timezone/LocationTimeZoneEventTest.java
Change-Id: Iba9c07780e3cc9f94f2c77144c48916236f31e60
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
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
Expose the LocationTimeZoneProvider and associated classes in the
location lib API.
Bug: 152744911
Test: build only
Change-Id: Ib577bbdee10d7778e28fc1c6003cc97fdb15acb3
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
-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
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
The package name from the service watcher may be inconsistent with the
package name of the currently bound service.
Test: none
Change-Id: Iede437d2e61a0da0b853fdbb133a29add04f6bf3
Remove LocationTimeZoneProviderRequest.workSource and correct some docs.
Bug: 152744911
Test: treehugger only
Change-Id: Ibd26886a1c4e66507bbcaafc5132b615e5af443e
Minimal skeleton for location time zone providers. Most behavior has
been stripped and more detail will be added later.
Test: atest services/tests/servicestests/src/android/location/timezone/LocationTimeZoneEventTest.java
Test: services/tests/servicestests/src/com/android/internal/location/timezone/LocationTimeZoneProviderRequestTest.java
Change-Id: I64102df0970e6cfbcc07c9377b226c8663a29a74
Providers no longer need the ability to specify additional packages,
this can be replaced with tracking the provider identity.
In addition, move CallerIdentity into the client space, and fix some
minor GNSS bugs.
Bug: 149839935
Test: atest LocationProviderTest
Change-Id: Ide107abc61531946b20d2ac50cd9555fc215ef03
All calls out of system server must be oneway to prevent the system from
being blocked by external code. Geocode has been the very last interface
not to conform to this - this is now fixed.
Bug: 146677166
Test: atest GeocoderTest
Change-Id: Ib04d36a9b759f1737ebc2806e49f0bf1e53cea7c
There were a couple problems with work profile state in location. First,
we assumed that notifications sent to parent users would also be sent to
profiles but this is not true. Second we had assumed location status in
profiles was always identical to the parent user, but work profiles may
have user restrictions applied which are not present on the parent user.
The easiest way to handle these issues seems to be to expand LMS user
handling to deal with all users, rather than making various assumptions
which may or may not be true.
This also means we need to store last locations on a per profile basis.
Since we're refactoring how last location works completely, we also
removed the special NO_GPS handling for last locations. With the new
permission strings we now no longer have to exclude gnss based location
from coarsening. This lets us:
1) deprecate and remove various constants and methods use for storing
coarse locations tied to fine locations
2) substantially simplify code that calculated coarse location
This also exposed numerous bugs in the location service where we were
using the current user's state instead of the calling user's state,
which could have exposed the current user's location to other users
inappropriately.
Bug: 148798374
Bug: 146071833
Test: presubmits + manual
Change-Id: I2d3216a9fb58b73d0124d563b05de8870b70b716
DPM can currently control the master location toggle, but cannot
influence the behavior of individual providers. This adds an API for
DPM (or other privileged entities) to request a provider to turn itself
on.
Practically, this is necessary to allow DPM to control network location,
which may be gated by additional consents. This change also renames some
internal location code to make clearer the distinction between provider
enabled and provider allowed: enabled = location on && allowed
Bug: 136219903
Test: CTS tests to be added
Change-Id: I05f03c976428f0f5a8a2cf627a84dc9e2baf3e67
Fix some minor bugs and ensure fused location provider correctly
supports location bypass. This is especially important for when
location bypass is invoked in direct boot.
The added UPDATE_DEVICE_STATS permission is necessary for FusedLocation
to correctly update WorkSources. FusedLocation receives work from LMS and
then further delegates that work to other location providers. The other
location providers should be informed of the correct applications for
battery blame, and should not be blaming the FusedLocation package.
1) This is the minimally scoped permission necessary to battery blame
correctly.
2) There is no way to attribute battery blame without this permission.
3) This is the correct permission - as required by LocationManager, and
this permission will likely never be removed (FusedLocation will always
need to battery blame).
Test: atest FusedLocationTests
Change-Id: If7126fffaae5577ddf8e366a0b5c17b3e5286582
Ensures that lint tests can run properly from client code which uses
this library.
Bug: 130188099
Test: manual
Change-Id: I1d3c8e486c38633d73c405f2c6f9b350ef1e6946
This call has never worked in testing, and adds a significant penalty to
dumping LocationManagerService.
Bug: 125313528
Test: manually
Change-Id: Ia455578e2b941c5a0888abb79a13adc0bb55729a
Rename APIs while there are no clients. Also prevent throttling when
location settings are being ignored.
Bug: 118883513
Test: manual
Change-Id: I225c50b152e77ab181c959ecd9dc652333f59d5e
This will replace the LocationManager.getNetworkProviderPackage() API
with LocationManager.isProviderPackage(). The network provider should
not be considered special.
In addition, providers now have the ability to specify additional
packages that may make location requests on their behalf, so that those
packages can be considered location providers as well.
Bug: 117177078
Test: manually
Change-Id: I204b56e7bb40874ac3347988474fb8afa787feb8
Removing AR from the Android code base. We had already severed the
connection to the AR HAL in Android Oreo. This change simply removes all
unused references and uses of the stubs.
Test: Build compiles. Ensure that clients that provide AR through other
channels continue to work.
Change-Id: I79d19c0bd2b80962cdecc8ad88065911fd6311ac
Put enabled/disabled state under location provider control, and use it
to represent whether a location provider may be used, not whether the
user has enabled or disabled a location provider.
Bug: 118885128
Test: manually
Change-Id: I1209c49c13ca8995b223f383ad332322fffc7a96
After Treble's FLP merge into GNSS HAL, the FlpHardwareProvider is just
an empty shell. Removing FusedLocation and/or Flp + Hardware classes
altogether.
Bug: 35726697
Test: m -j
Test: Open Google Map and then walk around. The dot moves as I walk.
Change-Id: I7f413e38b57424e8ebb9d7d14d94f145a48d10f8
com.android.location.provider.stubs is the stubs library for the shared
library com.android.location.provider. The stubs library is intended to
provide the stable set of APIs to the apps implementing location
provider.
Without the stubs library, apps had to directly link to the shared
library which is built without Android SDK and exposes private APIs that
are not intended to be used by apps. This also has been causing the
lin-type check warnings when the shared lib is used by apps built with
SDK; apps built with SDK is not allowed to link to lib built without
SDK. This has been reported as warnings but will soon be errors. Now
such apps are required to link to the stubs lib, which is built with
SDK.
While building the stubs library, following APIs are made hidden because
they are exposing private APIs from the Android platform.
1) Activity* classes are removed from the API, as they are not intended
to be used by apps since O.
2) GeocodeProvider and GeofenceProvider are removed from the API.
3) LocationProvider.mLocationManager is removed as it is exposing the
private symbol ILocationProvider
4) ProviderPropertiesUnbundle.getProviderProperties are removed from the
API as it is exposing the private symbol ProviderProperties.
5) The constructor of ProviderRequestUnbundled is removed since the
class is intended to be instantiated by the service.
Bug: 71420593
Test: m -j com.android.location.provider.stubs
Change-Id: I20aba7e9ca9c3adc75db241f37a55f0d657f3ced
Add a callback-based mechanism for GmsCore to connect to Hardware Activity
Recognition. This allows GmsCore to stop polling to identify if the Android
platform supports the functionality or not.
Bug: 17112184
Change-Id: I8f9459cbd15eecd70f6919c6551e6f7a663c732f
Ensure that activities are unregistered from AR HW when the client's
binder dies. This clean up is required to prevent AR HW to keep active
when there are no clients listening for events.
Bug: 19894637
Change-Id: Iccd609cf1d2d4a4453c7a96cb8645b61639c3234
Retain compatibility with implementations compiled
against old headers or left unchanged from LMP.
Change-Id: I3f7cfaaf0cba8697c312940a805b053c6040caa6
Currently GmsCore has to guess how many locations to retrieve
based on requested frequency and then demux the output looking
for timestamps (that aren't monotonically increasing). This
capability gives GmsCore a more graceful solution.
Change-Id: Ie1d71615f699bc0d3c63f8b80aa7b40b9971cf96
Let HAL implementation tell if geofencing/batching is
supported and which technologies (GNNS, wifi, etc)
can be used.
Still todo: Add ability for GmsCore geofencing to
tell which technologies are supported (instead of
just using it to update monitoring). This requires
SystemApi change + approval so will do in separate CL.
Note that the classes in the lib are not copied
directly into GmsCore. The instance will always
be whatever is in the platform. This is why
the callback is backwards compatible as long as
their is a default implementation (but not if
it's abstract).
Change-Id: I7d6adeb049b89935bc4443785df5d7ef4c730e5d
