- LocationManager.isProviderEnabled() no longer throws SecurityException:
the caller could already circumvent the permission check by calling
Secure.isLocationProviderEnabled()
Change-Id: I5abd04264299671ed35ce4594b5be46d86378767
- Split getStatus() into onGetSummary() and onGetEnabled()
- Call them on app's UI thread
- Allow runtime exceptions to propagate up
- Make a couple of more methods final to prevent subclasses from playing
around with the intent
- Remove explicit timing requirement from javadoc
- Mention that this will be restricted to system-image apps (will be
enforced by the actual settings code)
- b/10461474
Change-Id: Id22dd7a707c05de396ae4c5810e839ca734714c0
- Currently redundant with PROVIDERS_CHANGED_ACTION, but that may
change in the future
- Part of fix for b/10409275
Change-Id: I12daaf20e6546fd9e9dc71c599967fa0ad95e27f
- Fix additional getInt() path, restores the location settings screen
functionality.
- Should fix "unresolved link" build breakages in
git_klp-dev-plus-aosp-without-vendor, which is much more persnickety than
klp-dev for some reason.
- Add warning that we may add additional location modes in the future.
- Finish fix for b/10461763 and b/10461474
Change-Id: Id7155e3a0d7526a377d446018ef3bdb057bad3a6
- Escape < and > in javadoc
- Constructor does not take log tag
- Start intent rename
- Comments for Status.summary and enabled
- Bonus fixes:
- Start renaming STATUS_KEY to SUMMARY_KEY
- Send message back even if getting the status fails so we don't have
to wait for the fetch to time out
- Add comment about setting activity being invoked when disabled
- Partial fix for b/10461474
Change-Id: I025e7e0782c2873a4eda20ab4793bc6145daf8db
Document their purpose and permissions required in case
this is unhidden in a different code line.
Change-Id: I42f6f950157f488cf51b361e3411861ff98794e8
Helps to make sure the service doesn't throw a
SecurityException for not having the UPDATE_DEVICE_STATS
permission.
Change-Id: I9be0302f1378d2c4441e6b7d5ce472ed0d5fbd80
This seems to be the standard usage, and there are rare reports of
requestLocationUpdates giving NullPointerExceptions on the first call
to requestLocationUpdates but not on subsequent calls (b/10207898).
Change-Id: If7a873fba5a2cd77b836ff3fda89105da20104ac
Move icon to right side of the screen and synchronize status with
AppOpsManager.OP_MONITOR_HIGH_POWER_LOCATION.
Change-Id: Iea2570501cb18be0489669fd4ea240dc63f9567a
LocationManagerService now annotates incoming Location objects that
have come from mock location providers. The new isFromMockProvider()
method can be called on any Location to determine whether the
provider that supplied the Location was a mock location provider.
Bug: 6813235
Change-Id: Ib5140e93ea427f2e0b0036151047f87a02b4d23a
Initial implementation, tracking use of the vibrator, GPS,
and location reports.
Also includes an update to battery stats to also keep track of
vibrator usage (since I had to be in the vibrator code anyway
to instrument it).
The service itself is only half-done. Currently no API to
retrieve the data (which once there will allow us to show you
which apps are currently causing the GPS to run and who has
recently accessed your location), it doesn't persist its data
like it should, and no way to tell it to reject app requests
for various operations.
But hey, it's a start!
Change-Id: I05b8d76cc4a4f7f37bc758c1701f51f9e0550e15
This commit adds the valid ranges to the latitude/longitude
parameters in Geofence.createCircle()'s javadoc.
Bug: 7172696
Change-Id: Iff6e3c3723d3fd9b6393bbc827ec5755c0d034af
Many media files and source code files were marked as executable in Git.
Remove those.
Also a shell script and python script were not marked as executable.
Change-Id: Ieb51bafb46c895a21d2e83696f5a901ba752b2c5
Hide all new location APIs related to LocationRequest/Geofence and
undeprecate all deprecated APIs consequently to the LocationRequest and
Geofence introduction. Also introduce LocationRequestUnbundled for
LocationProviders to use.
Change-Id: I5b116c7d342041f45b341c88a4b6813571118018
In this commit, we provide a means for unbundled location providers
to attach an EXTRA_NO_GPS_LOCATION to the Locations that they report.
We also build FusedLocation against the SDK rather than the internal
tree.
Used in conjunction with I394ded497b8de40d1f85618bff282553cdf378cb
to fix NLP for applications with only ACCESS_COARSE_LOCATION
permission.
Bug: 7453355
Change-Id: Ie696f7abff9ef5237740ab87fe9f537a1c812c54
The javadoc mistakenly claimed that GPS and PASSIVE location
providers could be used with ACCESS_COARSE_LOCATION permissions.
That was incorrect, and the javadoc has been amended.
Bug: 7389249
Change-Id: I6f6489bb539679a962c67ae7263857700df33c82
This commit is the result of a comprehensive permissions review for
MR1 release. It addresses a number of deviations from spec and from
MR0's behavior, bringing MR1 into sync with both.
It also cleans up the concept of "location resolution permission",
representing it internally as an enumerated access level to reduce
reliance on cumbersome string manipulation. There's a function to
convert the enum int into a permission string where needed, too.
Additionally, this confines caller-identity-sensitive calls to the
hopefully-obviously-named "getCallerAllowedResolutionLevel()". This
should make it much easier to prove correctness with respect to
accidentally calling functions that depend upon the caller's identity
after identity has already been shed by Binder.clearCallingIdentity().
Change-Id: I446169aee8fb2fde26ac6d04b479b40253782acb
Prevent overflow in LocationRequest.setExpireIn(), for example,
when we pass in Long.MAX_VALUE.
Bug: 7047435
Change-Id: Ie56928a59fb387173fbd3887c0ef9aede00f8152
This takes the easy way around notifying the correct users
about GPS state transitions by notifying ALL the users(!).
I've also laid groundwork for proper multiuser support in
LocationManager and did a tiny bit of cleanup in
GpsNetInitiatedHandler while I was looking at notifications.
Bug: 7213552
Change-Id: I2d6dc65c459e55d110ac0f5f79ae7a87ad638ede
FusionEngine now attaches a secondary location that has never seen
GPS data to its result. LocationFudger uses the GPS-less location so
that COARSE apps never see data from the GPS provider.
When the previous location is updated, the previous GPS-less location
is carried over if the location update was GPS-only.
Additionally, apps without FINE permission are not notified when GPS
location changes, and any attempt to use GPS_PROVIDER without FINE
permission is met by a stern SecurityException.
Bug: 7153659
Change-Id: I12f26725782892038ce1133561e1908d91378a4a
