Is there any way to force proximity alerts to use only network provider?
I'm worried about battery drain.
Forcing proximity alerts to take more than 4 minutes to be fired would be a good solution too.
Any ideas?
A brilliant question,sadly though I dont think that would be possible , just had a look over the documentation as well , take note of this "Before API version 17, this method could be used with ACCESS_FINE_LOCATION or ACCESS_COARSE_LOCATION. From API version 17 and onward, this method requires ACCESS_FINE_LOCATION permission." So they are making it compulsory to pass in GPS Permission.
So currently there is no way of forcing it to use any particular provider.
There is a Enhancement Feature requested for the same , go ahead and star it to make Google implement it.
Link to Enhancement : https://code.google.com/p/android/issues/detail?id=33151
If your project does not require gps for other features you can set the SDK target to version 16:
android:targetSdkVersion="16"
and require just the coarse location:
<uses-permission android:name="android.permission.ACCESS_COARSE_LOCATION" />
so the proximity alerts will not check for the gps signal.
My point is that is the user keeps the GPS ON is conscius of the drain, remember that this is a toggle, you should consider it in the requirement of the app.
Related
I am working on a Android application that uses bluetooth and I want to use the new Android 12 Bluetooth_SCAN and CONNECT permissions to remove the need for location permission using
<uses-permission android:name="android.permission.BLUETOOTH_SCAN" android:usesPermissionFlags="neverForLocation" />
As shown in the bluetooth documentation
The problem is, the application has one main feature and one optional. The main feature works fine with these permissions.
However, the optional feature uses beacon scanning. These beacons are filtered out from scanning by the Android OS when using the "neverForLocation" flag.
Note: If you include neverForLocation in your android:usesPermissionFlags, some BLE beacons are filtered from the scan results.
The beacons appear during scanning if the flag is removed from the manifest permission.
However, if i remove this flag from the manifest, then even users that don't want to use this feature have to provide the location permission, or else the normal BLEScan returns nothing. This is something that i would like to avoid giving the fact that the whole reason for these new permission is to avoid asking the user for location.
Is there a way to provide this flag when making the actual runtime request to the OS for the permission instead of it being declared in the manifest? Any help or idea is appreciated.
I have an app that requests the user's location every 5 minutes and then maps their path.
To my understanding, with Android 11, Google changed how background location requests are handled. I have several questions about how this will affect my app:
Can I continue getting background location updates every 5 minutes?
If not, is there anything I can do to keep doing so?
When a new user downloads my app, what is the process of requesting background location permissions starting with Android 11?
I'm reading here that in Android 11:
On Android 11 (API level 30) and higher, however, the system dialog doesn't include the Allow all the time option. Instead, users must enable background location on a settings page, as shown in figure 3.
Does this mean that unless the user selects "Allow all the time", I won't ever be able to get the user's location in the background?
Thank you!
declare the ACCESS_BACKGROUND_LOCATION permission in your app
<uses-permission android:name="android.permission.ACCESS_BACKGROUND_LOCATION" />
In order to use the Geofence API the user has to give the app ACCESS_FINE_LOCATION. This location is considered to be dangerous and can be revoked at any time; once this permission is revoked, the app can not request the geofence updates.
How does ACCESS_BACKGROUND_LOCATION permission fit in this picture? We know for sure that this permission is also dangerous and can be revoked at any time. Does it mean that if we want to register some IntentService to be invoked every time the geofence change occurs, we also have to make sure the user has provided ACCESS_BACKGROUND_LOCATION permission? Or do we need to use this permission only if we attempt to get a current location in our own background Service/BroadcastReceiver?
The reason I'm asking this question is that the documentation seems to be a bit vague at this point: the documentation describing the Q Developer Preview mentions that geofencing is one of the use cases for the background location retrieval, while the Geofencing API page does not mention ACCESS_BACKGROUND_LOCATION among its requirements.
Geofencing API Documentation is now updated and we need to define ACCESS_BACKGROUND_LOCATION to monitor Geofences if we target Android Q
From the doc:
To use geofencing, your app must request ACCESS_FINE_LOCATION. If your app targets Android 10 (API level 29) or higher, your app must also request ACCESS_BACKGROUND_LOCATION.
My guess the section "Re-register geofences only when required":
Registered geofences are kept in the com.google.process.location process owned by the com.google.android.gms package.
will be that it is not really needed, as com.google.process.location should be the one getting the location data (so the one needing to request the ACCESS_BACKGROUND_LOCATION permission).
That being said, following this logic ACCESS_FINE_LOCATION permission should neither be needed. The fact that it is needed may be because of two reasons (I don't know the real reason):
that either when registering the geofence or when receiving a notification location is checked,
or that this permission is checked by Google Play Services to forbid an app to circumvent the lack of location permission by using Play Services as a proxy process to obtain the information.
For me, the second assumption makes more sense, meaning that even when technically will not be needed by the app (the process getting the location is Play Service), it is required for privacy/security reasons.
Following this logic, Google should (will?) also enforce the ACCESS_BACKGROUND_LOCATION, both to ensure user's privacy/security and to reduce battery consumption.
On beta 4, adding a geofence when ACCESS_BACKGROUND_LOCATION is not granted, even when the app is fully in the foreground, fails with status code 13 ("error").
You need Android 10 API Level 29+ to use ACCES_BACKGROUND_LOCATION
I would like to replace the default GPS location provider on android phones with my own coordinate source.
Is there any layer/API/library/provider that would allow to be replaced with my signal provider instead of the built-in hardware GPS, or read from an external plugin? It should allow all apps that rely on the GPS service to receive my signal instead of GPS.
Ideally, the replacement should still be able to access the GPS signal (for comparison/correction or to toggle between the two providers).
I am thinking for example of implementing my own LocationManager, and registering it in the system (as optional or default), if that is possible. But at this stage, I am still trying to find out what is possible and suitable.
Thank you for any pointers.
Replacing the "default" is not allowed at this time and the only work around is to create a mock provider. First you must set the security permission:
<uses-permission android:name="android.permission.ACCESS_MOCK_LOCATION" />
Second, set your code to use the mock provider which you will create. There is some excellent information about how to accomplish this here: http://diffract.me/2009/11/android-location-provider-mock/
I'm only in the process of reading about the android SDK at the moment. However my understanding is that you would provide an implementation of a GPS_PROVIDER intent.
Any application can then divert to using the user preferred GPS_PROVIDER intent.
See:
http://developer.android.com/guide/topics/intents/intents-filters.html
I'm pretty sure the default location providers for fine location are baked into Android.
Given that Google are becoming more conscious about potential misuse and abuse of system resources by applications, i'd say that's a good thing. Otherwise people would be able to trick the user into thinking they're somewhere else, using the trustworthy sounding 'Use GPS satellites' setting.
The only way I can see that you can add a location provider is via android.location.LocationManager.addTestProvider(......), which requires the permission ACCESS_MOCK_LOCATION. Now, this method and permission are both documented as being for "testing" purposes. I can't find a source that specifically says that that permission is not granted for market release apps, but I strongly suspect that to be the case.
I'm using this code to find my current location. But if I'm at home it can't locate me. But google maps and another similar applications can locate me although I'm at home. What is difference?
If you're using the GPS_Provider, make sure that you have the following permission in your app manifest:
<uses-permission android:name="android.permission.ACCESS_FINE_LOCATION"/>
But usually GPS only works with a free sky (not indoors very well). Therefore while Google Maps might show the last known location, maybe your app doesn't. So you might want to initially call getLastKnowLocation initially to set the initial marker.
Even though GPS cannot get a fix, you could still show the last known location known to the device, i.e. when you were outdoors last time.
Alternatively or additionally to GPS_Provider, you could also use the
LocationManager.NETWORK_PROVIDER
instead,which is based on Wifi and/or GMS, is less accurate than GPS but works indoors.
For this, you need the permission
<uses-permission android:name="android.permission.ACCESS_COARSE_LOCATION"/>
in your manifest.