Runtime: Android: Next Steps

[qmfrederik]

With dotnet/runtime#7544 resolved, .NET Core on 64-bit Android can now run a basic "Hello World" app.

I'm opening this issue to see what the next steps would be. That would include:

• CI builds (or at least standardized builds which can be used to create NuGet packages)
• Assigning a RID for Android

[qmfrederik]

@gkhanna79 Let's continue the conversation from dotnet/runtime#7544 here.

Both CoreCLR and CoreFX can now cross-build on Linux for arm64 Android.
Cross-building is similar to how it's done for ARM Linux - that is, using a rootfs and a set of cross compilers.
For Android, we use the NDK ("Native Development Kit for Android") to cross compile.

The cross-building instructions are here: https://github.com/dotnet/coreclr/blob/master/Documentation/building/android.md.

There isn't a separate doc for CoreFX but the steps are similar.

If there's interest on your side to get CI builds and a MyGet feed for Android, let me know - I can free up some time to get the process started.

[cydhaselton]

Are their other components around or central to .NET Core for which an Android port would be useful and/or possible? I'm thinking specifically of anything listed in the dotnet org, i.e. the cli, buildtools or other projects

[am11]

@cydhaselton, the bootstrap script in dotnet/core repo:
https://github.com/dotnet/core/tree/927a249/tools/dotnet-bootstrap/dotnet.bootstrap.py#L349-L364 suggests coreclr, corefx and core-setup under dotnet org with native components are required to be rebuilt. The rest of the repos contain portable, managed code.

[cydhaselton]

There's not much in the way of documentation for building core-setup; is this on purpose?

[qmfrederik]

@cydhaselton Have a look at dotnet/core-setup#747 and dotnet/core-setup#749. These were the PRs that got core-setup to cross-build for ARM Linux.

I think that to cross-build core-setup for Android, you can re-use the same approach that was taken for CoreCLR and CoreFX: work with a rootfs for Android using the build-android-rootfs script (adapted for core-setup) and use a cross/android/arm64 folder with the toolchain.cmake and tryrun.cmake files.

Once you have core-setup building, I think you can try building a CLI package for .NET on Android. You can use the approach @am11 suggested - take a CLI package for Linux (perhaps one of the drops for arm64 Linux), replace the OS-specific files with the ones you've built, and you should be able to run .NET core on your Android device.

Pinging @stevedesmond-ca as I think he went through that exercise for arm Linux, so he may be able to help you, too.

Once you have that, you should even be able to build PowerShell on your device :)

[stevedesmond-ca]

dotnet/core-setup#725 has a checklist that could be useful. I recall reading recently that the CI switched to Docker containers instead of the chroot/rootfs, so might not be necessary anymore.

[cydhaselton]

@stevedesmond-ca: Thanks, that post has a wealth of info

@qmfrederik: Please post here if/when you PR a RID for Android and I'll do the same. Based on the documentation it should use api levels (i.e. 20, 21, 22) instead of OS (i.e. 5.0, 5.01, etc).

[cydhaselton]

@qmfrederik Not sure if this is the place to mention this, but also not sure where else I'd put this…how should we handle the actual work on the Android next steps so we're not duplicating work and/or stepping on toes? (i.e. duplicate RID PRs in corefx). Should a discussion/issue be created with a list of TODOs or would you prefer to handle all of it?

FYI, I started work on the RIDs because a) it was the easiest implementation to put in place and b) wouldn't require possibly modifying/duplicating code/changes you;d already made.

[qmfrederik]

@cydhaselton I think the best is to create a checklist of tasks that needs to be done to get .NET Core up and running for Android.

I think the next step is to get core-setup (and the muxer) up and running on Android. dotnet/core-setup#1648 implements that for ARM64 Linux, from there porting to Android should be similar with what we've done for CoreCLR and CoreFX.

My focus will be on ARM64 Linux and getting all of my dependencies to run on netstandard2.0, so I'll be a bit light on Android for now.

If we start work on something major, perhaps best would be to either update this thread or create a new issue and ping each other?

[cydhaselton]

@qmfrederik I think setting up a new issue in core-setup with a checklist of tasks, like the one for dotnet/core-setup#725 would be the way to go. I'll create a placeholder and update with the necessary tasks when I've got time.

[masonwheeler]

This is great news, but what's the status on 32-bit? A lot of ARM Android devices are still 32-bit only, so I'm kind of surprised to see the ARM64 version reach this milestone first...

[qmfrederik]

@masonwheeler dotnet/coreclr#9961 tracks the work for ARM Android.

[masonwheeler]

@qmfrederik So once that's merged... then what? Will it be on the same level as 64-bit?

[qmfrederik]

Pretty much, yes. The OS porting aspect is the same for arm64 and arm, so things should just work.

Cross-building for arm still needs to be enabled for corefx; the changes required over there should be very similar to dotnet/coreclr#9961.

Out of curiosity, what do you plan to use .NET Core on Android for?

[masonwheeler]

@qmfrederik Sort of playing a long game here, but I'm building a game engine and I'd like to be able to have it work for Android as well as Windows.

[qmfrederik]

@masonwheeler Sounds exciting! Just to set expectations right, with what we've done so far, you can run .NET Core console applications on Android.

To the best of my knowledge, apps in Android (so .apk files) always start as Java processes. You can inject native (C) code in that process via JNI - I guess that would be a way to inject .NET/C# code in that process but that requires additional work.

