You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We need to better understand why AndroidVersions.KnownVersions needs to be public, because making it public is almost certainly the wrong thing to do, long-term.
In particular, the PR message is incorrect:
KnownVersions should be the only place we modify when new versions are published.
This is wrong; see also commit aad97f1. The intention is that xamarin-android should control which versions are "supported," via the presence of the AndroidApiInfo.xml files. Using the AndroidApiInfo.xml files is key, so that we can plausibly introduce new API levels (API-Q, anyone?) without requiring code changes to xamarin-android-tools (and the requisite product bumps across 6+ repos).
For Android Manifest we also need to know what exists because Minimum Android Version and Target may be anything
This is in fact not correct either; there are limitations. Case in point: dotnet/android@06e920c.
NDK r19 -- which xamarin-android/master is now using -- has a minimum API level of 16...which varies across ABI targets. armeabi-v7a and x86 have a minimum API level of 16, while arm64-v8a and x86_64 have minimum API levels of 21. Trying to use a lower value may work, but it's highly likely they won't work, because of e.g. native linker symbol references.
In any event, anything prior to API-16 won't be QA'd or supported.
Which is a long-winded way of saying that this problem space is more complicated, and we need to come up with a more complete (and updatable!) solution.
Just making AndroidVersions.KnowVersions public Is Not The Correct Approach.
The text was updated successfully, but these errors were encountered:
We need to better understand why
AndroidVersions.KnownVersions
needs to be public, because making it public is almost certainly the wrong thing to do, long-term.In particular, the PR message is incorrect:
This is wrong; see also commit aad97f1. The intention is that
xamarin-android
should control which versions are "supported," via the presence of theAndroidApiInfo.xml
files. Using theAndroidApiInfo.xml
files is key, so that we can plausibly introduce new API levels (API-Q, anyone?) without requiring code changes toxamarin-android-tools
(and the requisite product bumps across 6+ repos).In short, what is the actual need behind PR #57?
This is in fact not correct either; there are limitations. Case in point: dotnet/android@06e920c.
NDK r19 -- which xamarin-android/master is now using -- has a minimum API level of 16...which varies across ABI targets.
armeabi-v7a
andx86
have a minimum API level of 16, whilearm64-v8a
andx86_64
have minimum API levels of 21. Trying to use a lower value may work, but it's highly likely they won't work, because of e.g. native linker symbol references.In any event, anything prior to API-16 won't be QA'd or supported.
Which is a long-winded way of saying that this problem space is more complicated, and we need to come up with a more complete (and updatable!) solution.
Just making
AndroidVersions.KnowVersions
public Is Not The Correct Approach.The text was updated successfully, but these errors were encountered: