I have an android application which was supporting till lollipop. Now I'm migrating it to support Marshmallow.
I am stuck in a case where if we manually changed the app permission in marshmallow it kills all the process.
I get it as explained by #CommonsWare in similar question here.
But in my case I have to kill the app and need to restart the app. Because my app each activity is dependent on previous activity some data is shared. I just need to know when we manually change the permission is there a way our app get noticed.?
I meant any callback occurs. if Not is there anyway I can handle this case.? Please Let me know if the question is too broad I'll update my question
Thanks in advance
I just need to know when we manually change the permission is there a way our app get noticed.?
Your process is terminated. This is indistinguishable from any other reason why your process might be terminated.
I meant any callback occurs.
No. You get ordinary lifecycle callbacks (e.g., onPause(), onStop()) as the user navigates over to Settings to be able to revoke the permission, but that's it. There is no specific callback related to losing the permission.
Also note that the user could leave your app, your process could be terminated for other reasons, the user could then go into Settings and revoke your permission, then the user could return to your app. If all of that happens within ~30 minutes, Android will still try to rebuild the outstanding task. You certainly would not get a callback of any sort in this case, as your process was not running before the permission was revoked, let alone after.
Related
I figured that in M requestPermissions() can only be called by an Activity class. I have an app that has no UI screen. It runs as a background service. Does this mean that I have to put a spinner screen if checkSelfPermissions returns denied?
I have an app that has no UI screen.
Then it will never run, unless it is preinstalled on an Android device or custom ROM, or it is a plugin to some other app. Otherwise, your app will remain in the stopped state forever. Pretty much every app distributed through normal channels, including the Play Store, needs an activity.
Does this mean that I have to put a spinner screen if checkSelfPermissions returns denied?
I do not know what "a spinner screen" is. AFAIK, the recommended pattern for a service needing a runtime permission that it does not have is to:
Raise a Notification, to let the user know that the service cannot do its work without this permission.
Have the Notification trigger an Activity that can call requestPermissions(). Optionally, this activity can have Theme.Translucent.NoTitleBar, so the only visible UI is the permission dialog.
If onRequestPermissionResult() indicates that you have the permission, the activity can tell the service to go ahead (e.g., via a call to startService()), then finish() itself. If onRequestPermissionResult() indicates that the user denied the permission, do whatever makes sense (e.g., show the Notification again, gracefully shut down, suggest to the user that the user uninstall the app).
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 :)
I'm trying to write an Android service, which starts on boot and works in the background periodically. I have defined the BroadcastReceiver of mine, added the right permissions and all the necessary stuff in manifest.
When I install the APK on my phone and reboot, nothing happens, the program is there in the installed apps section, but not running.
I've seen a user comment stating that "standalone" services are disabled (for security reasons?) since Android 3.1 but I couldn't verify this information anywhere.
Anyone could give me a clear view about this? Without that, I don't know how to proceed: debug or change plans.
Thank you in advance!
Just after the first the first installation of a package, the application is in a "stopped state" preventing it to execute any code for security reasons.
The app loses this particular "stopped state" as soon as the user launch the app explicitly for the first time.
After 3.1 , Android introduced a security feature, where the application's code can't be run unless the user opens the application. Check the link for more info http://commonsware.com/blog/2011/07/13/boot-completed-regression-confirmed.html
I would like to know if anyone has found any hack or work around for this problem, where i can listen to a system broadcasts like boot, connectivity changed and run a service without opening the installed application.
This is not what the posts said. You can still register broadcast listeners, or alarms. You just need the user to actually start your application once. And, if the user forcefully stops your application, they'll need to start it manually again.
Why would you want a way around this behavior? It seems to make a lot of sense.
I want to know whether my app has crashed or exited by the user. Is there any way to do so?
See this: https://developer.android.com/reference/java/lang/Thread.html#setDefaultUncaughtExceptionHandler(java.lang.Thread.UncaughtExceptionHandler), it may help :)
There's no such thing as exiting the application by the user. You can always do something when onStop() or onBackPressed() of your main activity is called, but that's all. Just note that it doesn't mean that the app was "exited", but only "left" by the user. You can of course finish the activity from there to make sure the app is really exited.
Technically, there's no exit ideology in Android. Applications are kept on running in background and (if necessary) Android's VM automatically kill stale applications when it requires to free memory.
Regarding app-crash, if the app is crashed, so you may get notified on your Google Play's developer console in case the user has chosen to report the crash.