[masonwheeler]

@qmfrederik You talk about the Java app -> .NET app process as if it were something that's not working yet. So what's the mechanism by which you're running console apps?

[qmfrederik]

You can use adb shell to open a terminal (bash) session on an Android device. That gives you a normal busybox/bash shell in which you can run console apps.
Alternatively, you can use Termux, like @cydhaselton is doing.

[cydhaselton]

At some point, probably after core-setup work is close to completion, documentation should be added that specifies the conditions for which .NET Core will run on Android.

[masonwheeler]

@cydhaselton How does Xamarin do it? I figure it has to have some Java Activity that it includes in your project whose job it is to start the CLR as an NDK call and call into it, but I don't know where the file for that is in the Xamarin install, to have a look at it.

[qmfrederik]

@masonwheeler I think you are looking for this: https://github.com/xamarin/xamarin-android/blob/master/src/monodroid/jni/monodroid-glue.c

[masonwheeler]

@qmfrederik That looks more like a runtime library, really. What I'm really looking for is something like this: http://hg.libsdl.org/SDL/file/a364af650bf1/android-project/src/org/libsdl/app/SDLActivity.java

This is how SDL does the equivalent task: it provides an Activity in Java that sets up SDL and invokes your code by an NDK call.

[cydhaselton]

@masonwheeler No idea on how Xamarin does it; when I built mono it was for a Termux-like Android app…then later for Termux. I didn't do any work on integration with Java

[shahid-pk]

perhaps one can write a custom host like corerun and coreconsole that will work on android/GUI . The hosting apis are i think for this purpose.

[masonwheeler]

After a bit of research, (thanks to Grace Feng for pointing me in the right direction,) it looks like Xamarin has a completely different way of doing it, actually: https://developer.xamarin.com/guides/android/under_the_hood/architecture/#Application_Startup

Basically it's a hack that hooks the ContentProvider creation (which is about managing SQL data shared between applications and has nothing to do with runtime setup; as near as I can tell it's just "something that loads very early in the setup process that it's possible to hook into with an arbitrary class") with a class that calls MonoPackageManager, which loads the Mono runtime, represented by the mono.android.Runtime Java wrapper class. MonoPackageManager relies on data in the MonoPackageManager_Resources class, which is generated at compile-time by Xamarin and contains metadata about your project, such as the set of CLR assemblies that need to be loaded.

MonoRuntimeProvider is also generated at compile-time.

So that's how Xamarin does it. If I had to guess, I'd say this is probably necessary in order to support Xamarin's development model, where we are presented with the polite fiction that we can write managed classes that inherit from Android API classes such as Activity. If that's important, we'll need something similar. (Or, alternatively, we could come up with some PRs for the Xamarin project to support CoreCLR as well as Mono.)

On the other hand, if we don't care about that, and just want to write something that provides its own UI, such as a game, that convoluted approach isn't necessary and we should be able to get by with a solution similar to the SDL Activity I linked to above.

[masonwheeler]

Other useful references:

monodroid-glue.c, the native side of the mono.android.Runtime class. (And wow, the binding semantics are ugly! [DllImport] is so much nicer!)

Templates for generating MonoRuntimeProvider. Two different versions, depending on whether the Mono runtime is bundled into the APK or external.

@qmfrederik @cydhaselton @shahid-pk Hope some of this stuff is helpful!

[cydhaselton]

Couple of items/questions:

1. Given the rapidity of changes to corefx/coreclr, it would be good to get a CI build for Android up and running sooner rather than later.
2. I have next-to-no knowledge of the steps to get a CI up, much less an Android one. I'm willing to learn but given the need and my limited resources it would be more efficient a) to have a clear set of instructions or b) for someone familiar with the task to take it on.
3. The issues/PRs previously referenced (#725, dotnet/runtime#4149, etc) are helpful, but at least one of the bring-up steps is out of date due to more recent PRs (#8421) or code refactoring. Is there a repo-independent set of steps for bringing up a new platform for .NET Core or am I asking for the impossible?

Tagging @qmfrederik and @stevedesmond-ca for info, feel free to tag others I've missed.

[jean]

I'm anxiously waiting for the day that I can do apt-get install dotnet-sdk-2.0.0 in Termux.

[alexbihary]

Hi, I'd like to know if there is progress on this? I also would like to develop in dotnet core on termux (chrome-os / android environment). Thanks.

[cydhaselton]

Still waiting on some dependencies.

Additionally I'm dealing with some serious family issues at the moment, so
most of my non-work projects are on hold.

Will update/resume when things have calmed down

On Jan 12, 2018 10:52 PM, "Alexander Bihary" [e-mail]
wrote:

Hi, I'd like to know if there is progress on this? I also would like to
develop in dotnet core on termux (chrome-os / android environment). Thanks.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/dotnet/coreclr/issues/9946#issuecomment-357409948,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AKrdyTvC5-FeMuUd08asOLvzLqN_TBgJks5tKDakgaJpZM4MSw_0
.

[alexbihary]

Checking in again. Is there a chance this gets some love this year? Appreciate all your efforts.

[PythonSmith]

I'm currently making a python script to fix the termux-packages which are not available anymore. It will automatically load the latest version of the required termux library packages. Hopefully it compiles with the new libraries too.