World: r4wp

If the automation script I'm working on work, you'll be able to generate 
an APK without download the SDK and JDK! ;-)

I don't want to use Eclipse, nor any other SDK :-( Willing to use 
command-line tools as javac etc. Btw - I use Android Studio, so actually 
wonder, if I would be able to do it using it instead of Eclipse ...

Just wait an hour more to see if I can finish the automatic building 
toolchain...

Believe me, Eclipse is actually much easier to compile/build/test 
an android app than manually calling the command-line tools.

I know, it is just that I am multiplexing between work, red, creating 
ads for my led screen, photo shooting, photo editing, video editing. 
So basically I just jump here or there, and right after I was suggested 
to use Android Studio last month, because - it comes from Google, 
I am now supposed to install yet another toolchain. Last month I 
also installed my Visual Studio 2013 and got really scared by the 
complexity of all that stuff, that comes with it ....

So - I can wait, but maybe not, I am fast at trying new stuff and 
making my Window8 installation even more messy with constantly trying 
new SWs :-)

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