Look for locale files in main bundle on Android

[hmelder]

On Android, we do not have a system-wide GNUstep installation and thus not
a 'gnustep-base' library bundle. Search the main bundle (the resource path of an Android app) for Languages/Locale.aliases instead.

#484 tracks a revamp of the config infrastructure

[rfm]

As discussed in #484, this seems to duplicate a small part of the existing functionality to flexibly deploy all resources in the app bundle, and we should avoid duplication.
Unless I'm missing something, instead of a system-specific hack for android, they could/should just use the normal standalone/relocatable layout (resource paths relative to the base library within the application bundle).

[rfm]

PS. look at standalone.conf (a quick example standalone layout) or at the copious detail in the Base documentation on the GNUstep configuration file (particularly the part about relocatable/standalone config).

[triplef]

@hmelder what kind of language string are we getting back from the system on Android? We’ve never actually shipped the "Languages" resources with our app on either Android or Windows, and if I understand correctly here it’s only needed to map language codes like "en" to "English" in case the app still uses localized resources using the old-style long names like "English.lproj" (which we don’t). So just for our own case I don’t think we should need to fix loading of the Languages resources in order to fix our issue. Maybe the first commit was already sufficient for our case?

Regarding the config / file system layout, we’re already using this customized layout on Android. What’s tricky about Android though is that everything is bundled into an APK, and so neither libraries nor resources are actually in a normal file system, but instead have to be accessed via the "AAsset" API which reads them directly from the APK. We deal with this as best as we can by having the main bundle automatically check for resources in the APK as well (via [NSBundle assetForPath:]), but since the Languages resources are searched for in the gnustep-base bundle instead of the main bundle, I don’t currently see how the system could work for Android as-is. But maybe there’s a better way than hardcoding _gnustep_bundle to the main bundle @rfm?

[rfm]

This is probably what's causing problems: What’s tricky about Android though is that everything is bundled into an APK, and so neither libraries nor resources are actually in a normal file system, but instead have to be accessed via the "AAsset" API which reads them directly from the APK. Now I assume that the base library and the application, sharing the same APK, have some means of identifying resources within the APK, and I would hope that this works broadly like a filesystem (a hierarchical structure within the APK). On other platforms, in a standalone config paths of the form ./a/b refer to item b in folder a relative to the base library. To me the obvious analogue for android would be that the AAsset based resource lookup code should treat that path as meaning item b within folder a within the APK or something similar. In other words, the dot ('.') at the start of the relative path should be interpreted by the android specific code as meaning the location of the root of the resource hierarchy within the APK.

…

[triplef]

Ah yes of course, that might actually already work. We should check if placing the language resources in gnustep-base/Languages in the APK resources makes this work.