The goal of this issue is to investigate ways to support Android API level < 26 (current requirement for core 2.X and sdk 3/4).
SDK users: please like (and subscribe to get notified of progress) this issue. This will allow us to gage the interest of the community for this work. Don't hesitate to engage in the conversation either.
The current SDK requires API level >= 26 mostly because of the downstream requirements from azure-core/azure-identity. The azure team made a choice of shipping libraries for Java developers first, which might work for Android developers. We (the graph sdk team) have aligned on that decision because we're dependent on them, lack of resources to develop 2 SDKs for the same eco-system, and because of usage data.
Besides the authentication aspects, we've later on made the choice to provide the best Java development experience at the expense of Android backwards compatibility: those productivity features include CompletableFutures, some streaming and string encoding capabilities and more. The easiest way to get an exhaustive list of such platform features is to downgrade the api level of the android linting project and look at the list of errors.
The eco-system usually targets API level 19 or 21, respectively supporting 98.1% and 94.1% of android phones our there at the time of writing (android studio, file, new project, help me choose the api level). And the library authors go one of multiple ways:
- Complete separate package names between the Java and Android version (most likely what Azure will do)
- Same package names, but variants in the version (guava is a good example)
- Support only a single platform (our current case)
On top of all this considerations, the chosen approach should consider the following aspects:
- Don't degrade the Java development experience.
- Avoid significant maintenance burden.
- Be mindful of package sizes as it impacts distribution of the resulting apps. We probably should target an SDK size of <2MB. (excluding downstream dependencies) Proguard/r8 helps keeping apps small but brings a whole set of other issues.
- Look at kotlin.
- Look at the existing closed issues and PRs in this repo and in the service repo.
AB#10300
The goal of this issue is to investigate ways to support Android API level < 26 (current requirement for core 2.X and sdk 3/4).
SDK users: please like (and subscribe to get notified of progress) this issue. This will allow us to gage the interest of the community for this work. Don't hesitate to engage in the conversation either.
The current SDK requires API level >= 26 mostly because of the downstream requirements from azure-core/azure-identity. The azure team made a choice of shipping libraries for Java developers first, which might work for Android developers. We (the graph sdk team) have aligned on that decision because we're dependent on them, lack of resources to develop 2 SDKs for the same eco-system, and because of usage data.
Besides the authentication aspects, we've later on made the choice to provide the best Java development experience at the expense of Android backwards compatibility: those productivity features include CompletableFutures, some streaming and string encoding capabilities and more. The easiest way to get an exhaustive list of such platform features is to downgrade the api level of the android linting project and look at the list of errors.
The eco-system usually targets API level 19 or 21, respectively supporting 98.1% and 94.1% of android phones our there at the time of writing (android studio, file, new project, help me choose the api level). And the library authors go one of multiple ways:
On top of all this considerations, the chosen approach should consider the following aspects:
AB#10300