- Extend NSBundle resources support to handle directories in Android assets.
- Fix NSFileManager -isReadableFileAtPath: to also support directories in Android assets.
Requires passing the activity's AssetManager object from Java to GNUstep by calling +[NSBundle setJavaAssetManager:withJNIEnv:], which then enables the following features:
- NSBundle main bundle resource paths support for Android assets, e.g. for pathForResource:ofType:, URLForResource:ofType: and related methods.
- NSBundle main bundle info dictionary support if Info.plist exists in Android assets.
- -initWithContentsOfFile: and related methods support for reading Android assets from main bundle in various classes (e.g. NSData, NSDictionary, NSArray, etc.).
- NSFileManager fileExistsAtPath:(isDirectory:) and isReadableFileAtPath: return YES for main bundle asset / asset directory paths.
- NSFileHandle support for reading Android assets from main bundle.
- NSDirectoryEnumerator support for enumerating Android assets from main bundle. Note that recursion into subdirectories is currently not supported by the native Android asset manager API (see https://issuetracker.google.com/issues/37002833).
Also adds support for automatic NSProcessInfo initialization on Android with a fake executable path "/data/data/<app identifier>/exe" (as Android apps don't have a real executable path), and tweaks main bundle initialization to allow that path. Main bundle resource paths are prefixed by "/data/data/<app identifier>/Resources".
Implement a method for getting attribytes of a file system path. Reuse
the implementation of -fileSystemAttributesAtPath: for this purpose but
export the last system errors to the caller. Make
-fileSystemAttributesAtPath: use the new implementation, without
exposing error info to the caller.
Create NSFileManagerDelegate, a more modern manner to verify whether to
proceed a file operation after an error or whether an operation should
actually be performed by NSFileManager.
No functionality using the delegate is yet implemented.
