No Permission. Please Grant Permission and Try Again.
I'g pretty sure that you lot know that with Marshmallow (SDK 23), we got a new permissions system. Permissions are non handled by the apk installer anymore. Before Android half dozen.0, all permissions were shown on the screen after clicking "Install" on any application on Google Play. Since Android 6.0, the permissions are handled at the runtime. What information technology means is that user is asked to Permit or Deny permissions after he runs the application.
I'm non entirely sure why Google fabricated this decision, if I were to guess I'd say that they wanted to provide users with more than flexibility. Imagine that you got an awarding Calculator, which requires you to let Location services, then the app can collect your location. The developers might demand it, so they know where people utilize their Figurer app, but for you it is absurd to let this, as all you care about is calculations and it does non make any sense to transport your location data while calculating. That is where the new permission system comes handy; you tin can but deny the location permission and go ahead with your calculations. This is just an example; there might be more of a groundwork story to this system.
Although everything is squeamish and fair now, it is harder for developers to implement all the situations that could possibly happen. What if user denies a permission that you strictly need for y'all app to work properly? And what if they check the 'Don't evidence again' option and you won't be able to ask them nearly the permission once more? These are the consequences you lot have to wait. We will be implementing a permission check that will work based on this diagram:
There are many libraries that make information technology easier to implement these permissions. Using a library can sometimes cut off a slice of flexibility for you though, and it too makes the release APK a fleck bigger. It is absolutely piece of cake to implement the permissions using native Android classes, that is why I will show you lot how to do it in the simplest way. There are two options here – you tin either require permissions on application startup, or during it's lifecycle, f.e. on click on a button that further performs a job which requires some permission.
I will implement the second option, but it's absolutely easy to transform it to the first selection too, so yous tin can choose what fits your awarding meliorate. So permit's say we accept a button that writes a file into phone'south storage. Nosotros will create an onClickListener for information technology and inside nosotros will bank check if the system has the required permission.
btn_write.setOnClickListener(new View.OnClickListener() { @Override public void onClick(View view) { if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.M) { // Comment 1 if (checkSelfPermission(Manifest.permission.WRITE_EXTERNAL_STORAGE) == PackageManager.PERMISSION_GRANTED) { .... write file into storage ... } else { requestPermissions(new String[]{Manifest.permission.WRITE_EXTERNAL_STORAGE}, // Comment 2 666); } } } }); Comments:
1: Equally I said, permissions before version 6.0 (Build.VERSION_CODES.M) are granted during application installation. Method checkSelfPermissionworks only since version vi.0, that is why yous have to perform this check. Without information technology, y'all would get an error
two:Method requestPermissions accepts an array of String objects as a parameter. You can add together more permissions hither, just add them into new Cord[] { }
When the requestPermissions() method is fired off and the user clicks on Let or Deny on the permission dialog, you can catch his activity and continue with it by overriding the onRequestPermissionsResult() method. So when the user immune the permission WRITE_EXTERNAL_STORAGE, we can go further with our code and write the file into storage. Although if he denied the permissions, there is no fashion we tin can continue. If he actually denied the permission, we volition prove a Snackbar saying that this app will not run properly without this permissions and we will also testify him a button that will forward him into Settings where he can let this permissions.
@Override public void onRequestPermissionsResult(int requestCode, @NonNull String permissions[], @NonNull int[] grantResults) { switch (requestCode) { case 666: { if (grantResults[0] == PackageManager.PERMISSION_GRANTED) { // Annotate ane. ... nosotros got the permission immune, at present nosotros can try to write the file into storage again ... } else { if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.M && !shouldShowRequestPermissionRationale(Manifest.permission.READ_EXTERNAL_STORAGE)) { // Comment ii. Snackbar s = Snackbar.make(findViewById(android.R.id.content),"We require a write permission. Please allow it in Settings.",Snackbar.LENGTH_INDEFINITE) .setAction("SETTINGS", new View.OnClickListener() { @Override public void onClick(View view) { Intent intent = new Intent(Settings.ACTION_APPLICATION_DETAILS_SETTINGS); Uri uri = Uri.fromParts("package", getPackageName(), goose egg); intent.setData(uri); startActivityForResult(intent, 1000); // Annotate three. } }); View snackbarView = due south.getView(); TextView textView = (TextView) snackbarView.findViewById(android.support.pattern.R.id.snackbar_text); textView.setMaxLines(3); // Comment 4. s.evidence(); } } } } } Comments:
1: In our instance, we request only one permission, hence grantResults[0]. If you require more of them, you should loop through this array and check every one of them.
2: At that place is a different caption for shouldShowRequestPermissionRationale() method, but I will give you lot a different one. This method returns false if the user ticked the 'Don't bear witness again' option. Equally long as the user did not tick the 'Don't show again' selection, the method tells the states that we still can and should show the dialog requesting the specific permission – method returns true. Later on user ticked information technology, we tin no longer show the dialog – method returns false. Nosotros practise this bank check, considering while user hasn't ticked the option, we practice non have to show any Snackbar. The user can just go on and click the btn_write until he realizes that he needs to tick the option if he wants to become rid of the dialog. Subsequently he does tick information technology, then we show him the Snackbar which volition forward him to options.
3: The number '1000' is just an example. You need this number to differentiate betwixt separate activity results. This activity redirects user to options. After he comes dorsum from options, we will desire to know that he did, so we will check if the outcome of the intent is too 1000 and if is, we volition bank check again if he allowed the permission in that location.
4: This is a simple fob. Our Snackbar grows on size based on length of the chosen text. This command will allow information technology to brandish more lines than simply one.
Now that we have this done, the simply matter left is to check the permission once again when user returns from Settings. It'due south fairly easy – if he did permit the permission, nosotros will not practise anything, he can continue using the application without any restrictions. Although if he did NOT allow information technology (pregnant he went to Settings but then he came back without changing anything), nosotros have to show him the same Snackbar again. In the previous step, nosotros started the settings intent with code 1000, and then we volition catch the same code in overridden onActivityResult()method which handles returns from other activites.
@Override public void onActivityResult(int requestCode, int resultCode, Intent information) { super.onActivityResult(requestCode, resultCode, information); if (requestCode == 1000 && resultCode == Activity.RESULT_OK) { if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.Grand && checkSelfPermission(Manifest.permission.WRITE_EXTERNAL_STORAGE) == PackageManager.PERMISSION_DENIED) { Snackbar s = Snackbar.make(findViewById(android.R.id.content),"Nosotros crave a write permission. Please allow it in Settings.",Snackbar.LENGTH_INDEFINITE) .setAction("SETTINGS", new View.OnClickListener() { @Override public void onClick(View view) { Intent intent = new Intent(Settings.ACTION_APPLICATION_DETAILS_SETTINGS); Uri uri = Uri.fromParts("packet", getPackageName(), null); intent.setData(uri); startActivityForResult(intent, k); } }); View snackbarView = southward.getView(); TextView textView = (TextView) snackbarView.findViewById(android.back up.design.R.id.snackbar_text); textView.setMaxLines(half dozen); s.show(); } } } In the code above we check if the permission was granted, we don't do anything, although if it is not granted, we show the same Snackbar. And that's ALL! We take a very simple circular permission cheque wheel that will not neglect in any instance and will brand certain that user will grant the permission. If you do non understand any
Vladimir Marton
Source: https://www.guidearea.com/granted-denied-and-permanently-denied-permissions-in-android/
0 Response to "No Permission. Please Grant Permission and Try Again."
Post a Comment