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
These have been created to reduce the size and complexity
of frameworks/base.
mms-common was created by moving all of
frameworks/base/core/java/com/google/android/mms
to:
frameworks/opt/mms
telephony-common was created by moving some of
frameworks/base/telephony
to:
frameworks/opt/telephony
Change-Id: If6cb3c6ff952767fc10210f923dc0e4b343cd4ad
Hot TTTF is about 5 seconds, so don't cycle the GPS hardware until
the interval is 10 seconds.
Also add some more dumpsys logging.
Bug: 6367964
Change-Id: I39402fc61f34458a1639c8814610a02606a8eb79
This patch fixes the update of the extras Bundle in the Location object
each time the platform derives a new GPS location and passes it to
listening applications via LocationListener.onLocationChanged().
Sometime between Android 1.6 and 2.1 a bug was introduced that stopped
any extras calculated by the platform from being added into the Location
object, which means they were never passed up to any LocationListeners
for the GPS Provider. This manifested as an issue where the number of
satellites used to derive a fix always reported “0” when retrieved from
Location.getExtras() (Issue 4810 on the Android Issues page -
http://code.google.com/p/android/issues/detail?id=4810).
Sample code to be used within
LocationListener.onLocationChanged(Location location) which demonstrates
this problem:
Bundle extras = location.getExtras();
Int numSats = extras.getInt("satellites"); //This always reports “0”
//post 1.5, although in 1.5
//it properly reported the
//number of satellites used
//to derive this location
The “satellites” extra key/value pair for Locations is defined in
http://developer.android.com/reference/android/location/Location.html#getExtras()
This patch modifies GPSLocationProvider.java to properly update the
Location object with the extras Bundle before the Location object is
passed to any listening applications, and therefore the number of
satellites used to derive a fix can now be retrieved properly through
location.getExtras() (as shown in sample code above). Therefore, this
patch fixes Issue 4810.
Change-Id: Ief21056a3623269bb3149ec78ab92738a234f57f
Signed-off-by: Sean Barbeau <sjbarbeau@gmail.com>
This is especially important when AGPS is disabled
Bug: 5355661
Change-Id: I072dbe1ddf43aa24c8fc39b750040504a1633c53
Signed-off-by: Mike Lockwood <lockwood@android.com>
GPS Provider Service changes
GPS engine needs to receive network state changes from Android fw.
Added db query for the current APN, also added a new parameter
between JNI / HAL to the new method in AGpsRilInterface struct
for gps engine to receive APN from GPSLocationService
Conflicts:
services/java/com/android/server/location/GpsLocationProvider.java
Change-Id: I33c45027f1571493d3525324f62d199517c4960c
Signed-off-by: Mike Lockwood <lockwood@android.com>
GPS engine needs to receive network state changes from Android fw.
Added db query for the current APN, also added a new parameter
between JNI / HAL to the new method in AGpsRilInterface struct
for gps engine to receive APN from GPSLocationService
Change-Id: I62e35c948d2ac1961771d1a10581a3b8e695c05a
Signed-off-by: Mike Lockwood <lockwood@android.com>
Uses NTP server and timeout from secure settings, or fallback to
defaults in resources. Update various system services to use cached
NTP time when fresh enough, or force updates as needed.
Bug: 4517273
Change-Id: Ie1c4c4883836013d02ca0bbd850cf8949f93b34b
In the CDMA case we do not get a valid APN on a data connection request
to the connectivity manager. A fix is put in so that even if we get a
null APN we populate this field before we call native_agps_data_conn_open()
method to avoid a run time exception.
Change-Id: I134ead5d8b177fced9b14756c6bd8199a2b9c35d
4 hours is excessive, and we want to save bandwidth on the NTP servers
Change-Id: Ic5ac4f4a8e62167206f3f620ea51635a2ea771d6
Signed-off-by: Mike Lockwood <lockwood@android.com>
Add support for encoding and decoding SMS 7 bit user data using the
national language shift tables defined in 3GPP TS 23.038 (GSM/UMTS only),
including the new tables added in Release 9 for Indic languages.
Decoding is always supported, but encoding is only enabled for the
specific language tables added to the new integer array resources
"config_sms_enabled_single_shift_tables" and
"config_sms_enabled_locking_shift_tables" defined in
frameworks/base/core/res/res/values/config.xml. The default empty arrays
should be overridden in an OEM overlay for the specific nationalities where
SMS national language shift table encoding is allowed/mandated (e.g. Turkey).
GsmAlphabet.countGsmSeptets() will try to find the most efficient encoding
among all combinations of enabled locking shift and single shift tables.
If no 7 bit encoding is possible, 16 bit UCS-2 encoding will be used.
This change also fixes a bug in the decoder: when an escape septet
is followed by a septet with no entry in the extension (single shift)
table, TS 23.038 Table 6.2.1.1 states that the MS shall display
the character in the main GSM 7 bit default alphabet table, or the
active national language locking shift table. Previously, we were
decoding this sequence as a space character. Two consecutive escape
septets will continue to decode as a space character, according to
Note 1 of table 6.2.1.1.
Change-Id: I4dab3f0ffe39f3df2064ed93c9c05f26e274d18b
Between Froyo and Gingerbread we disabled scheduling an XTRA data download
at boot because the Qualcomm engineers thought it should not be necessary.
However, some users noticed a GPS performance degradation after receiving
their Gingerbread update, and some reported forcing an XTRA download cleared
up the problem. This change restores the Froyo behavior of downloading
XTRA data after boot.
Bug: 3509901
Change-Id: I5a52201a2b24ce4a5d3ddb1f86340e3d5387f603
Signed-off-by: Mike Lockwood <lockwood@android.com>
Adding changes to be able to have access to missing data to SUPL
(celld, imsi, WAP_PUSH and SMS)
Change-Id: I0207f7f7ea6595ed3fd7021cb732feddf52e4cf9
Signed-off-by: Mike Lockwood <lockwood@android.com>
If handleUpdateNetworkState() is called before
ConnectivityManager.startUsingNetworkFeature() returns, then we will not
call native_agps_data_conn_open() to inform the GPS that the APN is up.
So we now set mAGpsDataConnectionState to AGPS_DATA_CONNECTION_OPENING
before calling ConnectivityManager.startUsingNetworkFeature() to avoid
this problem.
Change-Id: I5e1597d6494dc8ab68e608911c546a7a04f2ea07
Signed-off-by: Mike Lockwood <lockwood@android.com>
This fixes a problem where applications could ask the location
manager to do very heavy-weight things (like... say... update
location every minute), which would get accounted against the
system instead of the application because ultimately it is the
system making the heavy calls (wake locks, etc).
To solve this, we introduce a new class WorkSource representing
the source of some work. Wake locks and Wifi locks allow you
to set the source to use (but only if you are system code and thus
can get the permission to do so), which is what will be reported
to the battery stats until the actual caller.
For the initial implementation, the location manager keeps track
of all clients requesting periodic updates, and tells its providers
about them as a WorkSource param when setting their min update time.
The network location provider uses this to set the source on the
wake and wifi locks it acquires, when doing work because of the
update period.
This should also be used elsewhere, such as in the GPS provider,
but this is a good start.
Change-Id: I2b6ffafad9e90ecf15d7c502e2db675fd52ae3cf
XTRA data downloads are now strictly on demand from the GPS engine.
Also fix typo in handleDownloadXtraData()
Change-Id: Ied1a6e2e62134add4d965326aae909c86f834682
Signed-off-by: Mike Lockwood <lockwood@android.com>
MS-Assisted support should not be required for using MS-Based mode.
Change-Id: Ia6ee219674de3e9cc13190b753f8776305a4fa90
Signed-off-by: Mike Lockwood <lockwood@android.com>
Rather than polling for events from the native code in an event thread,
we now require the GPS HAL libraries to call our callbacks from a thread
that is registered with the JVM to call directly into Java.
This eliminates a thread from our code and removes one step in the chain
of message passing from the GPS to the Location Manager client.
Change-Id: I2745a157690310ba9a699a8369f54a7366c6b1ba
Signed-off-by: Mike Lockwood <lockwood@android.com>
Use MS-Assisted mode for single shot GPS fixes if it is supported.
Add finer grained control over accuracy to the android.location.Criteria class
and location criteria logic from LocationManager to LocationManagerService
Change-Id: I156b1f6c6a45d255c87ff917cf3e9726a6d7a75b
Signed-off-by: Mike Lockwood <lockwood@android.com>
Merge commit 'f4dffd8a45386b5a5f0e6de4f30facc9eaac4001' into kraken
* commit 'f4dffd8a45386b5a5f0e6de4f30facc9eaac4001':
GpsLocationProvider: Store new Location before onGpsStatusChanged is sent
Telephony: Add PUK MMI code support for CDMA RUIM phones
Type Zero Sms should not be displayed/stored/notified.
Now we stop after one fix rather than waiting for 10 when requesting occasional
fixes to conserve power.
Change-Id: Ic420f2d20780db983fc4db22246e0a486eecc58e
Signed-off-by: Mike Lockwood <lockwood@android.com>
This fixes problems with wakelock permissions introduced in an earlier change.
Change-Id: If0f4761ac27525d1eece0613c96be62f9e370a14
Signed-off-by: Mike Lockwood <lockwood@android.com>
Rather than holding a wake lock the entire time the GPS is active, we now
hold it only when messages are pending for GpsLocationProvider's Handler
and rely on the lower level implementation holding a wake lock when calling
into the provider.
Signed-off-by: Mike Lockwood <lockwood@android.com>
