On Monday, 6 April 2020 at 08:38:03 UTC, Jan Hönig wrote:
> Is there some "Hello World!" example for D on Android?

So I did a tiny thing in the repo:

https://github.com/adamdruppe/d_android/tree/master/android-dub-test

if you open that in android studio it should load up, and the makefile is commented, but tells you the 8 commands (4 dub builds, 4 file copies, just doing the same things for each of the 4 android architecture targets) to do a full add.

The main program is still in Java - there's a way to do pure D, the NDK's NativeActivity, but I never tried it personally (tbh I've only actually done hello world in android at all, i have zero interest in mobile dev, i just did it cuz someone had to do something and the JNI meta code was kinda cool) - but then you can call to/from D/java with native methods.


> However there is just so much to know.
> It is really overwhelming.

no kidding, I spent several weekends just trying to understand the setup and build process. And I still basically don't really know, which is why my thing there builds the D code externally and copies the files where gradle can find them instead of actually changing the gradle config.

On Tue, Apr 07, 2020 at 12:43:20PM +0000, Adam D. Ruppe via Digitalmars-d-learn wrote:
> On Monday, 6 April 2020 at 08:38:03 UTC, Jan Hönig wrote:
> > Is there some "Hello World!" example for D on Android?
[...]
> > However there is just so much to know.
> > It is really overwhelming.
> 
> no kidding, I spent several weekends just trying to understand the setup and build process. And I still basically don't really know, which is why my thing there builds the D code externally and copies the files where gradle can find them instead of actually changing the gradle config.

I managed to build APKs without Gradle (yes, I'm crazy like that). There are several steps, and you do need some tools from the Android SDK/NDK, namely aapt, apksigner, dx (called dalvik-exchange on some distros), zipalign, and a Java 1.7 compiler (the last time I checked; maybe they support 1.8 now, I don't know).

I haven't tried a native app so far, so the way I set it up is to create a dummy Java wrapper that contains main() that calls native methods that are implemented in D.  You can use Adam's jni.d to generate implementations for your native methods.

Steps:

1) Follow LDC wiki to build an Android cross-compiler and cross-compiled
   LDC libraries (this may already be prepackaged with the latest LDC
   releases). Most important thing you need is the path to the droid32
   or droid64 directories containing the libraries libdruntime-ldc.a,
   libphobos2-ldc.a, libdruntime-ldc-debug.a, libphobos2-ldc-debug.a.

	DROID32_PATH=/usr/src/d/android/droid32/lib	# for example

2) Generate R.java:

	TARGET_API_LEVEL=23 # for example
	/usr/bin/aapt package -f -m -M AndroidManifest.xml -S res -I ${PATH_TO_ANDROID_SDK}/platforms/android-${TARGET_API_LEVEL}/android.jar -J ${PATH_TO_JAVA_SOURCE_CODE}

3) Compile Java sources:

	/usr/bin/javac -source 1.7 -target 1.7 -bootclasspath ${PATH_TO_ANDROID_SDK}/platforms/android-${TARGET_API_LEVEL}/android.jar -d obj -sourcepath src ${JAVA_SOURCE_FILES (including R.java)}

4) Generate classes.dex (on some systems dalvik-exchange might be called
simply 'dx'):

	/usr/bin/dalvik-exchange --dex --output=classes.dex ${PATH_TO_OBJ_DIR}

5) Setup linker config file (for optimizing apk size):

	LINKER_VERSION_FILE=lib${YOUR_APP_NAME}.version
	cat > $LINKER_VERSION_FILE
	LIBGAME_1.0 {
		global:
			Java_*;
		local:
			*;
	};

