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 aad97f165317a6308dd34aeca33998c894743804. 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).
In short, what is the actual need behind PR dotnet/android-tools#57?
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: 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.
We need to better understand why
AndroidVersions.KnownVersionsneeds 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 aad97f165317a6308dd34aeca33998c894743804. The intention is that
xamarin-androidshould control which versions are "supported," via the presence of theAndroidApiInfo.xmlfiles. Using theAndroidApiInfo.xmlfiles 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 dotnet/android-tools#57?
This is in fact not correct either; there are limitations. Case in point: 06e920c.
NDK r19 -- which xamarin-android/master is now using -- has a minimum API level of 16...which varies across ABI targets.
armeabi-v7aandx86have a minimum API level of 16, whilearm64-v8aandx86_64have 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.KnowVersionspublic Is Not The Correct Approach.