Re: Android: How to call GSInitializeProcess() properly?

[Ivan Vučica]

Hi Richard,

thanks for the response. I've played a bit further and looks like this is enough to set up GNUstep. Turns out that GSPrivateExecutablePath() doesn't need modification.

    NSString * cmdline = [NSString stringWithContentsOfFile: [NSString stringWithFormat: @"/proc/%d/cmdline", getpid()]];

    NSString * identifier = [[cmdline componentsSeparatedByString: @" "] objectAtIndex: 0];

    NSString * home = [NSString stringWithFormat: @"/data/data/%@", identifier];

    NSString * exe = [NSString stringWithFormat: @"%@/exe", home];

    FILE * f = fopen([exe UTF8String], "w"); if(f) fclose(f);

    NSString * path = [NSString stringWithFormat: @"PATH=%@", home];

    NSString * home2 = [NSString stringWithFormat: @"HOME=%@", home];

    const char* argv[1] = { [exe UTF8String] };

    const char* env[4] = { "USER=android", [home UTF8String], [path UTF8String], NULL };

    

    GSInitializeProcess(1, argv, env);

I've chucked this in the initialization function (which, with the example for using NativeActivity class provided in documentation, is android_main()).

I've hoped this might help with NSMutableDictionary issues (that something gets initialized) but apparently that isn't the case. Oh well.

On Thu, Jun 12, 2014 at 11:44 AM, Richard Frith-Macdonald <rfm@gnu.org> wrote:

On 12 Jun 2014, at 11:27, Ivan Vučica <ivan@vucica.net> wrote:

> Hi,
>
> as you may know, any native code in Android GUI applications must be delivered as a shared object.
>
> So, there is no main() and there is no executable. There is also no bundle that the binary can be delivered in, and we might only fake HOME by providing the application's data directory. (I temporarily use /.)
>
> Based on previous discussions on this list, I've thrown together a fake call to GSInitializeProcess():
>
>     const char* argv[1] = { "gnustep-app" };
>     const char* env[3] = { "USER=android", "HOME=/", NULL };
>     GSInitializeProcess(1, argv, env);
>
> Sadly:
>
>     I/gnustep-app( 6739): 2014-06-12 10:25:35.191 gnustep-app[6739] NSBundle.m:396  Assertion failed in NSString *GSPrivateExecutablePath().  NSInternalInconsistencyException
>
> Any existing approach to dealing with there-is-no-executable situation?

I don't know of any (and would be surprised if anyone has done it).

The GSPrivateExecutablePath() function to locate the running executable is key to finding relative/relocatable configuration information (GNUstep.conf) and therefore finding where the program is installed and hence where/how to handle the parts of the OpenStep/Cocoa API dealing with file/resource locations.

So ... I imagine we actually need specific new code in base to handle this for android.
I don't know the android APIs at all but I do know (from using a phone and reading a bit) that.
1. apps normally store their data on the internal phone memory, but can usualy be moved to the sd card
2. in the latest android release, the app data on the sd card is forced to live in a fixed folder location

That suggests to me that android must provide an api for determining what folder the app and its data lives in ... so I guess GSPrivateExecutablePath() would need to be modified to point to a dummy/fake executable within that folder, and anything using it would need to be modified to cope with the fact that the executable itsself might not actually be there; probably little to do since I guess mostly code will likely just remove the last path component (the name of the executable) and use the remainder as a starting point to find resources.
The base library could then be configured with default relative paths (from GNUstep.conf) and would locate resources using those relative paths.

On the other hand, it might make more sense to change all the bundle/path utilities code to use the corresponing android APIs (probably a lot more work though).

--

Ivan Vučica

ivan@vucica.net