Android 6.0 Permissions

Question

I am working on a big project with a reasonably big code base. What I want to ask you is hints on how to reliably check where I have to provide a solution to adapt for android 6.0 . What i have used is Analyze > Inspect Code , it does a static analysis of the code and than shows missing checks in the section : Android > Constant and Resource Type Mismatches. It looks somewhat not the right place to find those problems and that is why I am asking to make sure I am using the right thing and am looking at the right thing, plus I am a bit confused because I have parts of code which write files and i am not getting notified about permissions checks there(is it a normal behaviour?!)

public static boolean write(String folderName, String filename, Object objToWrite) {
    // serialize cardModel
    FileOutputStream file = null;
    ObjectOutputStream o = null;
    File dirFile = AppController.getInstance().getApplicationContext().getDir(folderName, Context.MODE_PRIVATE);
    try {
        // Create archiveDir
        File mypath = new File(dirFile, filename);
        file = new FileOutputStream(mypath, false);
        o = new ObjectOutputStream(file);
        o.writeObject(objToWrite);
    } catch (Exception e) {
        e.printStackTrace();
        return false;
    } finally {
        try {
            o.close();
            file.close();
        } catch (IOException e) {
            e.printStackTrace();
            return false;
        }
    }
    return true;
}

Should I get a warning for Write permission here ?

Another thing that makes me ask is this issue that i have posted on google regarding an Android Studio bug: Android Studio Bug

score 2 · Accepted Answer · answered Sep 21 '15 at 08:34

2

Not every write to a file needs a permission - only the one to external storage - this function might also write to the app file space - this needs no permission. Depends on the parameters

answered Sep 21 '15 at 08:34

ligi

39,001
44
144
244

Thank you for the answer, I also thought that it is not always required, but I kind of needed some reassurance. Do u also have any idea about the two other parts of the question, the Inspection type and the AS bug? – Rubin Sep 21 '15 at 11:48
I can confirm the AS behavior - not quite sure if it is a bug - the devs once spoke about this in the android developers backstage podcast - some checks are done irregulary - otherwise it would consume to much CPU-cycles – ligi Sep 21 '15 at 16:00
I understand what you mean and that is why they have also included some checks only in the Analyze menu of AS, so that they are not always run, but we can manually run them from that menu. The problem is not with it not being automatic, but with the fact that even if I run them manually it still doesn't respond accordingly – Rubin Sep 21 '15 at 16:07
then it is a bug - but you should add this info to the bugreport – ligi Sep 21 '15 at 16:27

score 0 · Answer 2 · answered Sep 15 '16 at 18:49

Interestingly enough, the definition of what "external storage" vs "internal storage" has changed quite a bit since Android Lollipop. What does this mean?

This call will require you to have storage permissions in the external public directory:

public File getAlbumStorageDir(String albumName) {
    // Get the directory for the user's public pictures directory.
    File file = new File(Environment.getExternalStoragePublicDirectory(
            Environment.DIRECTORY_PICTURES), albumName);
    if (!file.mkdirs()) {
        Log.e(LOG_TAG, "Directory not created");
    }
    return file;
}

However, if you do the following, you won't need STORAGE Permissions.

public File getAlbumStorageDir(Context context, String albumName) {
    // Get the directory for the app's private pictures directory.
    File file = new File(context.getExternalFilesDir(
            Environment.DIRECTORY_PICTURES), albumName);
    if (!file.mkdirs()) {
        Log.e(LOG_TAG, "Directory not created");
    }
    return file;
}

According to Google:

`If none of the pre-defined sub-directory names suit your files, you can instead call getExternalFilesDir() and pass null. This returns the root directory for your app's private directory on the external storage.

Remember that getExternalFilesDir() creates a directory inside a directory that is deleted when the user uninstalls your app. If the files you're saving should remain available after the user uninstalls your app—such as when your app is a camera and the user will want to keep the photos—you should instead use getExternalStoragePublicDirectory().

Regardless of whether you use getExternalStoragePublicDirectory() for files that are shared or getExternalFilesDir() for files that are private to your app, it's important that you use directory names provided by API constants like DIRECTORY_PICTURES. These directory names ensure that the files are treated properly by the system. For instance, files saved in DIRECTORY_RINGTONES are categorized by the system media scanner as ringtones instead of music. `

Android 6.0 Permissions

2 Answers2