Android Status

[Joakim via Digitalmars-d-learn]

On Monday, 9 January 2017 at 18:38:01 UTC, Ignacious wrote:
> On Monday, 9 January 2017 at 08:28:04 UTC, Joakim wrote:
>> I've tried to write up detailed instructions on the wiki.  I'm 
>> still improving those and plan to spin off those two sections 
>> I linked you, on how to just build the samples, into their own 
>> page.  You can contribute any steps you had to take with 
>> Bash/Ubuntu on Windows with the prebuilt linux/x64 
>> cross-compiler there, once I put the page up.
>
>
> Yeah, I found it a bit confusing though. It seems like it is 
> written up by someone that is working on the core rather than a 
> newb! ;)

Yep, that's what it is.  That's one reason why I want to add 
another wiki page which will just focus on building the sample 
apps, as opposed to building the cross-compiler too.

>>> The main problem I have had seems to be that UoW uses ver 14. 
>>> Somehow I was able to upgrade by following docs online(wasn't 
>>> easy but eventually got there and everything seems to work... 
>>> I should have documented ;) but I wasn't sure if the process 
>>> would work. Supposedly ver 16 exists by one has to be part of 
>>> the dev team or something.
>>
>> If you know all the steps to upgrade Ubuntu on Windows, you 
>> may want to document them on the wiki page I will put up or 
>> link to a good resource that shows how to do it.
>
>
> I don't because it was all new to me(I didn't know there was 
> even such a thing as UoW.  I simply searched for the errors I 
> got and tried different solutions until it worked. Luckily the 
> outcome worked... which is not always the case.

Is it easy for you to nuke it and go back to the original 14.04 
setup?  I may be able to remove some of those ldc library 
dependencies, so that it works on the original setup too.

> I think that it would be a boon for D to have some type of well 
> defined and well planned Android development suite rather than 
> what seems to be hacked/cobbled together. This would bring not 
> only more developers to D for android but also to D in general.

Yes, definitely the plan.  The big problem right now is that it 
requires a slightly modified llvm.  If that weren't needed, we 
could just have the official release builders also build the 
standard library for Android/ARM on their OS.

> I'm gonna try the opengl examples and hopefully the work. The 
> main problem I see is how to actually write "commercial" apps 
> using D for android. Can it be done successfully? Nobody knows 
> because there isn't a history. What are the exact steps, say, 
> to add ads, or interface with the subsystem? I saw that there 
> is some way to call some java stuff from D but seems like 
> nothing is thoroughly tested(most of the work as been just 
> trying to get things up and running).

I got interfacing with Java working late last year, through JNI.  
Not "thoroughly tested" by any means, but seems to work.  The 
only way to know whether commercial Android apps can be written 
in D is to actually do it.  I plan on writing one this year.

On Monday, 9 January 2017 at 23:24:08 UTC, Ignacious wrote:
> How difficult is it to build for x86/x64?
>
> Would be nice to be able to use something like
>
> http://www.android-x86.org/
>
> as a test instead of an actual device.
>
> Does one simply have to use the proper ldc2/dmd and link in the 
> correct libs? or is it more complex?

Not too hard.  I haven't bothered with it because Android/x86 had 
almost no market share, and Intel has essentially given up and 
pulled out of that market.  I may someday update it again, but 
the problem right now is that I don't have an x86 machine on 
which to try it.  I've gone all ARM and setting Android/x86 up on 
a VPS takes some work.

> Also, I'm a bit confused on how to compile the source 
> examples(working it out and trying to explain the solutions as 
> I type)
>
> https://wiki.dlang.org/Build_DMD_for_Android

As noted there, those instructions haven't been updated in a year 
and a half and are out of date.  I just updated the wiki page 
with a stronger warning.

> (set $NDK permanently)
> I have done(easy, find the file and modify)
>
>     rt_init();
>     android_main(android_app);
>     rt_term();
>
> Clean up and compile as before:
>
> $NDK/ndk-build clean
> NDK_TOOLCHAIN_VERSION=clang $NDK/ndk-build V=1
>
> But no error. Object files for various architectures are 
> created though, it seems. (rt_ errors do no exist contrary to 
> what is said in the docs)

I'm not sure why that wouldn't error anymore, it should be the 
same.  Anyway, since I wrote those instructions a couple years 
ago, I translated the google-provided android_native_app_glue.c 
to android_native_app_glue.d and didn't bother updating the 
instructions for Android/x86.

