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.
Comments (15)
-
-
reporter @AuahDark 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.
-
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.
-
reporter - marked as minor
Using API 22 as targetSdkVersion to circumvent having to request permissions manually. This works for now, therefore setting priority to minor.
-
@MartinFelis Great work for maintaining this repo, have used it to make my game recently :D
just want to share some info:
-
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)
-
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)
-
-
reporter - marked as major
@kwong999999 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. -
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
andandroid.permission.WRITE_EXTERNAL_STORAGE
) and can expect calls like "love.filesystem.write" to still work? that'd be handy -
I've got this message from Google Play when updating my LÖVE App
-
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?
-
reporter 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 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:
- 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))
- 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 @bartbes or @slime73 have ideas on when it would be best.
- 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.
-
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. -
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.....
-
@RamiLego4Game
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
-
It looks like that since KitKat,
WRITE_EXTERNAL_STORAGE
is not needed to enablet.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.
-
reporter - changed status to resolved
Fixed as of 94c8a99ddcf.
- Log in to comment
Setting the target SDK to something below Android 6.0 API level will treat the APK as legacy.