Clearly define and document minimum support API level

[baywet]

related #542
related #286
related #530

There's a number of instances where we are using runtime APIs that are not available in Android, or only available for specific API levels and up. Saying "this library requires java X" is not enough as not all java 8 APIs are available on android to this day and desugaring won't bring those APIs to a specific API level.
During this evaluation we should consider downstream libraries, market shares of different android versions, and code of "writing legacy code/workarounds".
Once an API level is selected, we need to hunt for any transgression and set tooling to check for use of APIs unavailable for a specific API level. (static analysis)
This should be possible via the android configuration in build.gradle which should warn about any transgression once configured.

AB#6385

[atulgpt]

Hi @baywet thanks for considering documenting api requirement for android clients. Also what will be the minimum Api level supported here? Will the library support api version 21 as making anything above 21 will break a lot of already clients using this lib including us.

[baywet]

@atulgpt do you have metrics in terms of downloads of your apps per Android version you could share with us? (privately, not here) That'd give us a good idea of actual market distribution.

[atulgpt]

Hi @baywet can you share your email id so to contact you and this info can be provided?

[baywet]

vibiret@microsoft.com

[atulgpt]

Hi, @baywet sorry for the delay...I am still in process of finding out how to share that info with you and awaiting a response from our internal team. Once I get the info I will update you regarding the same

[baywet]

no worries, thanks for the follow up. We'd only need the aggregated data of course and if possible some breakdown per metric (like per countries for instance).

[atulgpt]

Hi @baywet I have send the mail regarding the info. I have shared the last month MAU percentage on the these OSs(Android 0S 5,6 and 7). I know it took a while for the approval but I am hoping that it is still not too late.

[baywet]

while we're still working to get other numbers from internal applications. I started looking into it to see what API do we actually depend on at this time.
Here is some early information from my research. To get the validation of the API level working, we need to use the android-library instead of the java-library plugin.
We could do this either of two ways:

• setup a more complex project structure with multiple build.gradle files, one for android and one for java lib. Although it complexifies the project structure, this is probably the safest and it'll keep current publishing configurations in place without risking to lose JIGSAW or other configurations
• revamp the current build.gradle and move the configurations in the android node, like msal. See msal content vs ours. This might require rework as some of the options might be different. Also the android library plugin publishes aar instead of jar, which all IDEs/platforms might not be compatible with. We might have to add configuration to enable both jar and aar. Although this is a riskier approach, it also has the benefit of enabling us to publish a proguard rule file.

Another interesting note is that azure-identity has two libraries https://github.com/Azure/azure-sdk-for-android and https://github.com/Azure/azure-sdk-for-java. (API level 21). For consistency we might have to either use variants or split into two build.gradle and run two publishing sequences to get two libraries under different names, or fork the library (would require a lot of additional maintenance)