The first point in this document says that Background Location permission is required if the foreground location service is started while the app is in foreground starting Android 11.
https://developer.android.com/guide/components/foreground-services#bg-access-restrictions
My use case is that a user taps on a button to start location tracking. Tapping that button starts a foreground service which puts a notification. Now, I want the app to continue tracking even after backgrounding.
Until Android 10, background location permission wasn't required to accomplish this.
My question is that to support Android 11, do I need to start requesting background permission as well? Also, do I need to do the same for Android 10? Not finding any other reference on the internet to verify this. please let me know your thoughts.
According to the definition of background work
An app is considered to be running in the background as long as each of the following conditions are satisfied:
None of the app's activities are currently visible to the user.
The app isn't running any foreground services that started while an activity from the app was visible to the user.
Otherwise, the app is considered to be running in the foreground.
In your case, you fit into the second point where you started a foreground service when an activity is visible to the user so technically your app is still considered to be in the foreground while the service notification is being shown even if the user navigates away from your app.
The foreground service needs to have android:foregroundServiceType="location" in its manifest declaration if you are targeting Android 10 and above. See here.
You don't necessarily need the ACCESS_BACKGROUND_LOCATION permission if you are fetching location updates in the foreground service that you have created since you are not technically accessing location while in the background. However, within your service, if you use any APIs that may require background location permission, such as Geofencing, then you will require the background permission to be added to the manifest and request and handle the permission accordingly.
Related
I am trying to build an android application that use location information, but I am confused what to use foreground or background location permissions
my goal is to get location information always while the app is running even in the background and stop getting the location once the app is fully closed.
so what should I use? background or foreground location??
If I understand your problem correctly, your app needs to have both the permissions, Foreground and Background.
You can follow this link for more details: https://developer.android.com/about/versions/11/privacy/location
From the android documentation, the ACCESS_BACKGROUND_LOCATION permission should be stated for app that access the background location, user should see the "Allow all the time" option in the permission page of the application.
Yet, there are a lot of sports app, say strava, that track the gps of user continuously, even when app killed or app in background. They didn't even state the permission of ACCESS_BACKGROUND_LOCATION. This can be verify when going to their app permission page, only allow only when using app, ask every time and refuse options are shown. I understand they use foreground service to do such thing, but how come they didn't state for the ACCESS_BACKGROUND_LOCATION permission? Isn't this a must for apps to track user in background as required by Google? Can anyone give me some explaination on this? Thanks
Access to the Microphone in the background is stopped in Android 11. There are only 3 options, Allow when in-use, Allow once, and Deny.
How to make the app get access to the microphone in the background all the time in Android 11? Is there any workaround?
Now we have to specified a type for our foreground service (https://developer.android.com/guide/components/foreground-services#types):
<manifest>
...
<service ...
android:foregroundServiceType="camera|microphone" />
</manifest>
But in some cases our foreground service can't still access camera or microphone even if we specified android:foregroundServiceType:
If a foreground service was started while app was in background (wasn't visible to a user - no visible activities), for example on device boot (BOOT_COMPLETED) broadcast, then such service can't start using camera, microphone
If a foreground service was started while app was in foreground (was visible to a user - some visible activity) then such service can start using camera, microphone
Info from: https://developer.android.com/guide/components/foreground-services#bg-access-restrictions
My issue Camera2 cameraManager.openCamera exception from time to time on some devices
The new Android Developer Policy restricts access to Microphone and Camera in the background.
Using Accessibility Service one can still use the feature in the background. However, the notification will always be on.
To access background mic / camera / location in Android 11 there are some exemptions given by Android , you need to qualify one of these conditions:
Refer: https://developer.android.com/guide/components/foreground-services#restrictions-exemptions
Exemptions to while-in-use restrictions:
When a foreground service starts in one of the following situations, the service is exempt from the restrictions on while-in-use access to location, camera, and microphone:
The service is started by a system component.
The service is started by interacting with app widgets.
The service is started by interacting with a notification.
The service is started as a PendingIntent that is sent from a different, visible app.
The service is started by an app that is a device policy controller that is running in device owner mode.
The service is started by an app which provides the VoiceInteractionService.
The service is started by an app that has the START_ACTIVITIES_FROM_BACKGROUND privileged permission.
I am getting location updates in a service via FusedLocationProviderClient. Problem is: When "Always-on screen" is disabled on the watch, the location updates become very irregular.
Is there a way to circumvent this?
I figured out that it was actually not the location provider but android restricting the resources of the encapsulating service since it wasn't configured as a ForegroundService. From the documentation:
If your app targets API level 26 or higher, the system imposes restrictions on using or creating background services unless the app itself is in the foreground. If an app needs to create a foreground service, the app should call startForegroundService().
I am having a hard time understanding the right way to handle a user changing a permission while my app is still running in the background.
In my app I have a location class that registers for location changes and when the location changes the status is sent to a server. However this runs in the background.
When my app is launched I check with the user if its ok to use location services and if so I proceed with setting up that class. However the user can background my app and go into settings and remove that permission. I can, and will certainly check that the permission is enabled in my location class before asking for a location from the location service to avoid a crash. However I am not in an activity when a location comes in so I am not sure how to prompt them that my app needs location services.
EDIT:
It does seem that android restarts your app if a permission has been revoked in settings. However I have confirmed that as of now android does NOT restart your app if a permission was granted though settings.
I read somewhere that your app gets killed when the user changes the permissions on Android-M so you can be sure that this won't change while your app is running. It will been killed when this changes.
As reference check this video: https://www.youtube.com/watch?v=f17qe9vZ8RM
However I am not in an activity when a location comes in so I am not sure how to prompt them that my app needs location services.
Raise a Notification, alerting the user that your app cannot do its intended work without the permission that they revoked. Have the Notification tie into an Activity via a PendingIntent where the user will be able to grant that permission.
Along with CommonsWare suggestion, you can have the onProviderDisabled() to know which provider (gps, network) has been disabled and accordingly requestLocationUpdate() for the one that is still enabled. If both are disabled, see if at least Cell Location is of useful for your app. If so, you can send Cell Location at least till user see notification and re-enable the permission.Use PhoneStateListener to do that.
I would like to try a more modern 2020+ answer to the core question:
However I am not in an activity when a location comes in so I am not sure how to prompt them that my app needs location services.
However I am not in an activity when a location comes in so I am not sure how to prompt them that my app needs location services.
If you are in a normal end user environment:
Respect the users choice to revoke the permission and only display the missing permissions to the user if she opens your activity.
On modern devices your service needs to display a notification in the bar to even be allowed to continue running - change the notification to show the problem.
You are allowed to just ask for most permissions but the user has the ability to deny on the 2nd attempt. After that you get auto-no without anything displayed.
Some permissions (e.g. write settings and overlay) can be accessed by opening the settingspages for this directly - which can be done from a service but will be seen as harassment.
If you are in a work environment:
Best use an official mdm solution (COPE).There you can totally zombiefy your devices allowing nothing or anything and pretty much anything in between. User cannot even enter settings if you dissallow or not even turn the device off or.. you name it.
And apps can get all permissions they need and be installed automatically from the getgo.
For both (eben in mdm sometimes a more powerful user might be wanted):
Please build an extra Activity or Fragment (if you have one that uses those) dedicated to display why your app needs a permission and a button for the user to initiate the request/opening of settings.
It may be much work but users and google will be happy :)