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

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.

Related

Android permission SCHEDULE_EXACT_ALARM required with USE_EXACT_ALARM for alarm app?

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.

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.

Apps that can draw on top of the screen without permission

I know that in order to draw any view over other apps you have to enable this <uses-permission android:name="android.permission.SYSTEM_ALERT_WINDOW"/> permission. But I have accidentally found out that some apps have this permission enabled by default (e.g. Fabulous, Android Ultimate). How on earth is that possible?
If an app is installed via Play Store and it requests SYSTEM_ALERT_WINDOW, permission is granted automatically to that app.
This was introduced in Marshmallow.

Does Firebase Cloud Messaging really need a WAKE LOCK permission?

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.

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