Documentation update

ANDROID.md

@@ -60,7 +60,7 @@ The following emulators are configured for FileProvider access:
 * GBA.emu
 * GBC.emu
 * Lynx.emu
-* MD.emu
+* MD.emu (genesis, mastersystem, megadrive, megadrivejp)
 * MAME4droid 2024
 * MAME4droid
 * NES.emu
@@ -440,6 +440,13 @@ This PlayStation Vita emulator can be downloaded from their GitHub site. Refer t
 
 https://github.com/Vita3K/Vita3K-Android/releases
 
+### Yaba Sanshiro 2
+
+This emulator can be installed from the Play store, there is a paid Pro version as well. At the time of writing only the Pro version works when launching games from ES-DE. Also note that .bin/.cue files can't be launched for the time being, only .chd files seem to work. This needs to be fixed in the emulator so nothing can be done in ES-DE to work around that limitation.
+
+https://play.google.com/store/apps/details?id=org.devmiyax.yabasanshioro2 \
+https://play.google.com/store/apps/details?id=org.devmiyax.yabasanshioro2.pro
+
 ## Device compatibility
 
 This is clearly not a complete list of Android devices, but rather those we know have been tested with ES-DE and for which there is a known status.

CHANGELOG.md

@@ -1,5 +1,19 @@
 # ES-DE Frontend - Changelog
 
+## Version 3.0.3 (in development)
+
+**Release date:** TBD
+
+### Release overview
+
+### Detailed list of changes
+
+* (Linux, macOS and Windows) Added support for the new Lime3DS binary names
+* (Linux) Added support for the Flatpak release of Lime3DS
+* (macOS) Changed the minimum required OS version from 10.15 "Catalina" to 11 "Big Sur"
+
+### Bug fixes
+
 ## Version 3.0.2 / 3.0.2-21
 
 **Release date:** 2024-05-13

FAQ-ANDROID.md

@@ -47,7 +47,7 @@ Yes, as of ES-DE 3.0.2 there is experimental support for launching native Androi
 
 ## Every time I reboot my device ES-DE is starting the onboarding process, why is this happening?
 
-If you have set ES-DE as your home app then for some devices the onboarding configurator is displayed after booting your device. This happens because of an issue in the Android operating system where apps are started before the SD card has been mounted. When ES-DE starts it will obviously try to access the ES-DE and ROMs directories that it needs to function, but if either of these have been placed on an SD card that is not available, then the application assumes that the storage has been permanently removed and runs the onboarding process again. This is normal and intended behavior. On app startup ES-DE will however check if the SD card has been mounted, and it will wait up to 4.5 seconds for the storage to become available before it gives up and displays the configurator. For the overwhelming amount of cases this time is enough to handle reboots without issues, but some SD cards of larger sizes apparently need more time than this to get mounted, which triggers the failure mode. But note that you don't need to run through the entire onboarding process if this happens, it's enough to just press B or the back button, just make sure to wait a sufficient amount of time for the SD card to first get mounted. Unfortunately this issues is impossible to resolve on the application layer, it's an operating system defect and it needs to be fixed by Google. Setting a higher retry time than 4.5 seconds will make Android report ES-DE as non-responding, so that's unfortunately not a viable solution either.
+If you have set ES-DE as your home app then for some devices the onboarding configurator is displayed after booting your device. This happens because of an issue in the Android operating system where apps are started before the SD card has been mounted. When ES-DE starts it will obviously try to access the ES-DE and ROMs directories that it needs to function, but if either of these have been placed on an SD card that is not available, then the application assumes that the storage has been permanently removed and runs the onboarding process again. This is normal and intended behavior. On app startup ES-DE will however check if the SD card has been mounted, and it will wait up to 4.5 seconds for the storage to become available before it gives up and displays the configurator. For the overwhelming amount of cases this time is enough to handle reboots without issues, but some SD cards of larger sizes apparently need more time than this to get mounted, which triggers the failure mode. Note that you don't need to run through the entire onboarding process if this happens, it's enough to just press B or the back button, just make sure to wait a sufficient amount of time for the SD card to first get mounted. Unfortunately this issues is impossible to resolve on the application layer, it's an operating system defect and it needs to be fixed by Google. Setting a higher retry time than 4.5 seconds will make Android report ES-DE as non-responding, so that's unfortunately not a viable solution either.
 
 ## What game systems/platforms and emulators are supported by ES-DE?
 
@@ -85,7 +85,7 @@ No Android may stop applications that are not currently focused if it needs to r
 
 ## ES-DE takes a very long time to start, is there a way to improve this?
 