6) Cross-compile D code with LDC:

	${PATH_TO_LDC}/bin/ldmd2 -c -mtriple=armv7-none-linux-androideabi -mcpu=cortex-a8 -L-L${DROID32_PATH}/lib -Xcc=-fpie -Xcc=-pie -Xcc=--sysroot=${PATH_TO_ANDROID_NDK}/platforms/android-${TARGET_API_LEVEL}/arch-arm -Xcc=-fuse-ld=bfd -Xcc=-gcc-toolchain -Xcc=${PATH_TO_ANDROID_NDK}/toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64 -Xcc=-target -Xcc=armv7-none-linux-androideabi -O4 -inline -Isrc/d -od${PATH_TO_OBJ_DIR} ${D_SOURCE_FILES}
	${PATH_TO_ANDROID_NDK}/toolchains/llvm/prebuilt/linux-x86_64/bin/clang -Wl,-soname,lib${YOUR_APP_NAME}.so -shared -Wl,--gc-sections -Wl,--version-script=${LINKER_VERSION_FILE} -llog -landroid -lEGL -lGLESv2 --sysroot=${PATH_TO_ANDROID_NDK}/platforms/android-${TARGET_API_LEVEL}/arch-arm -fuse-ld=bfd -gcc-toolchain ${PATH_TO_ANDROID_NDK}/toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64 -target armv7-none-linux-androideabi ${D_OBJECT_FILES} ${DROID32_PATH}/lib/libphobos2-ldc.a ${DROID32_PATH}/lib/libdruntime-ldc.a -o lib/armeabi-v7a/lib${YOUR_APP_NAME}.so

7) Create unaligned APK:
	/usr/bin/aapt package -f -m -M AndroidManifest.xml -S res -I ${PATH_TO_ANDROID_SDK}/platforms/android-${TARGET_API_LEVEL}/android.jar -F bin/${YOUR_APP_NAME}.unaligned.apk
	/usr/bin/aapt add bin/${YOUR_APP_NAME}.unaligned.apk classes.dex
	/usr/bin/aapt add bin/${YOUR_APP_NAME}.unaligned.apk lib/armeabi-v7a/lib${YOUR_APP_NAME}.so

8) Sign the APK:
	/usr/bin/apksigner sign --ks-pass file:${YOUR_SIGNING_KEY_PASSWORD_FILE} --ks ${YOUR_SIGNING_KEY_STORE_FILE} bin/${YOUR_APP_NAME}.unaligned.apk

9) Align the APK:
	/usr/bin/zipalign -f 4 bin/${YOUR_APP_NAME}.unaligned.apk bin/${YOUR_APP_NAME}.apk

10) Copy bin/${YOUR_APP_NAME}.apk to your device and install it.


T

-- 
The two rules of success: 1. Don't tell everything you know. -- YHL

On Tuesday, 7 April 2020 at 12:43:20 UTC, Adam D. Ruppe wrote:
> On Monday, 6 April 2020 at 08:38:03 UTC, Jan Hönig wrote:
>> Is there some "Hello World!" example for D on Android?
>
> So I did a tiny thing in the repo:
>
> https://github.com/adamdruppe/d_android/tree/master/android-dub-test
>
> if you open that in android studio it should load up, and the makefile is commented, but tells you the 8 commands (4 dub builds, 4 file copies, just doing the same things for each of the 4 android architecture targets) to do a full add.


Thanks a lot. I was blind not finding it in your repo.