> But the following seems need updating/explaining. I am using 
> prebuilt ldc2 for android from some link you provided. -android 
> doesn't seem to work and I can't find sensor.d (not sure if it 
> is needed anymore)?
>
> ../../../dmd/src/dmd -android -I../.. 
> -ofobj/local/x86/objs/native-activity main.o -c jni/main.d 
> ../../android/sensor.d
>
> I had to change to use ldc2, remove -android, and obviously 
> change the file names and such(and download the android dir 
> from github).
>
> $NDK/toolchains/llvm-3.5/prebuilt/linux-x86/bin/clang 
> -Wl,-soname,libnative-activity.so -shared 
> --sysroot=$NDK/platforms/android-9/arch-x86 
> ./obj/local/x86/objs/native-activity/main.o 
> ./obj/local/x86/libandroid_native_app_glue.a -lgcc  
> -gcc-toolchain  $NDK/toolchains/x86-4.8/prebuilt/linux-x86 
> -target i686-none-linux-android -no-canonical-prefixes  
> -Wl,--no-undefined -Wl,-z,noexecstack -Wl,-z,relro -Wl,-z,now  
> -L$NDK/platforms/android-9/arch-x86/usr/lib -llog -landroid 
> -lEGL -lGLESv1_CM -llog -lc -lm -fuse-ld=bfd
> -L../../../phobos/generated/linux/release/32 -l:libphobos2.a -o 
> ./libs/x86/libnative-activity.so
>
> Seems a lot of the paths are wrong/different than what I have
>
> $NDK/toolchains/llvm-3.5/prebuilt/linux-x86/bin/clang 
> -Wl,-soname,libhello-jni.so -shared 
> --sysroot=$NDK/platforms/android-9/arch-x86 
> ./obj/local/x86/objs-debug/hello-jni/main.o 
> ./obj/local/x86/libandroid_native_app_glue.a -lgcc  
> -gcc-toolchain  $NDK/toolchains/x86-4.8/prebuilt/linux-x86 
> -target i686-none-linux-android -no-canonical-prefixes  
> -Wl,--no-undefined -Wl,-z,noexecstack -Wl,-z,relro -Wl,-z,now  
> -L$NDK/platforms/android-9/arch-x86/usr/lib -llog -landroid 
> -lEGL -lGLESv1_CM -llog -lc -lm -fuse-ld=bfd 
> -L../../../phobos/generated/linux/release/32 -l:libphobos2.a -o 
> ./libs/x86/libhello-jni.so
>
>
> I am going to zip of what I have so you can see how the paths 
> are laid out: http://www.filedropper.com/ldc2android
>
> There seems to be no obj file generated except for debug, that 
> was probably intentional but the given command line doesn't 
> represent that if so.
>
>
> It is a bit confusing for the beginner to come along and try to 
> get all this to work when there is contradictory information.

Yes, that wiki page notes that it is out of date, which accounts 
for most of the issues you noted.

> The reason being is simple in that a beginner won't know what 
> is used for what and the docs essentially are give as "plug and 
> play" yet don't actually work... rather than being descriptive 
> and explaining exactly what is what(some of it should be 
> obvious but not all will be to someone that isn't versed in 
> linux and android development or used to windows which 
> abstracts everything).
>
> What would be nice, at a minim, is a bash script that allows 
> one to adjust different variables for different situations and 
> then it can be used to compile. (e.g., set the obj path, ndk 
> path, ldc2 path, etc)
>
> What really needs to be done, IMO, is to have a simple set of 
> tools(scripts or whatever) that can be configured easily and 
> abstracts the complexity. (I've done that for the test script I 
> made
>
> #!/bin/bash
>
> /mnt/c/dlang/ldc2Android/bin/ldc2 -c $1.d
>
> $NDK/toolchains/llvm/prebuilt/linux-x86_64/bin/clang 
> -Wl,-z,nocopyreloc --sysroot=$NDK/platforms/android-9/arch-arm 
> -lgcc -gcc-toolchain 
> $NDK/toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64 
> -target armv7-none-linux-androideabi -no-canonical-prefixes 
> -fuse-ld=bfd -Wl,--fix-cortex-a8 -Wl,--no-undefined 
> -Wl,-z,noexecstack -Wl,-z,relro -Wl,-z,now -fPIE -pie -mthumb 
> -Wl,--export-dynamic -lc -lm $1.o lib/libphobos2-ldc.a 
> lib/libdruntime-ldc.a -o $1
>
>
> which does the compiling for me without having to type all that 
> junk in each time.. pretty simple but does the job, a more 
> advanced concept could be used to help make it easier on people
> )

