Thanks for the report. Unfortunately, I am not able to reproduce this at the moment because I do not have an external SD card on my Android devices (and the Android emulator does not work on my PC). However, I can confirm that it is not possible to access files on a USB stick connected to an Android device. Access to such files is only possible through a content provider. Kid3 is a portable application written in C++, and it and all the 3rd party libraries it uses access the files via a standard C file system API. Access to files which are not on real mounted file system is not possible. I suppose that getting access via a content provider would mean copying the file to another location, then edit it and finally copy it back. When this has to be done multiple times, it is probably more efficient to manually copy the files to internal storage in order to edit them. Or maybe there is some other possiblity in Android I am not aware of.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have now installed an external SD card and can confirm two bugs:
It is not possible to open a file from the SD card when using "Open with Kid3" from the system file browser, but it is possible from within Kid3 (Open, then selecting the SD card in the "three vertical dots" menu).
When changing a tag and then using "Save", nothing happens with files from the SD card
I will have a look at it.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
As I feared, it is not possible to completeley get rid of this problem. Kid3 is a cross-platform application written in C++ and the libraries it is using to tag audio files need normal file system access, and not a special API like the storage access framework in Android.
The good thing is that there is a workaround: Android still grants access to files inside application private directories, so what you have to do is to create a folder Android/data/net.sourceforge.kid3/ on the SD card. Probably such a folder was already created by Android, and inside this folder other directories such as files/Music/, which would be a good place to store audio files which can be edited by Kid3. There does not seem to be a way to have a shared folder on the SD card without using the storage access framework.
The restrictions for access to files on an external SD card have been made stricter with later Android versions. On a device with Android 7, I am able to open files anywhere on the SD card using Kid3, I have now fixed the problem that files from the SD card could not be opened in Kid3 from the file manager. But saving is only possible inside the private folder mentioned above. Kid3 will now display a message when trying to save outside of that folder. On a device with Android 9, I am not able to open a file outside of the private folder, so with late versions of Android, you will have to move the files into Android/data/net.sourceforge.kid3/ before trying to open them in Kid3.
If you would like to test it, there is a development snapshot kid3-git20190716 in the development folder. Note that I increment the version code only for official releases, so you will have to uninstall version 3.7.1 before installing version git20190716.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for the report. Unfortunately, I am not able to reproduce this at the moment because I do not have an external SD card on my Android devices (and the Android emulator does not work on my PC). However, I can confirm that it is not possible to access files on a USB stick connected to an Android device. Access to such files is only possible through a content provider. Kid3 is a portable application written in C++, and it and all the 3rd party libraries it uses access the files via a standard C file system API. Access to files which are not on real mounted file system is not possible. I suppose that getting access via a content provider would mean copying the file to another location, then edit it and finally copy it back. When this has to be done multiple times, it is probably more efficient to manually copy the files to internal storage in order to edit them. Or maybe there is some other possiblity in Android I am not aware of.
I have now installed an external SD card and can confirm two bugs:
I will have a look at it.
As I feared, it is not possible to completeley get rid of this problem. Kid3 is a cross-platform application written in C++ and the libraries it is using to tag audio files need normal file system access, and not a special API like the storage access framework in Android.
The good thing is that there is a workaround: Android still grants access to files inside application private directories, so what you have to do is to create a folder Android/data/net.sourceforge.kid3/ on the SD card. Probably such a folder was already created by Android, and inside this folder other directories such as files/Music/, which would be a good place to store audio files which can be edited by Kid3. There does not seem to be a way to have a shared folder on the SD card without using the storage access framework.
The restrictions for access to files on an external SD card have been made stricter with later Android versions. On a device with Android 7, I am able to open files anywhere on the SD card using Kid3, I have now fixed the problem that files from the SD card could not be opened in Kid3 from the file manager. But saving is only possible inside the private folder mentioned above. Kid3 will now display a message when trying to save outside of that folder. On a device with Android 9, I am not able to open a file outside of the private folder, so with late versions of Android, you will have to move the files into Android/data/net.sourceforge.kid3/ before trying to open them in Kid3.
If you would like to test it, there is a development snapshot kid3-git20190716 in the development folder. Note that I increment the version code only for official releases, so you will have to uninstall version 3.7.1 before installing version git20190716.
Is now fixed in version 3.8.0.