On Tuesday, 7 April 2020 at 14:51:15 UTC, H. S. Teoh wrote:
> On Tue, Apr 07, 2020 at 12:43:20PM +0000, Adam D. Ruppe via Digitalmars-d-learn wrote:
>> On Monday, 6 April 2020 at 08:38:03 UTC, Jan Hönig wrote:
>> > Is there some "Hello World!" example for D on Android?
> [...]
>> > However there is just so much to know.
>> > It is really overwhelming.
>> 
>> no kidding, I spent several weekends just trying to understand the setup and build process. And I still basically don't really know, which is why my thing there builds the D code externally and copies the files where gradle can find them instead of actually changing the gradle config.
>
> I managed to build APKs without Gradle (yes, I'm crazy like that). There are several steps, and you do need some tools from the Android SDK/NDK, namely aapt, apksigner, dx (called dalvik-exchange on some distros), zipalign, and a Java 1.7 compiler (the last time I checked; maybe they support 1.8 now, I don't know).
>
> I haven't tried a native app so far, so the way I set it up is to create a dummy Java wrapper that contains main() that calls native methods that are implemented in D.  You can use Adam's jni.d to generate implementations for your native methods.
>
> Steps:
>
> 1) Follow LDC wiki to build an Android cross-compiler and cross-compiled
>    LDC libraries (this may already be prepackaged with the latest LDC
>    releases). Most important thing you need is the path to the droid32
>    or droid64 directories containing the libraries libdruntime-ldc.a,
>    libphobos2-ldc.a, libdruntime-ldc-debug.a, libphobos2-ldc-debug.a.
>
> 	DROID32_PATH=/usr/src/d/android/droid32/lib	# for example
>
> 2) Generate R.java:
>
> 	TARGET_API_LEVEL=23 # for example
> 	/usr/bin/aapt package -f -m -M AndroidManifest.xml -S res -I ${PATH_TO_ANDROID_SDK}/platforms/android-${TARGET_API_LEVEL}/android.jar -J ${PATH_TO_JAVA_SOURCE_CODE}
>
> 3) Compile Java sources:
>
> 	/usr/bin/javac -source 1.7 -target 1.7 -bootclasspath ${PATH_TO_ANDROID_SDK}/platforms/android-${TARGET_API_LEVEL}/android.jar -d obj -sourcepath src ${JAVA_SOURCE_FILES (including R.java)}
>
> 4) Generate classes.dex (on some systems dalvik-exchange might be called
> simply 'dx'):
>
> 	/usr/bin/dalvik-exchange --dex --output=classes.dex ${PATH_TO_OBJ_DIR}
>
> 5) Setup linker config file (for optimizing apk size):
>
> 	LINKER_VERSION_FILE=lib${YOUR_APP_NAME}.version
> 	cat > $LINKER_VERSION_FILE
> 	LIBGAME_1.0 {
> 		global:
> 			Java_*;
> 		local:
> 			*;
> 	};
>
> 6) Cross-compile D code with LDC:
>
> 	${PATH_TO_LDC}/bin/ldmd2 -c -mtriple=armv7-none-linux-androideabi -mcpu=cortex-a8 -L-L${DROID32_PATH}/lib -Xcc=-fpie -Xcc=-pie -Xcc=--sysroot=${PATH_TO_ANDROID_NDK}/platforms/android-${TARGET_API_LEVEL}/arch-arm -Xcc=-fuse-ld=bfd -Xcc=-gcc-toolchain -Xcc=${PATH_TO_ANDROID_NDK}/toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64 -Xcc=-target -Xcc=armv7-none-linux-androideabi -O4 -inline -Isrc/d -od${PATH_TO_OBJ_DIR} ${D_SOURCE_FILES}
> 	${PATH_TO_ANDROID_NDK}/toolchains/llvm/prebuilt/linux-x86_64/bin/clang -Wl,-soname,lib${YOUR_APP_NAME}.so -shared -Wl,--gc-sections -Wl,--version-script=${LINKER_VERSION_FILE} -llog -landroid -lEGL -lGLESv2 --sysroot=${PATH_TO_ANDROID_NDK}/platforms/android-${TARGET_API_LEVEL}/arch-arm -fuse-ld=bfd -gcc-toolchain ${PATH_TO_ANDROID_NDK}/toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64 -target armv7-none-linux-androideabi ${D_OBJECT_FILES} ${DROID32_PATH}/lib/libphobos2-ldc.a ${DROID32_PATH}/lib/libdruntime-ldc.a -o lib/armeabi-v7a/lib${YOUR_APP_NAME}.so
>
> 7) Create unaligned APK:
> 	/usr/bin/aapt package -f -m -M AndroidManifest.xml -S res -I ${PATH_TO_ANDROID_SDK}/platforms/android-${TARGET_API_LEVEL}/android.jar -F bin/${YOUR_APP_NAME}.unaligned.apk
> 	/usr/bin/aapt add bin/${YOUR_APP_NAME}.unaligned.apk classes.dex
> 	/usr/bin/aapt add bin/${YOUR_APP_NAME}.unaligned.apk lib/armeabi-v7a/lib${YOUR_APP_NAME}.so
>
> 8) Sign the APK:
> 	/usr/bin/apksigner sign --ks-pass file:${YOUR_SIGNING_KEY_PASSWORD_FILE} --ks ${YOUR_SIGNING_KEY_STORE_FILE} bin/${YOUR_APP_NAME}.unaligned.apk
>
> 9) Align the APK:
> 	/usr/bin/zipalign -f 4 bin/${YOUR_APP_NAME}.unaligned.apk bin/${YOUR_APP_NAME}.apk
>
> 10) Copy bin/${YOUR_APP_NAME}.apk to your device and install it.
>
>
> T

