title: Can you request permissions synchronously in Android Marshmallow (API 23)'s runtime permissions model?
body: <p>Say you have a method like this:</p>
  
  <pre><code>public boolean saveFile (Url url, String content) {
  
     // save the file, this can be done a lot of different ways, but
     // basically the point is...
  
     return save_was_successful;
  }
  </code></pre>
  
  <p>Throughout your app, if you want to save a file to external storage, you do something like...</p>
  
  <pre><code>if (saveFile(external_storage_url, "this is a test")) {
     // yay, success!
  } else { // notify the user something was wrong or handle the error }
  </code></pre>
  
  <p>This is a simplified example, so don't get on my case about blocking the UI, handling exceptions properly, etc.  If you don't like file saving, you could imagine a <code>getContact()</code> or <code>getPhoneState()</code> or whatever.  The point is it's a permission-needing operation that returns some value(s) and it's used throughout the app.</p>
  
  <p>In Android &lt;= Lollipop, if the user had installed and agreed to granting <code>android.permission.WRITE_EXTERNAL_STORAGE</code> or whatever, all would be good.</p>
  
  <p>But in the new Marshmallow (API 23) <a href="https://developer.android.com/preview/features/runtime-permissions.html">runtime permission model</a>, before you can save the file to external storage, you're supposed to (1) check if the permission has been granted.  <a href="https://github.com/googlesamples/android-RuntimePermissions/blob/master/Application/src/main/java/com/example/android/system/runtimepermissions/MainActivity.java#L204-L208">If not</a>, possibly (2) <a href="https://github.com/googlesamples/android-RuntimePermissions/blob/master/Application/src/main/java/com/example/android/system/runtimepermissions/MainActivity.java#L217-L227">show a rationale for the request</a> (if the <a href="https://developer.android.com/reference/android/app/Activity.html#shouldShowRequestPermissionRationale(java.lang.String)">system thinks it's a good idea</a>) with a toast or whatever and (3) ask the user to grant permission via a dialog, then basically sit back and wait for a callback...</p>
  
  <p>(so your app sits around, waiting...)</p>
  
  <p>(4) When the user finally responds to the dialog, the <a href="https://github.com/googlesamples/android-RuntimePermissions/blob/master/Application/src/main/java/com/example/android/system/runtimepermissions/MainActivity.java#L263-L264">onRequestPermissionsResult()</a> method fires off, and your code now (5) has to sift through WHICH <a href="https://github.com/googlesamples/android-RuntimePermissions/blob/master/Application/src/main/java/com/example/android/system/runtimepermissions/MainActivity.java#L286">permission</a> request they are actually <a href="https://github.com/googlesamples/android-RuntimePermissions/blob/master/Application/src/main/java/com/example/android/system/runtimepermissions/MainActivity.java#L286">responding to</a>, whether the user said yes or no (to my knowledge there's no way to handle "no" vs. "no and don't ask again"), (6) figure out what they were trying to accomplish in the first place that prompted the whole ask-for-permissions process, so that the program can <em>finally</em>  (7) go ahead and do that thing.</p>
  
  <p>To know what the user was trying to do in step (6) involves having previously passed a special <a href="https://developer.android.com/preview/features/runtime-permissions.html#coding">code</a> (the "permissions request response") which is described in the docs as an identifier of the type of <a href="https://github.com/googlesamples/android-RuntimePermissions/blob/master/Application/src/main/java/com/example/android/system/runtimepermissions/MainActivity.java#L89">permission request</a> (camera/contact/etc.) but seems to me more like a "specifically, what you were trying to do when you realized you'd need to ask for permissions" code, given that the same permission/group may be used for multiple purposes in your code, so you'd need to use this code to return execution to the appropriate place after getting the permission.</p>
  
  <p>I could be totally misunderstanding how this is supposed to work-- so please let me know if I'm way off-- but the larger point is I'm <em>really</em> not sure how to even think about doing all of the above w/the <code>saveFile()</code> method described previously due to the asynchronous "wait for the user to respond" part.  The ideas I've considered are pretty hacky and certainly wrong.</p>
  
  <p>Today's <a href="http://androidbackstage.blogspot.com/2015/08/episode-33-permission-mission.html">Android Developer Podcast</a> hinted that there may be a synchronous solution around the corner, and there was even talk about a magic, one-step alt-enter type of "add a permissions request" tool in Android Studio.  Still, how the runtime permission process might be shoved into a <code>saveFile()</code> or whatever-- I'm thinking something along the lines of :</p>
  
  <pre><code>public boolean saveFile(Url url, String content) {
     //   this next line will check for the permission, ask the user
     //   for permission if required, maybe even handle the rationale
     //   situation
     if (!checkPermission(Manifest.permission.WRITE_EXTERNAL_STORAGE,
                          R.string.permission_storage_rationale))
         {
             return false; // or throw an exception or whatever
         } else {
  
     // try to save the file
  
     return save_was_successful;
  
     }
  }
  </code></pre>
  
  <p>So the above <code>checkPermission()</code> would fail if the user didn't have and also refused to grant the permission.  Maybe one could use a loop around <code>checkPermission()</code> to try asking up to 3 times or something, or better would be if a sane dont-be-annoying-policy was handled by the method.</p>
  
  <p>Is such a thing possible?  Desirable?  Would any such solution block the UI thread?  From the podcast it sounded like Google <em>may</em> have a solution like this coming 'round the corner, but I wanted to get thoughts on whether there was something-- a convenience class, a pattern, something-- that doesn't involve everyone having to refactor all permission-requiring operations, which I must assume could get pretty messy.</p>
  
  <p>Sorry for the long-winded question, but I wanted to be as complete as possible.  I'll take my answer off the air.  Thanks!</p>
  
  <hr>
  
  <p><strong><em>Update</em></strong>:  Here is the transcript from the podcast mentioned above.</p>
  
  <p>Listen at about <a href="http://androidbackstage.blogspot.com/2015/08/episode-33-permission-mission.html">41:20</a>.  In this discussion:</p>
  
  <p>Rough transcript:</p>
  
  <p>Tor Norbye (Tools team):  "<em>So it doesn't seem like it should be a lot of work for developers.  But I understand part of the problem is that these are not synchronous calls, right?.  So what you have to- actually change the way your activity is written to have a callback-- so it's really kinda like a state machine where... for this state, you-</em>"</p>
  
  <p>Poiesz (product manager): "<em>Ah- I thought- there was a- there might be an option for synchronous response--</em>"</p>
  
  <p>Norbye: "<em>Oh.  that would make things--</em>"</p>
  
  <p>Poiesz: "<em>I can talk with folks internally.  I recall a discussion about synchronous- but we can find out.</em>"</p>
  
  <p>Norbye: "<em>Yeah. In fact we should probably make it into the tools.  Where you have an easy refactoring...</em>"</p>
  
  <p>Then he talks about using annotations in the tools to determine which APIs require permissions.. (which as of now doesn't work that great IMO) and how he wants the tools someday to actually generate the required code if it finds an unchecked "dangerous" method call:</p>
  
  <p>Norbye:  "<em>...then if you're on M as well it'll say, 'hey, are you actually checking for this permission or are you catching security exceptions?', and if you're not, we'll say 'you probably need to do something for requesting the permission here.'   What I would like though is for that to have a quick fix where you can go 'CHING!' and it inserts all the right stuff for asking, but the way things were back when I looked, this required restructuring a lot of things-- adding interfaces and callbacks, and changing the flow, and that we couldn't do.  But if there's an easy synchronous mode as a temporary thing or a permanent thing, that would [be great].</em>"</p>