Remove the ProximityAlerts update Receiver when the last ProximityAlert expires.
Fixes issue 6900.
Change-Id: Ida1970c084e71df47b204c64986a065cb75d0c13
LocationManagerService was just checking if the string of (comma-separated)
Location Providers contained the provider we were interested in. This works
fine in normal cases, but breaks if we add a provider such as test_network.
Enabling test_network causes LocationManagerService to think that the network
provider is also enabled.
The code in Settings.Secure.isLocationProviderEnabled() checks for the commas
in the string as well, to make sure that a provider name which is a substring
of another provider name won't cause problems. It also centralizes the code
which reads the string.
Signed-off-by: Brad Larson <brad.larson@garmin.com>
Change-Id: I00dfe7c2b09739ed4c8ed07c6167e409b0bf7d13
In LocationManagerService if a LocationListener is removed while it has
a pending broadcast the wake lock held while pending broadcasts are
outstanding do not get cleared properly.
There are 2 cases of this race that are fixed:
1. locationCallbackFinished was changed to check the mReceivers HashMap
directly instead of calling getReceiver. getReceiver would add the
ILocationListener as a new Receiver if it did not exist which caused
a receiver that was removed when it still had a broadcast pending to
be added back in a bad state when the pending broadcast completed.
2. removeUpdatesLocked was changed to decrement the pending broadcasts
when a Receiver is removed that has pending broadcasts.
Added a screen to the setup wizard, after login, to ask user to
opt-in for location collection.
Added a dialog to Settings when user turns on Network location.
Fixed a security permission issue in LocationManagerService related
to this change.
BUG=1752566
Automated import of CL 144256