Thanks for the effort. I will try the "easy" way frist :D

On Tuesday, 7 April 2020 at 14:51:15 UTC, H. S. Teoh wrote:
> 1) Follow LDC wiki to build an Android cross-compiler and cross-compiled
>    LDC libraries (this may already be prepackaged with the latest LDC
>    releases).


They are - this is all automatic just-works now (if you download the right versions - my android-setup.d will grab the appropriate binaries from ldc repo for you).


> 6) Cross-compile D code with LDC:

And my android-setup.d also changes the ldc config file to automate most this - you just set the mtriple (and optionally, mcpu) and the rest is automatic too.



I've had more bugs than time so the full-on "just works" promise is "your mileage may vary" but it is really getting simplified for these two steps.

On Tue, Apr 07, 2020 at 03:06:16PM +0000, Adam D. Ruppe via Digitalmars-d-learn wrote:
> On Tuesday, 7 April 2020 at 14:51:15 UTC, H. S. Teoh wrote:
> > 1) Follow LDC wiki to build an Android cross-compiler and
> >    cross-compiled LDC libraries (this may already be prepackaged
> >    with the latest LDC releases).
> 
> They are - this is all automatic just-works now (if you download the right versions - my android-setup.d will grab the appropriate binaries from ldc repo for you).

Nice!  I'm totally loving how the LDC maintainers have been packaging everything in such a convenient, easy-to-use way.  I've been doing cross-compilation to Windows, and it's been great, I don't even need a Windows machine, just cross-compile to Windows with the right triple and library paths set in ldc2.conf, and it Just Works(tm).


> > 6) Cross-compile D code with LDC:
> 
> And my android-setup.d also changes the ldc config file to automate most this - you just set the mtriple (and optionally, mcpu) and the rest is automatic too.

Very nice!


[...]
> I've had more bugs than time so the full-on "just works" promise is "your mileage may vary" but it is really getting simplified for these two steps.

The rest are Android-specific, but in theory easily scriptable (in fact, I typed it up by copy-n-pasting from the output of my SCons build script :P).  So in theory, one *could* write a script that does it all in one go.


T

-- 
People say I'm arrogant, and I'm proud of it.

On Tuesday, 7 April 2020 at 12:29:57 UTC, Adam D. Ruppe wrote:
> On Tuesday, 7 April 2020 at 11:45:24 UTC, burt wrote:
>> I managed to get it to compile. I had to add __bss_end__ symbol myself and set the value to the value of the `_end` symbol or it wouldn't work. A PR to the LDC druntime is wat caused the __bss_end__ symbol to be missing [0].
>
> Blargh it was supposed to just work without main() on the new ldc but I only actually ran stuff with 1.19 on actual android.
>
>
>> However, when I added a MainActivity class in D using arsd.jni, the app crashes whenever one of the @Exported methods is called.
>
> What does the android studio debugger say about it? Missing method or another link problem?
>
>> And a callback method for a button in Java called dFunction with the appropriate parameters. I noticed that the generated .so file didn't contain a `Java_com_mypackage_myapplication_MainActivity_dFunction` symbol. Any help on this would be appreciated.
>
> Yeah, it uses a private name and registers that in a static module constructor (this allows it to support overloads more easily), so that specific name not being there isn't wrong, but it could be the registration function never got called again.

Error is as follows according to the logs:

java.lang.IllegalStateException: Could not execute method for android:onClick
        at [etc.]
Caused by: java.lang.reflect.InvocationTargetException
        at [etc.]
Caused by: java.lang.UnsatisfiedLinkError: No implementation found for void com.mypackage.myapplication.MainActivity.dFunction(android.widget.TextView, android.widget.TextView, android.widget.TextView) (tried Java_com_mypackage_myapplication_MainActivity_dFunction and Java_com_mypackage_myapplication_MainActivity_dFunction__Landroid_widget_TextView_2Landroid_widget_TextView_2Landroid_widget_TextView_2)
        at [etc.]

So yes, it cannot find the function. How can I check if the module constructor is actually run?