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
Related
My app, already published on Google Play and currently targetting Android 12, is an alarm clock app. In the latest release, I have used the SCHEDULE_EXACT_ALARM permission and also handled checking and requesting this permission at runtime, as required.
Upon checking the behaviour change for Android 13, I found that there is a new permission USE_EXACT_ALARM which has very restrictive use cases as listed here. My app is an alarm clock app, and hence it qualifies to use this permission. (An advantage of using this permission is that the system automatically grants it, and it cannot be revoked by the user.)
I added this permission to the AndroidManifest.xml file and removed the SCHEDULE_EXACT_ALARM permission. However, Android Studio gives me a lint warning on the method alarmManager.setAlarmClock(...):
This is what the warning reads:
Setting Exact alarms with setAlarmClock requires the SCHEDULE_EXACT_ALARM permission or power exemption from user; it is intended for applications where the user knowingly schedules actions to happen at a precise time such as alarms, clocks, calendars, etc. Check out the javadoc on this permission to make sure your use case is valid.
The Android Developers website says that I have the option to declare either of the permissions based on my use case. However, Android lint tells me that I should declare SCHEDULE_EXACT_ALARM irrespective of whether I have already declared USE_EXACT_ALARM.
What should I do? Follow the website and suppress lint?
The answer's actually buried in the USE_EXACT_ALARM permission's documentation:
Apps need to target API Build.VERSION_CODES.TIRAMISU or above to be able to request this permission. Note that only one of USE_EXACT_ALARM or SCHEDULE_EXACT_ALARM should be requested on a device. If your app is already using SCHEDULE_EXACT_ALARM on older SDKs but need USE_EXACT_ALARM on SDK 33 and above, then SCHEDULE_EXACT_ALARM should be declared with a max-sdk attribute, like:
<uses-permission android:name="android.permission.SCHEDULE_EXACT_ALARM"
android:maxSdkVersion="32" />
So it's kind of a conditional thing - if you're on 33+, then USE_EXACT_ALARM will be available, and the other one won't be requested at all.
Any one know how get the location update every seconds. when my device on foreground or background mode.
I am working on Tracking app get the location in every seconds when he is waking on road or traveling whatever.
Actually my app working on version 10 not working on android 11 and 12.
Also searched on google don't found exact answer.
I used this permission:
Access background permission,
Access Coarse permission.
Access Fine Location.
OR Foreground services for notification
If any one know please let tell me
Thank you
in android 11 or higher the user has to go to app permissions and specifically give them permissions to always take the position in the background. This permission cannot be requested from the app. Only from the phone configuration.
To help protect user privacy, Android 11 (API level 30) introduces limitations to when a foreground service can access the device's location, camera, or microphone. When your app starts a foreground service while the app is running in the background, the foreground service has the following limitations:
Unless the user has granted the ACCESS_BACKGROUND_LOCATION permission to your app, the foreground service cannot access location.
The foreground service cannot access the microphone or camera.
Reference link : https://developer.android.com/guide/components/foreground-services#access-restrictions
you have to use the Foreground service for that and add a task in the Foreground service to get a location using geolocation or any other library.
steps to implement:
implement foreground service using link library::[1]: https://github.com/Raja0sama/rn-foreground-service.
add headless task using geolocation.
you will get the location after the app is removed from recent.
I have an Android app on Play store for 8 years. Recently Google release Android S or 12 introduce some limit with Foreground service launch restrictions
https://developer.android.com/about/versions/12/behavior-changes-12#foreground-service-launch-restrictions
and
Exact alarm permission
https://developer.android.com/about/versions/12/behavior-changes-12#exact-alarm-permission
In the app I use foreground service and alarm clock to schedule update weather data from the cloud and device sensor and send notification to user, update the widget.
But they said: Exact alarms should only be used for user-facing features so if I continue use those API, it is safe (with Google Play policy)?
I ask this because other solution like sticky notification with foreground service and workmanager not work as my requirements.
if you are testing android 12 then don't forget to add this line to Manifest
<uses-permission android:name="android.permission.SCHEDULE_EXACT_ALARM" />
Yes, the android.permission.SCHEDULE_EXACT_ALARM it's safe to use, on Android 12 this permission is automatically granted by the Android system but on Android 13 you need to check if the user has granted this permission.
So you need to add the permission to the manifest
<uses-permission android:name="android.permission.SCHEDULE_EXACT_ALARM"/>
And then you need to check if the permission was granted, if not granted then you need to redirect the user to the Alarms & Reminders page
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.S) {
val alarmManager = ContextCompat.getSystemService(context, AlarmManager::class.java)
if (alarmManager?.canScheduleExactAlarms() == false) {
Intent().also { intent ->
intent.action = Settings.ACTION_REQUEST_SCHEDULE_EXACT_ALARM
context.startActivity(intent)
}
}
}
Google also suggests that you need to check any changes on this permission by registering a Broadcast Receiver and check the changes on ACTION_SCHEDULE_EXACT_ALARM_PERMISSION_STATE_CHANGED
Google states: "(when your app) requires precisely-timed actions". Your use case is "to schedule update weather data (…) send notification to user". While this might be user-facing, it doesn't seem to require to be precisely on a certain time. I would guess your app doesn't qualify.
The methods requiring the additional permission are currently: setExact(), setExactAndAllowWhileIdle() and setAlarmClock(). Repeating alarms will always be inexact. Seems like getting processing weather data and device sensors is something repetitive anyway.
From what you've mentioned, you're talking about user-facing features.
A hypothetical example of the opposite would be Facebook forcing synchronization of user data at some specific time. That would be bad because it's preferable not to force a schedule on those types of things as it doesn't matter whether it happens at a specific time or a minute later when system resources are not used by some other service.
Also, "should" means it's a recommendation. Facebook can do the above, but it would be a less optimal solution. It's best to leave control over those kinds of services to Android as it would likely do a better job at distributing resources and preventing lag. So in other words, you not listening to their recommendation won't get your app removed from the app store or something like that.
Also, the paragraph you quoted from the second link, has a link to examples of acceptable use cases, and it mentions alarm apps. This is likely why your question was downvoted.
effective solution
you need to add the permission to the manifest before <application
An application I work on calls TelephonyManger.getCallState() to find out if the call state is CALL_STATE_IDLE.
Our intention is to avoid distracting the user by opening an activity while a call is in progress.
A courtesy.
However, as of API 31, this call is deprecated:
https://developer.android.com/reference/android/telephony/TelephonyManager#getCallState()
This method was deprecated in API level 31.
Use getCallStateForSubscription() to retrieve the call state for a specific telephony subscription (which allows carrier privileged apps), TelephonyCallback.CallStateListener for real-time call state updates, or TelecomManager#isInCall(), which supplies an aggregate "in call" state for the entire device.
Worse, it now requires a dangerous and scary permission.
Requires Permission: READ_PHONE_STATE for applications targeting API level 31+.
For any alternatives it suggests - you must either have READ_PHONE_STATE or carrier privileges.
https://developer.android.com/reference/android/telephony/TelephonyManager.html#getCallStateForSubscription()
The application I work on does have carrier privileges in some variants, but not all.
But WHY would this be required?
In Behavior changes: Apps targetting Android 12, this change is not mentioned at all:
https://developer.android.com/about/versions/12/behavior-changes-12
It says nothing whatsoever about the fact that you will no longer be able to tell if a call is in progress.
There is nowhere I can find the reason for this change.
It seems that knowing if user in call is something basic that an app might want to know. Not just apps that have carrier privileges.
Why was it okay for 12 years and suddenly not?
For example, some apps, like Audible, will stop audio when a call comes in and resume when call is completed. So is that not going to happen anymore without dangerous permissions?
READ_PHONE_STATE Permission includes the current cellular network information, the status of any ongoing calls, and a list of any PhoneAccounts registered on the device. A permission which a user will not grant lightly.
I am verifying my location service compatibility with Android Q but I am a little unsure how my app is going to react since in my testing I have seen not difference when granting Background permission vs Only while app is running.
Coming off this statement from the Q migration documentation
An app is considered to be in the background unless one of its
activities is visible or the app is running a foreground service.
Since the location service is a foreground service does the difference in permission even matter in this case?
Well it's a bit of a tricky question.
When running location foreground service on Q you need "while app running" permission + to declare in the manifest this foreground service is of type location. Your app has no need of the background permission.
If your app do asks for background permission, the user can get suspicious and reject any location permission :( So it is not recommended to ask the user for permissions you don't need.
highly recommend to watch this video from the google IO: Updating Your Apps for Location Permission Changes in Android Q (Google I/O'19)
You can read more about t here: documantation
And you can see googles example project on GitHub for location updates on Q with foreground service here :LocationUpdatesForegroundService
You just need run foreground service instead of background. Otherwise your app will crash during background services start when there is no activity on the foreground