Properly request permissions for Android >= 6.0

[Martin Felis]

Implement something like this: https://developer.android.com/training/permissions/requesting.html so that permissions are properly set.

Maybe also using this: https://stackoverflow.com/questions/8292558/is-there-a-way-to-check-for-manifest-permission-from-code to request all permissions that are present in the AndroidManifest.xml.

[Tae Hanazono]

Setting the target SDK to something below Android 6.0 API level will treat the APK as legacy.

[Martin Felis]

@Tae Hanazono and how are legacy apps treated differently? Also: what are legacy apps? I can't find much information about 'legacy apps' in the android doc.

[Rami Sabbagh]

If the targetSDK is below Android 6.0 API, then it's treated as "legacy", which means it will be given storage permissions while asking for them when installing the App.

But since the targetSDK is higher or equal to Android 6.0, then Android pretends that the app knows how to ask for permissions when launched.

[Martin Felis]

Using API 22 as targetSdkVersion to circumvent having to request permissions manually. This works for now, therefore setting priority to minor.

[kwong999999 NA]

@Martin Felis Great work for maintaining this repo, have used it to make my game recently :D

just want to share some info:

1. this year, Play Store will require new apps & updates to target at least API level 26, so the circumvention will not be accepted by Play Store starting from August/November 2018 (Source: https://developer.android.com/distribute/best-practices/develop/target-sdk)

2. A way to have file write access without needing to show request dialog for permission: internal storage Note: Unlike the external storage directories, your app does not require any system permissions to read and write to the internal directories returned by these methods. (Source: https://developer.android.com/training/data-storage/files)

[Martin Felis]

@kwong999999 NA thanks for outlining reasons as to why upgrading must be done (I do this in my free time and my day to day stuff has little to do with Android so I am not always on top of things here - so double thanks!).

Yeah, the internal write access is no problem, however if someone sets t.externalstorage = true then we have to show the dialog and especially when developing a game this setting can be very handy.

[kwong999999 NA]

you're always welcome, that's too humble of you! (I wouldn't have known that Play Store policy as well if I didn't experience it first-handly)

oh TIL the t.externalstorage option, so by default I can remove the storage permissions (android.permission.READ_EXTERNAL_STORAGE and android.permission.WRITE_EXTERNAL_STORAGE) and can expect calls like "love.filesystem.write" to still work? that'd be handy

[Rami Sabbagh]

I've got this message from Google Play when updating my LÖVE App

[Tae Hanazono]

Bump. I take all my words.

Unfortunately, as stated above, apps must target at least Android 8.0, and LOVE still doesn't know how to request this.

Can this one be changed to higher priority?

[Martin Felis]

The issue is less the priority but rather time available and/or pull requests. I don't think that I'll be able to fix it before August.

Current workaround:

As @kwong999999 NA already suggested you should be able to set t.externalstorage to false, remove storage permissions and set target API to level 26.

The only issue is that all files read or created will not be accessible using a file browser on a non-rooted Android device.

What needs to be done:

1. Figure out when it would be best to ask for storage permissions (and possibly others as well): when starting the app (probably easiest and good enough)? When storage is accessed (more tricky but the right thing (TM))
2. Figure out when LÖVE can request those permissions. Needs to be some time after conf.lua was read. Possibly needs some Android specific handling. Maybe @Bart van Strien or @Alex Szpakowski have ideas on when it would be best.
3. Add a JNI call back from C to the Java part to request the permissions.

Now that I think of it: there might be a way to simply request for all permissions in Java land only by going through the permissions in the manifest, request them, and then go start the SDL2/LÖVE native part.

[Tae Hanazono]

Regarding t.externalstorage, what about #132? Also my game must allow user to read/write the user save directory because mine is rhythm game and user can supply their own beatmap file.

[Rami Sabbagh]

I've got a reminder email from google:

The walk-through to not use the t.externalstorage option in conf.lua won't work for me, because I MUST provide access for my users into the save directory !

Only 3 months left to solve this.....

[kwong999999 NA]

@Rami Sabbagh

just my few cents: to my understanding, if it's an existing app that you're not going to update in the soon future, then there's no immediate action needed, the app will still be there after 3 months

after Android M, for external storage, you must always handle the case of external storage being unavailable since users can always turn off the app's access (like iOS). only internal storage is guaranteed.

For your case, I remember reading somewhere about using ContentProvider to provide access for other apps to your app's (ie. your game) internal storage, which is guaranteed to be there.

otherwise you might have to make the need for external storage optional

[Tae Hanazono]

https://developer.android.com/reference/android/content/Context#getExternalFilesDir(java.lang.String)

It looks like that since KitKat, WRITE_EXTERNAL_STORAGE is not needed to enable t.externalstorage, so I think this one can be ignored. But then the /sdcard/lovegame support and *.love file support will be problematic without permission request.

I had tried to experiemnt on how to implement this thing correctly, but it seems that it doesn't play well with LOVE game loop, so I'm kinda stuck.

[Martin Felis]

Fixed as of 94c8a99ddcf.