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
Merged-In: I8285daa8530260251ecad6f3f38f98e263629ca7
Change-Id: I626caf7c1fe46c5ab1f39c2895b42a34319f771a
-Add a new app ops helper to make testing easier.
-Consolidate app identity within CallerIdentity class.
-Remove location age restriction for coarse locations, was a bit
arbitrary.
-Remove listener identifiers from LM. These were not being properly
propagated and add a lot of binder overhead with what appears to be
little benefit since we have featureIds, which contain much better
information.
-Remove appops checks from some GNSS APIs that shouldn't require it.
-Move location fudger into location providers and reset them after mock
providers are used so that offset information cannot be leaked.
Bug: 149375028
Test: presubmits + manual
(cherry picked from commit 6033344baa)
Change-Id: I18e2cf3c39836f31d28180e1a4613df4ad675ab7
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
Existing annotations in libcore/ and frameworks/ will deleted after the migration. This also means that any java library that compiles @UnsupportedAppUsage requires a direct dependency on "unsupportedappusage" java_library.
Bug: 145132366
Test: m && diff unsupportedappusage_index.csv
Change-Id: I4bc8c9482e4bb1af21363f951affff7ee3fefeab
This reverts commit cef1e80327.
AND
Fixing typo that fix a failure b/127312065
Test: atest CtsGraphicsTestCases:android.graphics.cts.BitmapFactoryTest#testDng -- --abi x86
Bug: 127312065
Change-Id: I96657adb54c33ceb92f25896bb5b6bdaa19e902c
In this CL, I pushed
location.setElapsedRealtimeNanos(SystemClock.elapsedRealtimeNanos()); (from Java)
Test: This patchset include a CTS test for location.java changes.
Bug: 121353225
Change-Id: I606e23175e2fb6405660ed032b41c9996f1ba0c8
If they were null, then the Parcelable would fail to work.
Bug: 126726802
Test: manual
Change-Id: I7929ffa2f20e5de1c8e68e8263cca99496e9d014
Exempt-From-Owner-Approval: Trivial API annotations
Members modified herein are suspected to be false positives: i.e. things
that were added to the greylist in P, but subsequent data analysis
suggests that they are not, in fact, used after all.
Add a maxTargetSdk=P to these APIs. This is lower-risk that simply
removing these things from the greylist, as none of out data sources are
perfect nor complete.
For APIs that are not supported yet by annotations, move them to
hiddenapi-greylist-max-p.txt instead which has the same effect.
Exempted-From-Owner-Approval: Automatic changes to the codebase
affecting only @UnsupportedAppUsage annotations, themselves added
without requiring owners approval earlier.
Bug: 115609023
Test: m
Change-Id: I020a9c09672ebcae64c5357abc4993e07e744687
For packages:
android.location
This is an automatically generated CL. See go/UnsupportedAppUsage
for more details.
Exempted-From-Owner-Approval: Mechanical changes to the codebase
which have been approved by Android API council and announced on
android-eng@
Bug: 110868826
Test: m
Change-Id: I2e49951f49072866906ecb8fba133ff16293e65a
Added "Tow Known" as a possible gnss measurement state. As well added Automatic Gain Control (AGC)
to allow jammer detection. Also added the GNSS carrier frequeny to SV status. Also added vertical
GPS position uncertainty, speed uncertainty and bearing uncertainty. Also propagate locaton new
fields to geofence engine.
Test: Existing unit tests still pass.
Change-Id: I472b2fd2516cb7614877dea4bb054a34f50844dc
-Use bitmask for has*** methods.
-Use ThreadLocal for caching intermediate computations
rather than preallocating memory in every Location
Change-Id: If2fa17bfd59511ec0b809f4b7d7cd8028360c340
Minute values in the range [0, 59] are valid if seconds are
present. If seconds are not present then minute values are
valid in the range [0, <60]
Second values are valid in the range [0, <60]
Examples:
50:59:59.99999 is valid
50:59.99999 is valid
50:59.1:1 is not valid
Patch taken from Motorola: partner gerrit 137210
Bug: 17958582
Change-Id: I0d1265534092157883af564119f723984362d436
Issues: 2667 and 2668
The Location.convert() methods do not invert each other as might be
expected. Changing this would introduce breaking changes, so I've
updated the javadocs to make this clearer.
Bug: 13280976
Change-Id: If4bd3c83d5fb67915450849ca471aabc27544dac
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
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
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
