I am working on run time permissions. When I am in my activity class while creating a report having images, when permission is changed app crashed and I lost my data.I have used OnsaveInstance but it does not do what I really want. I want to restart my app when someone change app permission from settings and save my report.
which method of the activity is called when permission changed?.
How i know that permission is changed from background?
You can check permission in your activity startup or resume, like
this answer
and for restarting app you can try any answer from this Q/ans thread, one of the accepted answer for restarting activity here
Intent i = getBaseContext().getPackageManager()
.getLaunchIntentForPackage( getBaseContext().getPackageName() );
i.addFlags(Intent.FLAG_ACTIVITY_CLEAR_TOP);
startActivity(i);
How i know that permission is changed from background.?
If, from Settings, the user removes a permission that the user granted previously, your process is terminated immediately. You find out that the permission changed the next time your app runs.
If, from Settings, the user grants a permission that the user had not granted previously, then your process is left alone, but you also are not informed about the new permission. You are welcome to call checkSelfPermission() at appropriate points to see if you now have the permission that you lacked before.
To check if you currently have a permission you use ContextCompat.checkSelfPermission(), see the developer docs for details.
If you need the permission in a background thread then you check if you have the permission before you do the work. If you do not have the permission you will have to skip the work, if you just continue then your code will most likely throw a SecurityException.
How you handle it when you don't have the required permissions depends on the use case. You could create a system notification that informs the user the background task could not be performed due to a missing permission. If the user taps the notification then you can request the permission from the user before retrying the task. See the same developer docs for how to request a permission from the user.
If it would be okay to abort the background task then you could do just that but you will probably want to show somewhere in your user interface that the background task needs a permission that is missing and ask the user to grant it so the (optional) background task can do its work.
Related
Since Android 11, there has been a system feature where it resets app permissions after a certain amount of time has passed and you haven't used the app.
I know you can turn it off on most apps, by the user itself like the screenshot below :
and also it seems to turn back on when there are app or system updates.
How can I disable this function in my app by code or sth else?
Well, I doubt there is an easy way.
If your app is a device policy controller, it will not be set to hibernation (System exemptions from hibernation) or, if your app is a default handler for messages, phone, browser etc.
What you can do, is to ask the user to disable auto revoke for your app. But you might have to do that after updates as well, if the system resets this privilege on your app (so your problem won't be solved).
The permissions you request in your app manifest (android:required="true") should never be revoked. But of course you cannot request every kind of permission that way. Some need to be requested explicitly.
Apps using background services are whitelisted automatically as stated here. So you can declare a background service, if this is appropriate for you. But if there is nothing to be done, I could imagine, that the system removes your app from whitelist. (I didn't test all of it)
If you see this post you can also try
PackageManager pm = getPackageManager();
pm.setAutoRevokeWhitelisted(getPackageName(), true);
boolean result = pm.isAutoRevokeWhitelisted(); // result should be true
and this in your manifest:
<uses-permission android:name="android.permission.WHITELIST_AUTO_REVOKE_PERMISSIONS" />
But I actually doubt it works.
i found article for your subject. It's says,
"The toggle is disabled for some apps that perform a background
service, including device admin apps Whenever the toggle is
hidden/disabled the app is already exempted from auto revoke"
Link to the article
You can examine this if you want. I hope it helps you.
For context, the Android documentation says that some app classes receive the SYSTEM_ALERT_WINDOW permission automatically on request:
Any app that has ROLE_CALL_SCREENING and requests SYSTEM_ALERT_WINDOW automatically receives the permission. If the app misses ROLE_CALL_SCREENING, it loses permission.
Any app that is capturing the screen using a MediaProjection and requests SYSTEM_ALERT_WINDOW automatically receives permission, unless explicitly denied by the user. When the app stops capturing the screen, it loses permission. This use case is primarily intended for apps to stream games live.
How can I achieve this configuration to be able to obtain this permission automatically or by default?
As the documentation you quoted says, if you don't fit into one of those use cases, you can't.
It needs to be explicitly granted, and not all devices even support it.
This is because being able to draw over the screen whenever the app wants opens the door to bad behaviors, such as disguising other parts of the UI or preventing the using from using the device properly.
How do I request permission for my location (api 23>) when I want to access the location inside a service?
I have a service running every minute fetching data from a URL. In this service I want to pass my location in the URL but I have issues requesting the permission for my location (since you cant do that inside a service). How can I request permission in my MainActivity?
EDIT: I think my problem is requesting permissions inside a service. My service is started with alarmManager (setRepeating), and in this service I want to access my real time location. When I try to request permission there it does not work. Can I request permissions elsewhere?
Update: If the app starts for the first time, you can ask the user for permission (from your Activity) - user can grant or deny the permission.
If user has denied the permission you should stop/don't start your service and inform the user that, without this permission, your app doesn't work.
See Requesting Permissions at Run Time.
Since Runtime Permissions were introduced in Android Marshmallow, I've been meaning to apply the new way for requesting permissions and I've read and understood the dangerous permissions and how to check for them and request them.
The question is, If I have an Activity that contains a Button for opening Camera.
Do I check and request the permission when the Activity is opened? Or when the button is clicked?
Please explain why your suggested way is preferred.
Do I check and request the permission when the Activity is opened? Or when the button is clicked?
If the only purpose of the Activity is to take a picture when the button is clicked, I would request the permission when the activity is opened.
If the Activity has other roles, such that the take-a-picture button is only one feature out of many, I would ask for the permission when the user clicks the button.
In other words, once the user has requested to go down a path that will (almost) certainly need the permission, ask for the permission.
According to me, when click on button ask for permission to open camera.
because activity can have many component which can request for like camera, contacts, write storage, etc
so you must not ask for permission when activity opens but when you click on button ask for camera permission
if you want to send SMS than ask when you need to send not at opening of activity.
Permissions Best Practices.
You can download official sample app here.
hope you get it.
Starting from Android SDK 23, system permissions are divided into two categories, normal and dangerous:
Normal permissions do not directly risk the user's privacy. If your
app lists a normal permission in its manifest, the system grants the
permission automatically.
Dangerous permissions can give the app access to the user's
confidential data.
If your app lists a normal permission in its manifest, the system grants the permission automatically. If you list a dangerous permission, the user has to explicitly give approval to your app.
For more information, see Normal and Dangerous Permissions.
If your app targets API 23, and you need to ask user for a dangerous
permission (such as READ_CONTACT or READ_CALL_LOG etc.), you need to
ask for permission in runtime.
We developed an application which decodes QR code using Blackberry BarcodeScanner class on OS 6 and above. When barcode scanner screen is invoked, OS alerts for camera permission and application is obscured i.e. it goes in the background. On this point, if user clicks red call end button, application hides (it remains in background and does not terminate) and alert remains open. On accepting ALLOW or DENY and re-opening application, mobile gets hanged and need to be restarted by removing battery from device.
What I want to do is when user clicked red call end button in this situation, I can terminate the application entirely. As OS permission alert is independent from application, when user will invoke application, it will have that permission.
Please help me by telling how can I terminate application from that point.
Not sure why the application hangs, but the best solution is that you should be testing for the permissions you need at start up, using the ApplicationPermissionManager. If you don't have permissions that are critical for application function (the camera is critical to bar code scanning) then you should request the permission through the API which allows you to provide a reason the permission is required. This should happen before you request access to the controlled resource. If the critical permissions are not granted by the user you can display a message and exit cleanly.
For completeness, if the resource is not critical to appliction function the application should ask for the permission once, at first start up, and if not given permission disable the functionality that requires that permission.
Using the default permission request at the time the resource is needed is confusing to most users and does not match the permission granting methods used in more modern systems (BB10, iOS, Android) whereas asking for all the permissions you need on first start provides a better user experience and is easier to handle in the code.