Beginnings of native Android build #110471
Conversation
dotnet-policy-service
bot
added
the
community-contribution
steveisok
added
os-android
and removed
community-contribution
|
Tagging subscribers to 'arch-android': @vitek-karas, @simonrozsival, @steveisok, @akoeplinger |
grendello
force-pushed
the
dev/grendel/android-build-with-ndk
branch
from
c25fbd9 to
3d9da10
Compare
…ndk' into dev/grendel/android-build-with-ndk
…stem.Security.Cryptography.Native.Android. It will incorrectly try to install in the coreclr build
…em.native library for the singlefilehost
| @@ -80,7 +80,7 @@ build_native() | |||
|
|
|||
| if [[ "$targetOS" == android || "$targetOS" == linux-bionic ]]; then | |||
| # Keep in sync with $(AndroidApiLevelMin) in Directory.Build.props in the repository rooot | |||
| local ANDROID_API_LEVEL=28 | |||
| local ANDROID_API_LEVEL=29 | |||
There was a problem hiding this comment.
@grendello has mentioned in #110470 that even API level 28 is unfortunate and that we will want to support older API level, e.g. the originally used level 21.
So I wonder if moving to the level 29 is a good thing.
There was a problem hiding this comment.
It's not good in the long term and is something we should fix. Moving it to 29 for now allows us to not have to deal with emulated TLS usage.
There was a problem hiding this comment.
Unless we can fix it now, I don't think this should block progress. We can do it sometime down the road.
There was a problem hiding this comment.
In perspective, this would drop 12.8% of the devices (with API level from 21 to 29) according to https://apilevels.com/
Then again:
Level 21 is Android 5 and 6 years EOL
Level 29 is Android 10 and 2 years EOL (https://endoflife.date/android)
Level 34 or higher is necessary to publish apps to the Play Store (https://developer.android.com/google/play/requirements/target-sdk)
There was a problem hiding this comment.
I think I can make the emulated TLS work without too much hassle. The question though is if we are worried about the perf implications of the emulated TLS vs the standard TLS and thus we would like to end up having support for both.
… R2R that acts like linux
| <_CoreClrBuildArg Include="-DANDROID_STL=none"/> | ||
| <_CoreClrBuildArg Include="-DANDROID_CPP_FEATURES="no-rtti no-exceptions""/> | ||
| <_CoreClrBuildArg Include="-DANDROID_STL=c++_static"/> | ||
| <_CoreClrBuildArg Include="-DANDROID_CPP_FEATURES="no-rtti exceptions""/> |
There was a problem hiding this comment.
Does this affect size of native AOT runtime packs? (Build with ./build.sh -ci -arch x64 -os linux-bionic -c Release /p:DotNetBuildRuntimeNativeAOTRuntimePack=true and check the size of libRuntime.WorkstationGC.a). We'll likely have to move this part of configuration someplace else, native AOT is the most size sensitive workload we have. Native AOT doesn't need C++ runtime library and doesn't need exceptions.
| @@ -23,7 +23,8 @@ public enum TargetOS | |||
| FreeBSD, | |||
| NetBSD, | |||
| SunOS, | |||
| WebAssembly | |||
| WebAssembly, | |||
| Android | |||
There was a problem hiding this comment.
Why does the AOT compiler need to distinguish between Linux and Android? We've been shipping for Android for a while now with native AOT and it's just Linux there.
There was a problem hiding this comment.
We'd have to play games with the RID to make it linux in order to pass that into the aot compiler. The reason why linux-bionic just works is because we are treating that not as android, but just another linux.
There was a problem hiding this comment.
There are two possible scenarios:
- We'll just treat it as Linux everywhere in the compiler anyway. If that's the case, we should just normalize to linux before compiler is invoked.
- The compiler needs to know this is Android. Then this change makes sense.
We had a similar discussion around iOSLike vs macOS in #87610 (comment). That one even wanted to add extra enums to RyuJIT to distinguish. We ended up not doing it because there was nothing different.
The AOT compiler (but not RyuJIT) needs to distinguish between macOS and iOSLike because Apple really wants to see that in the object files. I'm not aware of a need for this in the Android object files.
There was a problem hiding this comment.
I'd prefer to hedge towards needing a change in the aot compiler and then back it out if we don't. Once we are able to run something (perhaps in this PR), we might have a better idea.
| @@ -2,9 +2,36 @@ | |||
| <PropertyGroup> | |||
| <StaticLibPrefix>lib</StaticLibPrefix> | |||
| <ExeSuffix Condition="'$(HostOS)' == 'windows'">.exe</ExeSuffix> | |||
| <Blah>$(HostOS)</Blah> | |||
Also disable posix_madvise with POSIX_MADV_DONTNEED
No description provided.