World: r4wp

Hmm, can't avoid Java dependency...maybe I should be able to use 
the preinstalled JRE on Windows platforms, but not sure...

Nevermind, in any case, some description of how to proceed, is going 
to be needed. But it is a pity, as it pushes us to the different 
land, where no more the claim of sel-contained dev environment is 
true. Now we are in a lend of - do regular Android JAVA development 
and use Red DLL, when handy ...

issue #492 added on https://github.com/dockimbel/Red/issues?state=open

Ok build script pushed. You need to have JDK (correctly) installed 
currently for the script to work.

The jarsigner tool needs to access the Java runtime...we'll remove 
that dependency partially or fully in the future.

Holly crap! That works!

Haha :)

Just generated APK, it downloaded some tools (not sure it is cross-platform, 
but on Windows it works), then I thought it hanged, but there was 
a dialog requesting ability to write to dics, then lots of output 
in console, now uploaded apk to my server, and tried on my HTC Sensation! 
Nice dark theme!

Just wrote it in a hurry, I need to take a bus in about an hour...

Will work on the slides from this afternoon until Sunday.

That has to be facebooked!

Yeah, see the commit log, only Windows for now. Will add other platforms 
support tonight.

Outputs in console: you can disable it by setting verbose to false 
in the build script. I've left the verbose mode to make it easier 
for first testers to report errors.

Go facebook it, it should already be PRISM-ed anyway. ;-)

what was the site for the emulators online?

The first time the scripts runs, it download copies of binaries from 
the Android SDK, so it can take some seconds depending on your connection.

https://www.manymo.com

But that won't work with the apk you've buit, that online emulator 
requires x86 code.

btw - observed some delay, when app starts. dunno if for the first 
time, but few secs before prompt and button appears ...

You need to change a few things in the build script to generate x86 
apk.

ah, ok ...

Delay: yes, I need to optimize the starting process, it can be a 
bit slow on older devices.

For building an x86 system compatible apk, the following changes 
are required in the build script:


make-dir/deep bin-dir/lib/armeabi => make-dir/deep bin-dir/lib/x86
-t Android
 => "-t Android-x86"
/libRed
 => "Red"

Erratum: this change is not required: "/libRed" => "Red"

HTC Sensation is not a slow device, everything runs fast :-)

I have a Cortex A9 device (USB stick form factor) where the starting 
delay is not noticeable. Anyway, I just need to rearrange the bridge 
low-level code to make it much faster, not a problem.

hm, thought that app is going to be named after the apk name, but 
apparently not - eval.apk -> Red on Android

I uninstalled older coppies, now it seems to start in cca 1 sec. 
Good enough ...

OK, you made my day, so - donated 50EUR ;-)

Ah thanks! Good initiative! :-)

No, naming happens at several levels...Also Window title <> app name. 
:-)

We'll step by step abstract all those little details, so you'll be 
able to specify your whole app parameters from Red only without having 
to touch any Android XML file.

we could use a Rebol header format for that somehow maybe, so that 
it could be part of the program, no need of special config file?

x86 version generation worked well, but the .apk does not work. I 
can see x86 dir, which is empty though. Shouldn't it contain a DLL?

hmm, renamed apk to zip, I can see x86 is not incluede in the package, 
just armeabi dir containing .so library ... needs some other tweaks 
....

Managed to produce an apk, which contains x86 + arm version of demo, 
and it works on both targets!

In order to be able to generate x86 target, do the following:

- copy %build.r into %build-x86.r


- change make-dir/deep bin-dir/lib/armeabi => make-dir/deep bin-dir/lib/x86

- change "-t Android" => "-t Android-x86"


- change "rejoin [%../red/bridges/android/ bin-dir/lib/armeabi" => 
"rejoin [%../red/bridges/android/ bin-dir/lib/x86"


- run %build-x86.r - generates an apk and if you ran arm version 
previously, will pack both versions into one .apk

Bo, the above suggestions are all good. Your code looks OK until 
you start generating the third result image

img3: as-binary size1

is not the way to allocate an image. as-binary is just a type cast, 
like as-integer, not a declaration

So you're pointing img3 to a semi-random memory area that happens 
to have an address equal to the size of the first image. That will 
crash the first time you try to access the image

The correct way to allocate space would be

img3: allocate size1

and then you would have to check for a possible NULL result. Look 
inside the code of read-file-binary to see how that works

You also need to check the return values of read-file-binary and 
write-file-binary, as Arnold already mentioned

After you're done with img3, you should FREE the allocated memory. 
The same for img1 and img2 because the memory was allocated for you 
by read-file-binary

Alternatively, you could reuse either img1 or img2 to produce the 
result image if you don't need them afterwards. That would save the 
allocation and freeing of the third image

To make the algorithm foolproof, you could also check that size1 
and size2 are equal

Apart from the use of as-binary, everything should work. :-) I guess 
you were thrown by the initialisations:

img1: as-binary 0