[sword-devel] New shared common SWORD path on Android

Mon Oct 4 07:10:32 EDT 2021

Hi Tobias,
So, I did a bunch of reading when choosing this location and couldn't find anything that specifically listed which folders where standard "top level" folders under /sdcard, only that the changes to the API in newer versions of Android prevented creation of top level folders under /sdcard. This article suggested to use 'Music':

https://www.reddit.com/r/androiddev/comments/jn5azi/android_11_dodges_a_bullet_apps_creating_a_folder/?utm_source=amp&utm_medium=&utm_content=post_body

I didn't think Music was appropriate for us, but Iooked on my developer images from Google on the latest version of Android and a few versions back (I only need to go back as far as until Android still lets me store to /sdcard/sword, because I try that next if /sdcard/Documents/sword fails), and on my physical phone, and they all had /sdcard/Documents/ available.

I am open to better suggestions.

Again, to sum up where I understand things now:

Android, pre-10 lets us store to /sdcard/sword

Android 10 was kind of a mess and wanted everyone to use the new storage api instead of file paths but still allowed /sdcard/sword

Android 11 and later, Google recanted because of pressure from the community and settled on: file path are officially blessed again, but no top level folders created by apps under /sdcard, so we need to choose a folder.

/sdcard/Documents/sword seemed to exist on all versions of Android I checked, later than the versions which still supported /SD card/sword, so I settled with the logic:

Try in this order to test write access to:

/sdcard/Documents/sword
/sdcard/sword
[private unshared app storage]/sword

That's my best attempt. If you have a better suggestion, I am all ears.

Troy

On October 3, 2021 10:56:34 AM MST, Tobias Klein <contact at tklein.info> wrote:
>Hi Troy,
>
>I can certainly consider /sdcard/Documents as a new base also for Ezra 
>(haven't tried it yet).
>
>I just did a quick search and I didn't find any official Android 
>documentation on that particular filesystem path. Is there something you 
>can point me to?
>
>Best regards,
>Tobias
>
>On 9/13/21 12:38 PM, Troy A. Griffitts wrote:
>>
>> Thanks Michael, yes, I also feel we need to not swim against the 
>> Google flow.  The problem is that the Google flow seems to turn at 
>> each new release of Android.  Be assured, my goal is to find a common 
>> means for us to share a single install of SWORD modules and to do it 
>> the way Google wants and for as many versions of Android as practical.
>>
>> Tobias,
>>
>> I've had no trouble writing to /sdcard/... from our C++ code, as long 
>> as I don't write to the root of /sdcard/.  My change from 
>> /sdcard/sword to /sdcard/Documents/sword/ works fine on Android 11.
>>
>> Can you give /sdcard/Documents/sword/ a try?  You can grab my exact 
>> C++ code from the cordova plugin if you have trouble.
>>
>> https://crosswire.org/svn/sword/trunk/bindings/java-jni/jni/swordstub.cpp
>>
>> static void init(JNIEnv *env);
>>
>> On 9/13/21 10:32 AM, Tobias Klein wrote:
>>>
>>> Dear Troy,
>>>
>>> We should certainly align on the directories and keep it simple.
>>>
>>> However, starting from Android 11 Google makes it really hard for us 
>>> due to the "Scoped Storage" concept, see 
>>> https://developer.android.com/about/versions/11/privacy/storage
>>>
>>> I couldn't figure out a way to write to /sdcard any more in my C++ 
>>> context on Android 11.
>>>
>>> As a consequence at the moment I am not using /sdcard from Android 11 
>>> anymore, but only the private app folder.
>>>
>>> For Android < 11 I am using */sdcard/sword*, but for Android >= 11 I 
>>> have completely disabled this including the permissions request for 
>>> WRITE_EXTERNAL_STORAGE.
>>>
>>> I wonder whether there is still any way to still use /sdcard/* in 
>>> Android >= 11 in the C++ context ... I haven't found a solution yet 
>>> and it seems rather complicated.
>>>
>>> Best regards,
>>> Tobias
>>>
>>> On 9/12/21 3:51 PM, Troy A. Griffitts wrote:
>>>> Dear all,
>>>>
>>>> I've been updating Bishop to work on newer versions of Android and have
>>>> found that we are running into problems trying to create the
>>>> "Nonstandard top-level folder" 'sword' at the root of the common storage
>>>> folder.
>>>>
>>>> Tobias, I know a while back you mentioned that you had to update Ezra
>>>> for Android recently, but it has been a long while since we talked about
>>>> it and I'd like to know if you've had any updated thoughts on what
>>>> you're doing there.
>>>>
>>>> Any other mobile Android devs have any thoughts.
>>>>
>>>> For now, I have updated our cordova plugin (and thus Bishop) to check
>>>> and if possible use paths in this preferred order:
>>>>
>>>> "/sdcard/Documents/sword"
>>>>
>>>> "/sdcard/sword"
>>>>
>>>> ((android.app.Application)
>>>> app).getApplicationContext().getFilesDir().getAbsolutePath();
>>>>
>>>> And we are augmenting modules from AndBible:
>>>>
>>>> "/sdcard/Android/data/net.bible.android.activity/files"
>>>>
>>>> ... but I'd prefer not to do this any longer, once we all agree and
>>>> implement storing files in a common location.
>>>>
>>>> Any thoughts?
>>>>
>>>> Troy
>>>>
>>>>
>>>> _______________________________________________
>>>> sword-devel mailing list:sword-devel at crosswire.org
>>>> http://crosswire.org/mailman/listinfo/sword-devel
>>>> Instructions to unsubscribe/change your settings at above page
>>>
>>> _______________________________________________
>>> sword-devel mailing list:sword-devel at crosswire.org
>>> http://crosswire.org/mailman/listinfo/sword-devel
>>> Instructions to unsubscribe/change your settings at above page
>>
>> _______________________________________________
>> sword-devel mailing list: sword-devel at crosswire.org
>> http://crosswire.org/mailman/listinfo/sword-devel
>> Instructions to unsubscribe/change your settings at above page

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://crosswire.org/pipermail/sword-devel/attachments/20211004/9c79a362/attachment.html>