Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Android api level < 26 support #252

Closed
baywet opened this issue Jul 20, 2021 · 3 comments
Closed

Android api level < 26 support #252

baywet opened this issue Jul 20, 2021 · 3 comments
Assignees

Comments

@baywet
Copy link
Member

baywet commented Jul 20, 2021

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
@baywet
Copy link
Member Author

baywet commented Jul 20, 2021

Some additional context on the CompletableFuture choice microsoftgraph/msgraph-sdk-java#533

@perqin
Copy link

perqin commented Jul 22, 2021

On CompletableFuture before API 26:

CompletableFuture is added to Android SDK on API 24, which is used in msgraph-sdk-java-core v2 (for reference, an example of usage).

AGP 4.0.0+ offers Java 8+ API desugaring support, but unfortunately CompletableFuture is not listed in the supported API List yet.

@maisarissi
Copy link

Hey everyone.
Level 26 or later today support 91.1% of all Android devices: https://apilevels.com/
Since we haven't gotten much traction on this issue to support older versions, we are going to close this permanently or until we get a strong request from the community.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants