I knew I was going to mess that up. The only way I get any files listed in Music Titles 4 is to have get global APK = true set when using companion. It does play the file but get a notice that it can't find the cue sheet.
All media is put on the device by the User, and the amount will grow overtime. Most times, the media is going to be directly transferred from a PC, via a card or USB.
The App plays the music and displays the cue sheet, it does not supply any media.
The interpretation of what media actually is certainly seems to depend on Industry. One of daughters is in the film industry and as far as they are concerned, HTML and PDF are media. Google seem to have a different point of view
There has to be a way to move onto the next part of the process. The best way is to use a Procedure to start the next stage, which I have not done, but this is a test snippet where the primary concern is to get the media loaded and running.
To access (read) a non-media file (like HTML) from one of the Shared folders (like /Documents/PlayMusic) on Android 11+ it must have been created by the app itself.
However, on Android < 11 it should work.
If the app has granted MANAGE_EXTERNAL_STORAGE permission it should work on all Android versions.
Hi Richard - you are missing the point about the APK setting. It should only be true if the App is running as an APK. It should only be false if the App is running via the Companion. See my screenshot, that's the App running as an APK - the Label telling us that is totally reliant on the manual setting of the APK variable, in this case set to True.
Run as an APK
Run via the Companion
I read recently that later this year Google will be putting another potential spanner in the works by releasing Android 12b specifically for tablets
Edit: It is running perfectly in Android 10 here
Edit: The accumulated cache data of an app can cause it to stop working. When such a thing happens, we need to reset the cache data from the device settings. So, if individual Android apps are not working on your phone, another solution to fix it is by clearing the app's cached data. I don't think this is the cause of the issue you see, but there is no harm in clearing the cache.
So why do think the snippet works on Android 11 but not on Android 10? (Probably not on Android 9 either, Richard has a v9 device to test on too).
The snippet is not using allfilespermission.aix, only the latest version 14a of TaifunFile.aix.
Something interesting - my phone is running Android 11 and nagging me to update to Android 12, but GetApiLevel_3.aix returns API 29, Android Version 10.
Edit: This because Huawei have hoax Android versions built on top of the Android 10 open source. They are still banned from Google upgrades by the USA government.
This works without MANAGE_EXTERNAL_STORAGE permission on all Android version < 11, but on Android 11+ only wthMANAGE_EXTERNAL_STORAGE permission (or the app must use SAF).
If you open the sample, they were created by Richard on a PC with Serif WebPlus8 - so essentially HTML4, fixed dimensions. I have modified Richard's sample so that it is responsive.
Well, my Android 11 phone (Huawei P30 Pro), which is actually my daughters, borrowed on a non-return basis, is actually Android 10 (Hoax Android 11)! - so that explains why the snippet is working. It should also mean it would work on Richard's Android 10 devices......
Ok, but what user would go to the trouble of creating HTML files like this for all MP3s (and I have thousands of them)? I definitely don't. So this is far from a viable solution (approach).
Well, if there isn't one, none will be listed. So where should the problem be?
Firstly, it can be done by basically filling in a form, and that form is then used to generate an HTML automatically (Desktop program). I assume that cue data is readily available for popular recordings so it could be a conversion or copy and paste exercise.