Age | Commit message (Collapse) | Author |
|
Add API that will be invoked whenever anyone checks if the device is in
a significant place. This will allow us some latitude in implementation
of SignificantPlaceProvider (for example by avoiding geofences if
necessary) in the event of significant power burn without needing to
commit further changes in the framework. This gives us the flexiblity to
fix potential future issues with just implementaion changes. Ideally
this will never need to be used.
Flag: significant_places
Bug: 337870680
Test: manual
Change-Id: If25b328dd8140dedb972489c5363e4d0c7102310
|
|
Interfaces can be used to define the operations a significant place
provider must fulfill and what operations it can take.
Bug: 337870680
Test: na
Change-Id: I27ba0e3c9e48138c871bbaed3864956116ee39df
|
|
1) Deprecate old GeocoderProvider API which is not part of any published
API surface.
2) Create new GeocoderProviderBase API which lives in normal SystemApi
surface.
3) Cleanup various callback APIs and geocoding POJOs used internally.
Bug: 279319276
Bug: 229872126
Test: CTS
Change-Id: I1da453ba5f9fd98b08ecdbbbacf640497ed6cd42
|
|
Split it up into more generic and useable components that are not as
location specific.
Bug: 182491144
Bug: 181665909
Test: presubmits
Change-Id: I2d6d5e70328657a7430e170531402cb3acbed028
|
|
After API council feedback, use List<Location> in public APIs rather
than LocationResult.
Bug: 173712888
Test: atest CtsLocationFineTestCases
Change-Id: I02caa1f9c7164b52ef55c71ca14fb2bd7e311a85
|
|
|
|
Bug: 176905795
Test: on device
Change-Id: I56f0a2f117acfa9971222980acc7ed9f273da820
|
|
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
|
|
|
|
Test: presubmit
Change-Id: Ib2b0fd5c2065e85b390815fad6a2d7e04b81afb7
|
|
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
|
|
Bug: 144955780
Test: presubmits
Change-Id: Iec8520acfd98b9d9d92a4876ebfa899ac2a0731e
|
|
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
|
|
Test: manual
Change-Id: I0fde3dd9bdd418ab63c61c5afc093d8eef72e600
|
|
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
|
|
This reverts commit e24f1b095b020382f555c7f34f22ff3fb5005f90.
Reason for revert: b/123172409
Change-Id: Ic5863a8e8b36c8c4d8636cc4c004ad9606a3f523
|
|
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
|
|
Deprecate and remove logic around location provider status.
Bug: 118885128
Test: Tested manually on device
Change-Id: I68289cb5ed22e66532847758c36155a4ce607bbc
|
|
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
|