As I noted elsewhere, I am writing reggae files to automate 
building the sample apps.  The problem right now is that I have 
to rewrite my reggae files to work with an external linker from 
the NDK, as opposed to the native linker on my Android/ARM tablet:

https://github.com/atilaneves/reggae/issues/22

Once that's done, I will commit them to my Android repo so that 
anyone can use them with reggae.  The new wiki page will have 
instructions on how to use it all together, while keeping the old 
manual instructions around so you can see what they're actually 
doing.

> If you want, and you can accomplish this, if there was an 
> ldc2/dmd2 for android that runs on windows I could work on 
> getting it working for windows(as I prefer it rather than 
> linux, which I have no real experience with). I'm thinking 
> everything more or less would work similarly(since sdk/ndk 
> exists for windows). It would just be a matter of translating 
> paths and such. I could easily write a wrapper to reduce the 
> complexity.

I have not used Windows in more than a year.  We used to have two 
Windows devices at home 3-4 years ago, a laptop and an ultrabook, 
now we have none.  I suppose I could try setting up wine in a 
VPS, but I'm not sure if that'd work and don't feel inclined to 
try it.  As I said earlier, when this cross-compiler can use 
stock llvm, there will be official cross-compilers for every OS.

> The main problem I seem to be having are path issues(e.g,
>
> $NDK/toolchains/llvm/prebuilt/linux-x86_64/bin/clang
>
> rather than
>
> $NDK/toolchains/llvm-3.5/prebuilt/linux-x86/bin/clang
>
> ,etc)
>
>
> The final error I get is
>
> clang: error: no such file or directory: 
> './obj/local/x86/libandroid_native_app_glue.a'
>
> and I can't find this file anywhere.
>
> I assume I was suppose to get this file when I did
>
> $NDK/ndk-build clean
> NDK_TOOLCHAIN_VERSION=clang $NDK/ndk-build V=1
>
> You should see the following linker error, as the linker can't 
> find the rt_init and rt_term functions you just added:
>
> /home/joakim/android-ndk-r10/sources/android/native_app_glue/android_native_app_glue.c:232:
> error: undefined reference to 'rt_init'
> /home/joakim/android-ndk-r10/sources/android/native_app_glue/android_native_app_glue.c:234:
> error: undefined reference to 'rt_term'
> clang++: error: linker command failed with exit code 1 (use -v 
> to see invocation)
> make: *** [obj/local/x86/libnative-activity.so] Error 1
>
> but I didn't.
>
> If I execute that command in the android_native_app_glue.c dir 
> I get
>
> /opt/android-ndk-r13b/sources/android/native_app_glue# 
> NDK_TOOLCHAIN_VERSION=clang $NDK/ndk-build V=1
> Android NDK: Could not find application project directory !
> Android NDK: Please define the NDK_PROJECT_PATH variable to 
> point to it.
> /opt/android-ndk-r13b/build/core/build-local.mk:151: *** 
> Android NDK: Aborting    .  Stop.
>
> Of course, if I execute it in the project path I get a lot of 
> stuff but not that file anywhere.
>
> I have dried to put
>
> android_native_app_glue.d
>
> in different places but nothing...
>
> Once that is fixed I assume everything should work... but I'm 
> at a loss for what to do next. Any ideas?

If you really want to get it to work, you should replace the old 
instructions for the app_glue C file with the ones for the D file 
from the newer ldc/ARM wiki page.  Still no guarantee that it'll 
all work, as those instructions are written for dmd, while you 
are using ldc, which hasn't been tried with Android/x86 in a 
while.

Rather than use Android/x86 (which you are only doing because you 
think it's easier to test Android apps on Android/x86 in a VM?), 
I suggest you install the SDK, which comes with an Android/ARM 
emulator, or run on an actual Android/ARM device, which is what I 
do.  You can hook a phone or tablet up through USB to your 
Windows machine and control it better through adb.