how to help with android

Johannes Pfau nospam at example.com
Wed Jul 25 10:35:49 PDT 2012


Am Tue, 24 Jul 2012 20:12:33 +0200
schrieb maarten van damme <maartenvd1994 at gmail.com>:

> Hello, I would really want to use D on android. I've seen
> https://bitbucket.org/goshawk/gdc/wiki/GDC%20on%20Android and judging
> by the TODO's it's not really usable right now.
> 
> Is there a way I can contribute/help any way? I don't have any
> knowledge about druntime but quite some spare time right now.

Yeah I should continue the Android port at some time. I have some local
changes to the android build system to easily build d apps, but there
are still some big roadblocks for Android support:

* Android doesn't have native TLS. D needs native TLS (In this case
  'native' means not 'posix tls'. 'posix tls' means
  "pthread_key_create", 'native' means "__thread"). We can use GCCs
  emulated TLS, but currently emulated TLS doesn't interface to the GC
  correctly (the GC doesn't scan TLS memory right now)
* Android doesn't officially support native executables. I'm not sure
  where this statement is hidden, but it is an official statement. For
  example their linker is broken when accessing a global variable from
  a native application in a specific way. Just to emphasize how bad
  this really is: If you want to access stdout (the C global variable)
  which is used in writeln for example, you have to use hacks and
  dladdr to load the address of stdout. You can't simply declare it as
  external. So you can't actually write a hello world native
  exacutalbe with D for Android. The Android devs don't care about
  those issues, as native executables are not supported anyway.
  But you wouldn't want to use native executables anyway. For example
  native executables have no possibility to draw a GUI. There's just no
  way to access the required window handle from a native executable.
  Instead the supported way to write a "Native Application" is to write
  a Java stub which loads a shared .so library and calls functions of
  that library. With recent versions of Android/NDK you don't have to
  write that stub yourself, it's included in the "NativeApplication"
  but it still works the same way: Java code loads a .so library.
  Which leads to the next problem:
* Shared library support in D is probably not good enough to do that
  right now. We need:
    * Phobos as a shared library
    * Druntime as a shared library (it actually compiles as a shared
      library on ARM/Android as the asm code preventing that on x86 is
      not used, but I don't know whether it is really working)
    * Loading a shared D library should automatically load druntime
      and enable the GC (could maybe be done manually)
    * I'm not sure if this is necessary for Android, but at some point
      it should be possible to load two D .so libraries into a C
      application. Those libraries should use the same GC, runtime,
      etc...
* GDCs bug #120 can be worked around, but it'd be better to fix it.
  Doesn't seem like an easy fix though.

Those are the known compiler issues. At least the TLS and the shared
library issue has to be fixed, unless that's done there's no need to
look at the library side.

For the libraries:
* The unittest for phobos and druntime must be run and fixed. (This is
  not as easy as it sounds: We have to run the unittests with the cross
  compiler. And we can't really run unittests as native executables
  because of the issues described above. We'd have to build unittests as
  a .so and run them from a Java APP / "Native Application")

* Some modules in phobos need porting. For example std.stdio uses fwide
  which isn't available on Android, so we have to add special cases for
  Android. There are probably more similar problems, as Android doesn't
  implement all Posix APIs.

* When all that stuff is working, we can actually start interfacing to
  Android APIs. We'd need JNI bindings, bindings to the Android API's
  and at some point higher level wrappers would be nice.

> 
> I've also read that android never claims to be possix compliant yet
> this site disagree's:
> http://developer.android.com/guide/appendix/glossary.html

You mean the "Dalvik" part? It only needs some Posix APIs, not all.
Bionic/Android has (mostly) Posix compliant threading. Other Posix
stuff is completely missing though.

For an example where Bionic is not posix compliant:
https://github.com/android/platform_bionic/blob/master/libc/docs/OVERVIEW.TXT
"Note that Posix mandates a minimum of 128 slots, but we do not claim
to be Posix-compliant."
Most of the time Android uses Posix APIs. But if they think a function
is not necessary, they just don't implement it. (For example wide
character/wchar routines are not implemented on Android. It's not
needed for JAVA Apps)



More information about the D.gnu mailing list