Does Firebase Cloud Messaging really need a WAKE LOCK permission? - android

I notice FCM needs an Android wake lock permission. Could I remove the wake lock permission using?
<uses-permission android:name="android.permission.WAKE_LOCK" tools:node="remove" />
or will it disrupt receiving the data/notification payload?
I was reviewing this topic and started wondering if its needed. I remember in GCM its mandatory.
The other question I have is since wake lock is not a dangerous permission, I think on and after API 23, users won't even see or know about this permission as it will be transparent. Even the Play Store will not show them that the app needs a wake lock, is that right?

Referring to the GCM docs, the WAKE_LOCK permission seems to have been only optional and not mandatory:
Optionally, the android.permission.WAKE_LOCK permission if the application needs to keep the processor from sleeping when a message is received.
And nothing is stated in the FCM docs that WAKE_LOCK is needed in some way.
And yes, the app will not show that it needs WAKE_LOCK. For permissions with Normal Protection levels (docs):
If an app declares that it needs a normal permission, the system automatically grants the permission to the app.

While AL's answer is correct, I would like to add that on the Play Store listing for the app, it shows the permission under the category "Other":
I couldn't add the picture in a comment, so I was forced to create an answer.

Related

Android 12: Using SCHEDULE_EXACT_ALARM permission to get/show data at specific time are safe in Google Play Policy?

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

Is it really safe when using android 6.0 run time permission?

One of our developers made android application with all permission in manifest.xml (ACCESS_FINE_LOCATION, USE_FINGERPRINT ect.).
I guided him to remove unnecessary permission then he told me, "It is safe, because he used android 6.0 run-time permission (pop up the permission)".
But I think it is not safe because it can be abused.
Do I think wrong?
There are two kind of permissions, normal and dangerous. All declared normal permissions are in effect if declared in the manifest.If the app min sdk is Android 6.0 and above, until the user grants the permissions at runtime, the dangerous permissions are not in effect. It doesn't matter if they are declared in the manifest.It may be dangerous if the user grants the app dangerous permissions and you allow other apps to access some resources using your apps permissions like PendingIntent.
As suggested by Cao Minh Vu
It is better to request permissions which your app really requires.If you request a permission that is not required by your app users may think your app is malware.
For Example:
If you are requesting permissions for camera which is not required for your App even though giving permission or denying it is up to the user but it may cause user to be skeptical.And Probably user may uninstall your Application.

Will asking VIBRATE permission on upgrading an app prevent auto update?

I've added this to my manifest:
<uses-permission android:name="android.permission.VIBRATE" />
I am wondering whether this will disable auto update for my current users.
This question says asking for redundant permissions will not require manual update. So I wonder will VIBRATE prevent auto update?
It will still auto update. The permission android.permission.VIBRATE is not a dangerous permission, and even if it were you would only have to ensure you are correctly requesting that permission when required.
From this google support page
For apps built for Android 6.0 and up: You won't need to review or accept permission changes for the app to update. The first time you use a feature that uses a new permission, you can allow or deny the use of that data or capability.

Do I need android.permission.WAKE_LOCK for Google Play Services if I only release in Google Play Store?

I am trying to integrate Google Analytics for Android. As per the documentation here, it asks to add android.permission.WAKE_LOCK (provides the comment note below). I dont understand it clearly. If I am releasing the app ONLY in the Google Play Store, do I still need this?
I really do not want to ask users for an additional permission if this is not absolutely necessary.
<!-- Optional permission for reliable local dispatching on non-Google Play devices -->
<uses-permission android:name="android.permission.WAKE_LOCK" />
In particular, I do not understand what this note actually means here:
Optionally a WAKE_LOCK permission can be requested to improve dispatching on non-Google Play devices.
Update: As of Android 6 (API level 23, WAKE_LOCK is classed as a "normal" permission, meaning the permission is automatically granted. Removing the WAKE_LOCK permission will often cause apps to crash (see below) so I would avoid doing it.
I'm in the same position. I don't want to add an extra permission as it will significantly reduce the number of people using the latest version of the app (as new permissions mean the user must explicitly opt in to receive the app update).
I believe I have managed to find a solution by combining a few of the answers on this SO question.
First, add "tools" namespace to the app's manifest
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
xmlns:tools="http://schemas.android.com/tools">
Second, add the "WAKE_LOCK" permission but use the remove option
<uses-permission android:name="android.permission.WAKE_LOCK" tools:node="remove" />
Now, when I upload a new APK I can see the permission is no longer required:
Important
It seems like this solution may no longer be viable. I'm now getting a huge number of RuntimeExceptions being thrown with the message "Neither user 10182 nor current process has android.permission.WAKE_LOCK."
Fatal Exception: java.lang.RuntimeException
Unable to start receiver com.google.android.gms.measurement.AppMeasurementReceiver: java.lang.SecurityException: Neither user 10182 nor current process has android.permission.WAKE_LOCK.
WAKE_LOCK
Allows using PowerManager WakeLocks to keep processor from sleeping or screen from dimming.
On Google Play devices, a background service is almost always running as "Google Play Services", so WAKE_LOCK is not required.
On non-Google Play devices, WAKE_LOCK helps keeping the dispatching process / service of Google Analytics alive so it has more chances to report / upload data.
EDIT
Also, it is unclear what happens to dangerous permissions in permission groups that are not ones that the user can control via Settings, such as SYSTEM_TOOLS.
https://commonsware.com/blog/2015/06/02/random-musings-m-developer-preview-bad.html
When removing WAKE_LOCK, also remove AnalyticsReceiver and AnalyticsService.
That way is written on this site.
http://coffeee.hatenablog.com/entry/2017/11/26/035828
open AndroidManifest.xml
click the tab of "Marged Manifest"
right click on WAKE_LOCK and remove
remove AnalyticsReceiver and AnalyticsService
Good Luck

Android App Widget permissions

My very simple app currently does not ask the user for any permissions at all when they install it. I want to keep it this way but I really need to add a widget.
I was looking over the StackWidget Example (http://docs.huihoo.com/android/3.0/resources/samples/StackWidget/) and I noticed that in the manifest they have:
<service android:name="StackWidgetService"
android:permission="android.permission.BIND_REMOTEVIEWS"
android:exported="false" />
That permission there "BIND_REMOVEVIEWS", I haven't seen before. If I were to build off of this example and include that service with that permission, will the user now be notified that my app requires a permission before it can be installed/updated?
No.
<uses-permission> elements are what trigger the user to be notified about permissions that your app is requesting.
android:permission indicates that you are defending a component with a permission that some other app (or, in this case, the firmware) must hold. Since you are not requesting the user grant you a permission, the user is not bothered with the android:permission attribute.
So:
<uses-permission android:name="com.commonsware.permission.SHAVE_YAK" /> is asking the user "may I shave your yak?"
android:permission="com.commonsware.permission.SHAVE_YAK" is telling a third-party app "the user must have agreed to allow you to shave the user's yak"
note: no actual yaks were harmed in the creation of this answer

Categories

Resources