Sorry for my bad english.
I have multiple Activity in my app, I need to centralize the runtime app permission.
Do I need to use BaseActivity?
If yes, please suggest me how to handle it in case of many Activity in app.
If no, please suggest better approach to handle it.
I want to reduce the code redundancy. Not interested to write same code again and again with every Activity.
I am looking for negative scenario also where user denied the permission and i have to show rational instead of keep asking to allow permission. and based on that i have to provide message or i have to update UI
Run time permission were introduced to have control over the dangerous resources
So ideally you must be checking for the permission every time you use a resource. This code must not be eliminated.
Then when it comes to request a permission, it is a single line code. I don't think you must be having a trouble with this.
Now comes the tricky part. Handling the permissions that are given. You can definitely have a base class (not recommended) but ideally different permission is used for different purpose.
For example location permission:
In same Activity say Location.java, i might need location permission for getting the address of the person using LatLon values, and in the same activity I am using location permission for live tracking the user.
Now to handle different implementations for same permission, you must have unique permissions codes based on the purpose, but not based on the resource you are accessing permission for. Handling all these things in a base class can be tricky. So ideally you must handle permission in the activity where it belongs. It will keep your code safe and prevent any mix ups with other codes.
Always advisable to read the official docs.
There might be cases where you might get confused with redundancy of the codes and multiple implementations. For that, Android is handling most of the code in its end, as a programmer, least expected is to check for permissions and perform appropriate operations wherever dangerous resources are used.
If you have 10 activities and all of them need location permission.Then I guess it is very crucial permission for your application.
For crucial permission, if not allowed by user you can close your application, hence do it on first activity itself. Like facebook does for various permission. It might be bad experience for user but It is necessary permission for your application.
Just write it once in the first activity and stop application if not permitted by user. A lot of flagship application does that.
Related
I'm looking into starting an Activity (different app) with some parameters (sensitive session) and was wondering what's the safest way here. For instance, startActivityForResult() may be used on Android and I was wondering if any other app can see this request or if it requires root rights to intercept such a request? So basically, is it safe to use it or not? By default, we assume users don't have root rights.
I was wondering if any other app can see this request
The app that responds to your startActivityForResult() call can see the request. That could be:
The real unmodified app that you wish to send the data to
A hacked version of that app
A completely independent app that happens to match your Intent, particularly if you are using an implicit Intent
You can try to check signatures to confirm whether the other app is indeed the real unmodified app, so you avoid the latter two scenarios.
On older versions of Android, the Intent would be visible to other apps as part of the data backing the overview screen (recent-tasks list). That was cleared up somewhere in the 4.x series IIRC.
Those are the only two attacks that I know of for non-rooted devices.
Hey all!
So as Android Devs know, Android M introduced a new Permissions system.. I am nearing the end stages of Coding my App, and implementing this Permission Request is one of my final tasks. I just have a few quick questions about the way it works..
Upon starting my App for the first time, the user see's a Welcome screen, with a view pager type of interface with 4 pages containing information about using the App.. The last page will explain to the user that the App needs a Permission to be granted in order to use the App, and upon clicking a "Lets get Started" Button, I will have the Permission Request pop up..
Here are my Questions:
(1) - Am I actually able to Request the Permission on the fly like I descibed above, to be used later at some point, before I actually need to use the Permission? or am I limited to Requesting the Permission at specific times, such as when I actually need it, or at runtime, etc..?
(2) - Once the user Grants the Permission I Request, is it permanent? or will I need to Request Permission yet again if for example they reboot their phone etc?
Huge thanks for the information!
You can request for Marshmallow permissions at any point of time, they are not limited.
Yes, once the user grants the permission it is permanent, so no pop up will need to be generated. Although the user will still be able to manually remove the permission from the Settings app, which will require you to ask for it again next time you'll need it.
I am using LibGDX and for the Android version of my game I use the "Get Accounts" permission to identify a user by their Gmail address.
Is their a similar way to identify a user for iOS?
According to the App Store Guidelines, you shouldn't get user's personal data without obtaining the user's prior permission. The only identifier you can use anonymously is identifierForVendor:
UIDevice.currentDevice().identifierForVendor?.UUIDString
This identifier is common for all your apps on the user's device. If all the apps were deleted from the device, the identifier may change. More.
Your best bet is to use GameCenter on iOS for identifying the players. This link provides a little more info on handling users with GameCenter.
According to Apple, you shouldn't identify your users, unless you have a good reason to do so.
Like #Marat said, what you are looking for is the UUID,
but keep in mind that this value may change (for example, if the user delete your app and have none of your other apps).
A possible solution would be to keep the UUID value in the keychain, and that way you will always use the same value.
Edit:
Since your app is a game, you can use Apple's GameCenter.
This will identify the users for you.
I found many references to shared user IDs among two apps and it looks like what I'm looking for.
What I'm concerned about is that there are statements like permissions will be shared between the apps. If one of the apps is a system app, does that mean that the normal app will have system privileges too?
I want one app to be a regular app and one app to be a system one. I don't want the regular app to have any of the system admin privileges.
We are doing this so we can share a Content Provider. Our data is on the edge of being complicated enough for this, but I feel it's justified.
It appears that this is something you can't do. If you set up your system app as shared, you don't get any kind of an error, but Android appears to refuse to acknowledge it.
I took shared back out of my manifest file and it is working fine now.
Live and learn...
I have got a suggestion to restrict an Android application to be installed a limited number of times, let's suppose three times for a given user account. I have already inserted a form at the start of the application which checks for username and password from our database, and returns whether its valid or not.
Next I have to apply a trick to prevent this application from being installed more than three times by each user. I hope it clears what I am trying to do. Any ideas what to do and how to proceed?
By no means you can restrict user to not to install your application from google play.
Have a install_count column in the user table in your database. Each time the user fills out form, check for the install_count value, if it is equal to 3, then don't allow the application to continue, you can show a message like "max installs exceeded" and exit the app. Otherwise, increment the install_count value in the db for that user.
PS: As Zoombie said, you can't stop the user from installing the app, but you can restrict the user from running the application if installation limit exceeds.
Also you need to be aware, there are many apps which take a back up of the installed app and data that can be restored back anytime. More over, if the user changes his device more than thrice, he won't be able to run your application. So consider the drawbacks of this limitation.
Technically this isn't a very difficult problem but the issue of user relations will be difficult to manage. You should provide a simple and easy mechanism for your users to "reset" their install count. Additionally you need to inform your users of this restriction BEFORE they pay for your app.
Restrictions like this will result in problems in a few cases I can think of:
What happens if a user factory resets their phone and then re-installs the app?
What if the user installs a custom ROM or gets a new phone?
Are you going to deny a paying customer the ability to install an application that they paid for? Poorly enforcing a policy like this will only hurt you in the long run as it will result in
very bad reviews of your app
piracy of your app with the checks removed
Remember people are downloading/buying your app because it provides something to them and with that they assume that they'll always have access to your app. As soon as you start denying functionality or violating their assumptions you're going to start alienating your customers.