-Unfortunately disk I/O performance on Android leaves a lot to be desired compared to desktop operating systems. Google has repeatedly prioritized other things over performance which leads to disk speed being poor on this operating system. The biggest offender is the choice of FAT filesystems such as exFAT for external storage which offer abysmal performance for some file operations on which ES-DE relies heavily. Generally speaking a small to medium ROM collection can normally be placed on a FAT-formatted device such as an SD card but the ES-DE directory and more importantly the _downloaded_media_ directory should always be placed on internal storage. For large game collections ES-DE could turn borderline unusable if the ES-DE directory is placed on an SD card or USB memory stick. It's also possible to enable the _Only show games from gamelist.xml files_ option in the _Other settings_ menu to skip checking for game files on startup, but this has multiple implications such as what's displayed inside ES-DE not necessarily reflecting reality any longer. And obviously you'll need gamelist.xml entries for all games you want to show up inside ES-DE. So this option is really a last resort and is generally only recommended for testing purposes. In summary huge game collections are discouraged on Android due to limitations in the operating system itself. Setting up a collection of tens of thousands of games is for sure achievable with ES-DE on Linux, macOS or Windows but it's not really feasible on Android.
+Unfortunately disk I/O performance on Android leaves a lot to be desired compared to desktop operating systems. Google has prioritized other things over performance which leads to disk speed being poor overall on this operating system. The main offender is the choice of FAT filesystems such as exFAT for external storage which offer very poor performance for some file operations on which ES-DE relies heavily. Generally speaking a small to medium ROM collection can normally be placed on a FAT-formatted device such as an SD card but the ES-DE directory and more importantly the _downloaded_media_ directory should always be placed on internal storage. For large game collections ES-DE could turn borderline unusable if the ES-DE directory is placed on an SD card or USB memory stick. It's also possible to enable the _Only show games from gamelist.xml files_ option in the _Other settings_ menu to skip checking for game files on startup, but this has multiple implications such as what's displayed inside ES-DE not necessarily reflecting reality any longer. And obviously you'll need gamelist.xml entries for all games you want to show up inside ES-DE. So this option is really a last resort and is generally only recommended for testing purposes. In summary huge game collections are discouraged on Android due to limitations in the operating system itself. Setting up a collection of tens of thousands of games is for sure achievable with ES-DE on Linux, macOS or Windows but it's not really feasible on Android.
 
 ## On game launch RetroArch runs an old game instead of the one I just selected, how do I prevent this?
 
@@ -106,4 +106,4 @@ ES-DE is not a good match for gesture navigation, there are a lot of contextual
 
 ## Why does ES-DE need to have permissions to manage my storage?
 
-ES-DE needs the storage permissions (MANAGE_EXTERNAL_STORAGE) to manage storage because it's well.. a storage manager. It handles your library of games and media which can easily be tens or even hundreds of thousands of files, and this may span across multiple storage devices as for instance scraped media could be relocated to an SD card or the ROMs moved to another device than the application data directory. During development substantial work was spent on attempting to work around the Android security model without having storage manager permission. Although this was partially successful it never worked 100% due to additional restrictions introduced in Android 13. The approach was to pipe file operations from the native C++ code via JNI to Java and translate them to SAF/MediaStore file operations. And be aware that ES-DE depends on a large amount of C and C++ libraries that have no awareness of or support for the Storage Access Framework or Media Store subsystems in Android. Even if it would have worked 100% this would have lead to unacceptable performance issues as a lot of translations were needed, for instance Java uses "filtered" UTF8 Unicode while C++ doesn't so everything would need to be translated by the UTF8-CPP library. In addition to this an undocumented feature of the FileProvider API is that you can't provide access to files you don't own, even if you have read/write access to them using scoped storage permissions. As the FileProvider API is the future of emulator launching since it removes the need to setup scoped storage access individually in each emulator, it would break a very important feature to not have storage manager access. There are more issues on top of what has just been described, but these are the most important considerations.
+ES-DE needs the storage permissions (MANAGE_EXTERNAL_STORAGE) to manage storage because it's well.. a storage manager. It handles your library of games and media which can easily be tens or even hundreds of thousands of files, and this may span across multiple storage devices as for instance scraped media could be relocated to an SD card or the ROMs moved to another device than the application data directory. During development substantial work was spent on attempting to work around the Android security model without having storage manager permission. Although this was partially successful it never worked 100% due to additional restrictions introduced in Android 13. The approach was to pipe file operations from the native C++ code via JNI to Java and translate them to SAF/MediaStore file operations. And be aware that ES-DE depends on a large amount of C and C++ libraries that have no awareness of or support for the Storage Access Framework or Media Store subsystems in Android. Even if it would have worked 100% this would have lead to unacceptable performance issues as a lot of translations were needed, for instance Java uses "filtered" UTF8 Unicode while C++ doesn't so everything would need to be translated by the UTF8-CPP library. In addition to this an undocumented feature of the FileProvider API is that you can't provide access to files you don't own, even if you have read/write access to them using scoped storage permissions. As the FileProvider API is very useful for emulator launching since it removes the need to setup scoped storage access individually in each emulator, it would break a very important feature to not have storage manager access. There are more issues on top of what has just been described, but these are the most important considerations.

USERGUIDE-DEV.md

@@ -679,7 +679,7 @@ The following emulators are supported in AppImage format when using the bundled
 | macintosh     | Basilisk II         | BasiliskII*.AppImage           |
 | macintosh     | SheepShaver         | SheepShaver*.AppImage          |
 | n3ds          | Citra               | citra-qt*.AppImage             |
-| n3ds          | Lime3DS             | lime-qt*.AppImage              |
+| n3ds          | Lime3DS             | lime3ds-gui*.AppImage          |
 | n3ds          | Panda3DS            | Alber-*.AppImage               |
 | n64/n64dd     | Rosalie's Mupen GUI | RMG*.AppImage                  |
 | ngage/symbian | EKA2L1              | EKA2L1*.AppImage               |