Dependency change needs Android O?

[slowcar]

Without changing the library version, our build broke, and it looks like a depenency was changed, and now requires Android 0 (SDK 26)

This is the error we get:
com.android.tools.r8.a: MethodHandle.invoke and MethodHandle.invokeExact are only supported starting with Android O (--min-api 26)

The dependency graph lists
+--- com.microsoft.graph:microsoft-graph:3.5.0
| +--- com.google.code.gson:gson:2.8.6
| --- com.microsoft.graph:microsoft-graph-core:2.0.2
| +--- com.squareup.okhttp3:okhttp:4.9.1 (*)
| --- com.azure:azure-core:1.16.0

We are currently on minSDK 21 for our app and use desugaring, as suggested in your description.

When we exclude azure-core, we can build the library:

implementation ('com.microsoft.graph:microsoft-graph:3.6.0') {
exclude group: 'com.azure', module: 'azure-core'
}

It looks like everything is working, but i'd rather ask if we can skip this dependency.
It's a bit strange, that the SDK requirement changed without any warning. Our CI built the branch successfully yesterday (31.05. at 13:16 CEST)
AB#9657

[baywet]

Hi @slowcar
Thanks for reaching out.
microsoft-graph doesn't have a direct dependency on azure-core

microsoft-graph-core used to have a dependency on azure-identity that was replaced by azure-core. This change shipped with version 2.0.2. We've made that change as graph core was not using anything from azure identity, only from azure core. Making the overall total weight smaller for people not leveraging azure identity as the authentication provider.
This change rolled out in microsoft-graph with version 3.5.0.

Azure-identity has always had a dependency on azure-core.

So effectively, unless your application was previously excluding azure identity or azure core, it always had azure core as an upstream dependency. What could have happened is either:

• Your application upgraded from microsoft-graph 3.4.0 or below to 3.5.0 or above
• Your application upgraded from microsoft-graph-core 2.0.1 or below to 2.0.2 or above.
• Your application upgraded an upstream dependency (azure-identity, core, or upstream) and an API level change was included in the newer version.

Since version 3.X the required API level has always been 26. As far as I can remember this level was mostly required by upstream dependencies like the azure ones.

It's fine for you to exclude that dependency as long as your application is not using the token credentials auth provider.

Hopefully this provides clarity on the API level requirement and what could potentially have changed. Let us know if you have any further question.

[slowcar]

Thank you for the quick reply. I am not sure what exactly triggered the build issue, just that we located it in the azure-core and "resolved" it by removing the dependency.
We used 3.5.0 successfully for some time. We don't have a dependency to graph-core (only through the graph sdk), and also no other related libraries as far as i know.

We don't use the token auth provider, we already have msal handling the authentication and use that.

Regarding the minSDK, your readme states "Android developers targeting lower android API levels can do so by enabling desugaring in their project.", which we did, so i wondered what exactly could have changed.

[baywet]

You're welcome! I'm not sure what triggered the change for your application either but I wanted to list out the different things that could have. As I understand your question is answered, I'm going to go ahead and close this issue.

[perqin]

Desugaring doesn't work in my case. Graph Core v2 uses CompletableFuture, which is not yet supported by AGP's desugaring library. I have to downgrade Graph SDK to v2 which depends on Graph Core v1.

[baywet]

would using a package like android-retrofuture bring compatibility for your project?

[perqin]

No, I've tried it but with no luck. android-retrofuture offers CompletableFuture under the java9.* package, but Graph Core v2 uses one under java.*.

[baywet]

Oh so the references are broken. Interesting I thought they'd have used the same package name to offer a drop in replacement. Assembly redirect in dotnet doesn't seem to have an equivalent in Java /android ecosystems unfortunately. The alternative would be to find another package that backports futures, on the same package name. An equivalent to polyfill in JavaScript.

[perqin]

Copying and re-positioning retrofuture might work, I would have a try some day. Is is possible to avoid using CompletableFuture in Graph Core library?

[baywet]

The completableFuture usage is only at a dozen places or so in core today, so it might be feasible to do without. However the service library (this repo) depends on it at thousands of places, which makes things a bit trickier.
We're ramping up additional people on the team, which should allow us to give more time to the android story. I started an issue to collect all the pain points and potential solutions microsoftgraph/msgraph-sdk-java-core#252
Would you mind commenting on why the current SDK does and doesn't work for you please? thanks!

[perqin]

@baywet I've added the comment to that issue.

[ed-mauro]

Readme should be changed since it is misleading: "Android developers targeting lower android API levels can do so by enabling desugaring in their project.". It does not work.

[baywet]

Thanks for the feedback everyone. We're still trying to find a definitive answer to android API level < 26. But we can update the documentation in the meantime. I've logged #872 to tackle that.
Please go over microsoftgraph/msgraph-sdk-java-core#252 and provide as many details/feedback points as you can as: the API level you'd like to target, what language are you writing in (Kotlin, Java, Scala...), how would you handle asynchronous work (alternative to completable future)...