| Commit message (Collapse) | Author | Age | Files | Lines |
|\
| |
| |
| |
| | |
* commit '768d9e1a72ceee7d4a5f608776b87b62d6ce4a04':
Correct executable bit for source files
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The Settings.Secure value locationPackagePrefixBlacklist and
locationPackagePrefixWhitelist contains comma seperated package-name
prefixes.
Location & geo-fence updates are silently dropped if the receiving
package name has a prefix on the blacklist. Status updates are
not affected. All other API's work as before.
A content observer is used so run-time updates to the blacklist
apply immediately. There is both a blacklist and a whitelist.
The blacklist applies first, and then exemptions are allowed
from the whitelist. In other words, if your package name prefix
matches both the black AND white list, then it is allowed.
Change-Id: I4ea2ad56fa6bd75d32151bc250ac25c26a5777c4
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
|/ /
| |
| |
| |
| |
| | |
and clarify horizontal geofencing
Change-Id: I8ff264d7a12c8ec3c79854e008aeeb5f922ad459
|
| |
| |
| |
| |
| | |
Bug: 7172696
Change-Id: Ib1a104ee4a97c51996200b8d456face66178115f
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
| |
| |
| |
| | |
Change-Id: Ie38952bbaace080e81e41e61350cda172951d548
|
| |
| |
| |
| | |
Change-Id: Iaebd4cf00c8a33bcf4fc74eaa1dfec9675032826
|
|\ \
| | |
| | |
| | | |
elapsedRealtimeNanos()"" into jb-mr1-dev
|
| | |
| | |
| | |
| | |
| | |
| | | |
This reverts commit 2f6d8829524dfca3a77e9a57c3b9c3862209877d
Change-Id: Id5af767a09fc319127c4ebef837c5b7a7f75cb01
|
|\ \ \
| |/ /
| | |
| | | |
elapsedRealtimeNanos()" into jb-mr1-dev
|
| | |
| | |
| | |
| | | |
Change-Id: I71c24ea10093ece07a0780e97bc641ff548c1a44
|
|\ \ \
| |/ /
|/| | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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
|
|/ /
| |
| |
| |
| |
| | |
Bug #7173109
Change-Id: Ia2f4a5b6255dae7ace4702f7d66ec30a077c9c79
|
| |
| |
| |
| |
| | |
Bug: 7153226
Change-Id: I49236379e739fcda66bbc9a31cfdca9a87122aec
|
| |
| |
| |
| | |
Change-Id: I5859ee2c9db5745b0a3bc8abfa8f08728fb25059
|
| |
| |
| |
| |
| |
| | |
Age was a bad idea, since it depends when toString() was called
Change-Id: Ica0b6bfa9a93b5a452ba3def5fbb2b0a0194c401
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
I had to re-do this change for MR1 because LocationManagerService changed
so much. Here is the original change description:
Add package-name-prefix blacklist for location updates.
The Settings.Secure value locationPackagePrefixBlacklist and
locationPackagePrefixWhitelist contains comma seperated package-name
prefixes.
Location & geo-fence updates are silently dropped if the receiving
package name has a prefix on the blacklist. Status updates are
not affected. All other API's work as before.
A content observer is used so run-time updates to the blacklist
apply immediately. There is both a blacklist and a whitelist.
The blacklist applies first, and then exemptions are allowed
from the whitelist. In other words, if your package name prefix
matches both the black AND white list, then it is allowed.
Bug: 6986553
Change-Id: I1e151e08bd7143e47db005bc3fe9795076398df7
|
| |
| |
| |
| | |
Change-Id: I222d61811c88272e84a85512623210c0238337e5
|
| |
| |
| |
| | |
Change-Id: If15024ee88421c07ba3a174747774fc451fd002e
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Fix a couple of bugs, and modify the behavior of the random offset.
The random offset now slowly changes over time, to mitigate against
applications averaging out the offset over time while at a
grid boundary.
Change-Id: Iecffff29145b8c2b30d1eca1662cf9d3e8cff756
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Marshall LocationRequest array correctly.
Observe reportLocation from FusionEngine.
Actually deliver the setRequest message to fusion engine.
Change-Id: Iff64596fdd42f9fb06e563591dda9fbe0241533a
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This was never a public API, so we don't need to follow
an orderly deprecation. And it breaks a CTS test:
cts/tests/tests/location/src/android/location/cts/LocationManagerTest.java:521: reference to getLastKnownLocation is ambiguous, both method getLastKnownLocation(java.lang.String) in android.location.LocationManager and method getLastKnownLocation(android.location.Criteria) in android.location.LocationManager match
mManager.getLastKnownLocation(null);
^
Change-Id: I503267e4fa577ce4bf684239da777f11b0e511f5
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Themes: Fused Location, Geofencing, LocationRequest.
API changes
o Fused location is always returned when asking for location by Criteria.
o Fused location is never returned as a LocationProvider object, nor returned
as a provider String. This wouldn't make sense because the current API
design assumes that LocationProvider's have fixed properties (accuracy, power
etc).
o The fused location engine will tune itself based on the criteria passed
by applications.
o Deprecate LocationProvider. Apps should use fused location (via Criteria
class), instead of enumerating through LocationProvider objects. It is
also over-engineered: designed for a world with a plethora of location
providers that never materialized.
o The Criteria class is also over-engineered, with many methods that aren't
currently used, but for now we won't deprecate them since they may have
value in the future. It is now used to tune the fused location engine.
o Deprecate getBestProvider() and getProvider().
o Add getLastKnownLocation(Criteria), so we can return last known
fused locations.
o Apps with only ACCESS_COARSE_LOCATION _can_ now use the GPS, but the location
they receive will be fudged to a 1km radius. They can also use NETWORK
and fused locatoins, which are fudged in the same way if necessary.
o Totally deprecate Criteria, in favor of LocationRequest.
Criteria was designed to map QOS to a location provider. What we
really need is to map QOS to _locations_.
The death knell was the conflicting ACCURACY_ constants on
Criteria, with values 1, 2, 3, 1, 2. Yes not a typo.
o Totally deprecate LocationProvider.
o Deprecate test/mock provider support. They require a named provider,
which is a concept we are moving away from. We do not yet have a
replacement, but I think its ok to deprecate since you also
need to have 'allow mock locations' checked in developer settings.
They will continue to work.
o Deprecate event codes associated with provider status. The fused
provider is _always_ available.
o Introduce Geofence data object to provide an easier path fowards
for polygons etc.
Implementation changes
o Fused implementation: incoming (GPS and NLP) location fixes are given
a weight, that exponentially decays with respect to age and accuracy.
The half-life of age is ~60 seconds, and the half-life of accuracy is
~20 meters. The fixes are weighted and combined to output a fused
location.
o Move Fused Location impl into
frameworks/base/packages/FusedLocation
o Refactor Fused Location behind the IProvider AIDL interface. This allow us
to distribute newer versions of Fused Location in a new APK, at run-time.
o Introduce ServiceWatcher.java, to refactor code used for run-time upgrades of
Fused Location, and the NLP.
o Fused Location is by default run in the system server (but can be moved to
any process or pacakge, even at run-time).
o Plumb the Criteria requirements through to the Fused Location provider via
ILocation.sendExtraCommand(). I re-used this interface to avoid modifying the
ILocation interface, which would have broken run-time upgradability of the
NLP.
o Switch the geofence manager to using fused location.
o Clean up 'adb shell dumpsys location' output.
o Introduce config_locationProviderPackageNames and
config_overlay_locationProviderPackageNames to configure the default
and overlay package names for Geocoder, NLP and FLP.
o Lots of misc cleanup.
o Improve location fudging. Apply random vector then quantize.
o Hide internal POJO's from clients of com.android.location.provider.jar
(NLP and FLP). Introduce wrappers ProviderRequestUnbundled and
ProviderPropertiesUnbundled.
o Introduce ProviderProperties to collapse all the provider accuracy/
bearing/altitude/power plumbing (that is deprecated anyway).
o DELETE lots of code: DummyLocationProvider,
o Rename the (internal) LocationProvider to LocationProviderBase.
o Plumb pid, uid and packageName throughout
LocationManagerService#Receiver to support future features.
TODO: The FLP and Geofencer have a lot of room to be more intelligent
TODO: Documentation
TODO: test test test
Change-Id: Iacefd2f176ed40ce1e23b090a164792aa8819c55
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Add getElapsedRealtimeNano():
Currently Location just has getTime() and setTime() based on UTC time.
This is entirely unreliable since it is not guaranteed monotonic.
There is a lot of code that compares fix age based on deltas -
and it is all broken in the case of a system clock change. System
clock can change when switching cellular networks (and in some
cases when switching towers).
Document the meaning of getAccuracy():
It is the horizontal, 95% confidence radius.
Make some fields mandatory if they are reported by a LocationProvider:
All Locations returned by a LocationProvider must include at the
minimum a lat, long, timestamps, and accuracy. This is necessary
to perform fused location. There are no public API's for applications
to feed locations into a location provider so this should not cause
any breakage.
If a LocationProvider does not fill in enough fields on a Location
object then it is dropped, and logged.
Bug: 4305998
Change-Id: I7df77125d8a64e174d7bc8c2708661b4f33461ea
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously any geofence (proximity alert) would turn the GPS on at full rate.
Now, we modify the GPS interval with the distance to the nearest geofence.
A speed of 100m/s is assumed to calculate the next GPS update.
Also
o Major refactor of geofencing code, to make it easier to continue to improve.
o Discard proximity alerts when an app is removed.
o Misc cleanup of nearby code. There are other upcoming changes
that make this a good time for some house-keeping.
TODO:
The new geofencing heuristics are much better than before, but still
relatively naive. The next steps could be:
- Improve boundary detection
- Improve update thottling for large geofences
- Consider velocity when throttling
Change-Id: Ie6e23d2cb2b931eba5d2a2fc759543bb96e2f7d0
|
|
|
|
| |
Change-Id: I89d9fd64dc22c90680bb05415cc966c255165af9
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There is a long history in Android, on both GED and non GED devices
of GPS providers ignoring the minTime parameter making location updates
every second. The problem is usually poor GPS drivers that claim to
do scheduling but then do not.
By making the minTime parameter strict (instead of a hint) we can add
a CTS test to ensure that udpates to not occur too frequently. I believe
this is the desired behavior from apps. If apps want to take advantage
of more frequent updates when another application asks for those updates
then it can use the passive provider.
The CTS test for GPS has already been submitted (as part of CTS Verifier).
Bug: 6424983
Change-Id: I163b9e44ea7ab71530b86fc2282614e0150e90f1
|
|
|
|
| |
Change-Id: I1b43414aaec8ea217b39a0d780c80a25409d0991
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
-------------------------------------------------------
MCC detection fixes for CountryDetector
- Don't get and cache phone tpe at the initialization time. At this point
TelephonyManager is probably not ready yet.
- Refresh MCC whenever we get the service state changed callback, even when
the state hasn't actually changed, in order to make sure we get refresh
country properly when MCC changes.
- Also remove the initialization of mPhoneStateListener, which prevented us from
registering phone state listener properly.
- Also fix tests which were already failing.
Bug 5670680
-------------------------------------------------------
Add logging to country detector logic
This is for debugging purposes to verify the effects of
change Id45abeba1b1e843053ac2c946861b439ca568de4.
Bug: 5670680
Change-Id: I238d953484e2c8135f7dac70fce8662c8300a286
|
|
|
|
|
|
|
|
| |
These log statements were dead code. That isn't much of a problem,
except that the 'e.getMessage()' that was being logged could be null,
and that would cause a real problem.
Change-Id: I8573bc687a7eda73782bd028e8ddc048a1954dc5
|
|\
| |
| |
| |
| |
| |
| | |
FLAG_AUTO_CANCEL flag for multiple supl notifications."
* commit 'e0009bb0b700dcfeba3ff77f8c33113499674432':
Add FLAG_AUTO_CANCEL flag for multiple supl notifications.
|
| |\
| | |
| | |
| | |
| | |
| | |
| | | |
multiple supl notifications."
* commit '98395483e4309f7b92348136491575861008b3c0':
Add FLAG_AUTO_CANCEL flag for multiple supl notifications.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Added FLAG_AUTO_CANCEL to notification flags in GpsNetInitiatedHandler.java.
This is done to clear consecutive notifications in UI
Change-Id: I84be36af0b556f43ffd7d51ac04ff12300090ca5
Signed-off-by: Anshuman Pandey <anshuman.pandey@stericsson.com>
Signed-off-by: Christian Bejram <christian.bejram@stericsson.com>
|
| | |
| | |
| | |
| | |
| | |
| | | |
It was saying the same thing as requestLocationUpdates(), but it only provides a single update.
Change-Id: I0a0f612104a946b7db96928505bb95673377a335
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Previously external/libphonenumber accepted lower case
country codes (e.g. "us") but now it doesn't for performance reason.
Actually ISO 3166-1 doesn't allow lower cases, so we should not rely
on them.
Need to fix unit tests for PhoneNumberUtils, as it implicitly
relies on the previous behavior.
See also I3a3e6db84ed0d24290b1be19651fa9a82de4cc39
Bug: 4941319
Change-Id: If16f6531f274a0faf5e28724854409ca9b00a669
|
| | |
| | |
| | |
| | |
| | | |
Bug: 4345419
Change-Id: Ia3e071b97c6971538ea994fdee6029db928201d6
|
|/ /
| |
| |
| |
| |
| | |
It was saying the same thing as requestLocationUpdates(), but it only provides a single update.
Change-Id: Ib677d40e050a82332df539a823cc677de1fcb4fd
|
|\ \
| |/
| |
| |
| |
| |
| |
| |
| |
| |
| | |
* commit 'ce57a7f35344e76689d30f45964d1e37b78280cb':
GpsLocationProvider: Clean up HAL initialization/cleanup sequence
Fixed GSM encoded network initiated position request
Ensuring thread-safe usage of DateFormat.
Fixing infinite loop for zero duration.
Fix for an infinite loop while scrolling lists.
WAPPushManager, WAP Push over SMS message handler
Add --non-constant-id to aapt.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
GSM encoded network initiated position requests were previously
not correctly decoded. The GSM encoded string was decoded as
ASCII but not all characters are encoded in the same way for
GSM and ASCII. These characters was not displayed.
Besides that, when the number of characters was evenly divided
by 8 the last character was lost. This is also corrected.
Change-Id: Ic70b7c28bbba1f2936a9cc99e78f8002cc5c8761
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Notably, this removes exessive info about resources
from the content package, because it's not a good location
and the info is avilable in the dev guide, but also
added some of the info to the Resources class description.
Change-Id: Ie78af26c9cec66314deb98e53078f48e16c08e70
|
|\ \
| |/
| |
| | |
Change-Id: Ia9f4ea86b8554ff04a3aa6b9e065239ae73740e7
|
| |\
| | |
| | |
| | | |
Change-Id: I0ce429afeb26184f075b4ed326fc4e1c0833e905
|