We published this Chadian Arabic Bible (Roman script) app as version 2.3 last August:
We had some minor changes to the Scripture texts and a couple of formatting fixes that we wanted to make, so we made the changes and built a new version and posted it to Scriptoria. I gave it a test and everything looked good, but someone else tested it and the app could not find the audio files - it required them to be downloaded. We have since tested on two other devices, and they can’t find the audio files either.
So to make clear what we are seeing… Someone with the current Play Store version 2.3 (built with SAB 12.0) has the entire audio folder (1189 chapters), and playing audio works fine. The audio folder has usually been placed in the root, on an SD card or in the Music folder, and version 2.3 finds it in all of those places just fine. They update the app to the test version 2.5 (built with SAB 12.4), open the app and try to play audio, and it asks to download the audio file. If you download the audio it puts it into \Android\data\org.ipsapps.chad.shu.bible.latn\files\Bible-Arabe-SHU-Audio (not surprising) and plays it. If we add other audio files to that folder the app does find them and can play them, but it won’t find audio files elsewhere.
BUT, on my phone, for whatever reason, if I have v2.3 installed (and all the audio files) then update to v2.5, it still finds the audio files just fine. My audio files are on the root of an SD card, and I don’t think the other test devices had the files there - probably mostly in the Music folder of the main Phone - but that doesn’t seem like it should make a difference. I also verified on my phone that the \Android\data\org.ipsapps.chad.shu.bible.latn\files folder is empty (so no cheating with two copies of the audio files…).
Can anyone explain what’s going on? I can’t think of a reasonable explanation… And obviously we can’t publish our update if only 1 out of 4 tests pass.
I’ve asked our Kalaam “handler” if he can send me the SAB project folder as it was for v2.3. I was thinking of trying to compare the contents of the two projects, and seeing if some setting got changed inadvertently. But as far as I can remember, nothing changed in the audio settings.
For anyone who would like to test this, I have prepared a “Bible App Test” folder on Google Drive:
You can download the Bible-Arabe-SHU-Audio folder from that test folder and put it on your Android device: suggested locations are in the root of your Android device, in the Music folder, or on an SD card. (It only contains the audio files for the book of James for this test.) Then download and install the Bible in Chadian Arabic (Roman script) app from the Play store (link above, version 2.3), navigate to the book Yaakhuub (Jacques), and try to play the audio, I think it should probably work, no matter where you put the audio folder.
Then download from the test Drive folder the file Al-Kitaab_al-Mukhaddas-2.5.apk and install this update on your Android device. Then try again to play the audio in James. On 3 out of 4 test devices (so far), it doesn’t find the audio folder, and requests to download the audio, which it then puts in the org.ipsapps.chad.shu.bible.latn\files folder.
We are blocked from publishing this update until we can resolve this problem.
I just had a very fruitful discussion with @ChrisHubbard and we may have found the problem. I didn’t mention in the posts above that the audio files are .webm files. (Our .webm files are one third the size for basically the same quality, so why wouldn’t we always choose to use .webm files?) It turns out that there was an “improvement” in SAB 12.2.4:
Well, it appears that without this READ_MEDIA_VIDEO permission, the app can’t search for .webm files. (Our .webm files only contain audio, but because they are in a .webm container, they are considered video files.) So .webm files can only be downloaded and managed in the org.ipsapps.chad.shu.bible.latn\files folder mentioned above.
This would be a serious limitation, so I’ve written to @richard to see if the new data manager might allow the user to select the audio folder, so even if the app can’t search for the .webm audio files, it can still find the audio files in some place that’s not just the private app storage location (which would be messy for manually copying the audio folder to).
Our theory for why the app can still find the audio files on certain phones is that maybe on old versions of Android the READ_MEDIA_VIDEO permission is ignored. We’re still researching that.
I would be surprised if this is a situation unique to us… Do you have an app that uses .webm audio files in an external folder? Has your app been compiled with SAB 12.2.4 or later? Can the app find and play audio files when run on a fairly new Android device (let’s say Android 13-14 or greater)? It would be wise to check…
It appears that I’ve had my head in the sand, as there are a couple of other places where this issue was discussed, e.g.:
I guess I hadn’t made the connection between this issue and the ability to read .webm files. (Audio in .webm containers is considered as video in Android.)
In communications with @ChrisHubbard and @richard, it was acknowledged that this issue is a problem for apps that rely on large numbers of .webm audio files that are not just downloaded. For example, the Chadian Arabic Bible app has 1189 chapters of audio (~750Mb in .webm files) that are usually transferred to the Android device as a block, the folder copied from a computer, or passed from device to device with Xender. It’s not reasonable to expect users to place the audio folder precisely here: \Android\data\org.ipsapps.chad.shu.bible.latn\files for the app to access those audio files.
So Richard has said that they will add an option in the upcoming 12.5 release of SAB to add that READ_MEDIA_VIDEO permission back into the app. Selecting that option to add this permission back in will again allow the app to search for the .webm audio files, wherever they are on the device. But the drawback (as explained in the second of the links in the previous post) is that when you post to the Play Store, Google will likely initially reject your submission until you explain why you need that READ_MEDIA_VIDEO permission. There are some examples in that link of explanations that have worked. I propose the following, which is a bit more precise in why the permission is required:
This app plays synchronized audio for the included Scripture text. The highly compressed audio is stored in .webm containers in an external audio folder. Since .webm files are classified as video, the app requires the READ_MEDIA_VIDEO permission to find and play these files. No external files are modified; the app only locates the audio folder and plays the audio files contained within.
So I assume that when we submit the updated app with the READ_MEDIA_VIDEO permission, it will initially be rejected by Google (because of the permission required), and I’ll suggest to the Kalaam folks to give the rationale above, and see if it works.
And in case you are wondering, we did confirm in our testing that all Android devices up to Android 12 work fine without the READ_MEDIA_VIDEO permission, i.e. the app doesn’t seem to use or require the permission to access the audio files. So our app test version 2.5 finds the audio files on these versions of Android. But on Android 13+ the audio files cannot be found with the test app, because the READ_MEDIA_VIDEO permission was not granted. So that explains why the test version was finding the audio files on some devices but not on others. Mystery solved!
Version 12.5 of SAB now has an option in Media > Audio > Downloads where you can specify that WebM files should be stored in the shared media store folder. As soon as you select that option, a warning paragraph appears below the option:
We have now tested this with our Chadian Arabic Bible apps, and the test versions (with this option selected) are able to find the videos, even with recent versions of Android.
When Kalaam posted the apps to the Play Store, the console did present a form to fill out describing the app’s use of 2 permissions. We gave the following explanations (slightly shorter than what I gave above, since the explanations are limited to 250 characters):
READ_MEDIA_IMAGE permission:
This app allows the creation of a Scripture verse on an image to share on social media. The user may select a background image from their device, requiring the READ_MEDIA_IMAGE permission. No external files are modified.
READ_MEDIA_VIDEO permission:
This app plays synchronized audio stored in compressed .webm containers in an external folder. Since .webm files are classified as video, the app requires the READ_MEDIA_VIDEO permission to find and play these files. No external files are modified.
Thank you @richard and @ChrisHubbard for providing a solution for our many users who access a .webm audio folder external to the app.
