IssueTracker

./gradlew installDebug also fails with the same error.

Furthermore, the -g option should not be added by default (with no way to disable) on all installs as it doesn't allow for easy testing of runtime permissions.

I'll fix this issue by simply adding a API level check. "-g" option was added at the level 23.
We had a discussion in the team and decided to set "-g" by default. Here's reasons: 1) testing libraries (e.g. Espresso, orchestrator, etc) require it. 2) Starting in Android 10, a dialog is displayed asking for permission when you run a legacy apps (https://developer.android.com/about/versions/10/privacy/changes?hl=en#user-permission-legacy-apps). This behavior change makes existing tests to be failed without "-g" option. 3) Dealing with the runtime permission check dialog in instrumentation tests is not easy and not reliable.

Defaulting it to enabled with a wrapped api level check is fine but it should also be possible to disable it in the AGP dsl. it should be left up to the developer to decide when the permissions are granted and when they aren't. Especially given where it is implemented it applies to all installs done by Gradle, not just during instrumentation tests.

I created b/160249205 for the DSL.

I am experiencing the same issue. My instrumentation tests are installed with permissions granted. This causes our builds to fail, as we have espresso tests to verify the user paths when permissions are not granted.
What is the ETA for this DSL for disabling the automatic permission granting for instrumentation tests?

If have changed the behaviour completely with the release 4.1.0 you should at least provide at the same time the DSL which disables new behaviour.
At the moment this issue blocks further updates of AGP and in the end is a blocker to migrate to Jetpack Compose for many developers.

The issue will be fixed in 3.5.2.

Note that MPP is not officially supported. It's not considered stable by JetBrains and things will change, and break.

Sure, we understand that. It would still be very cool if you guys would start trying to support it a little bit better. The technology is very exciting but it falls apart right in the moment when Android is involved. AS 3.6 (Beta 1) is already a huge step in the right direction and I am very glad for it. However, seeing 3.5.1 completly breaking MPP made me feel that no one at Google seems to care, which would be extremely disappointing.

I'm sorry but I think your are way too harsh. You choose to your very early beta software and thus you have to live with the consequences. In fact I think it works extremely well, we opened an issue as soon as it was found and it's being fixed in the next version, what more can you ask?  The workaround here is also very simple; use 3.5.0 until it's fixed.

Sorry, I think you were right: That sounded too harsh. We really want this technology to succeed and are investing heavily in it. Of course, there are some frustrations adapting something early and this is, of course, entirely our own risk. I really think MPP has a huge potential and you guys, at Google, are playing a major role in it. I have no right demanding that you support it, but as I said: It would be disappointing if you would not. Anyways, AS 3.6 beta 1 already solves many, many issues and I hope you are furtherly working together with JetBrains on making MPP great.

We need MPP!!!

Maybe fixed in AS 3.5.2 (mentioned in changelog https://androidstudio.googleblog.com/2019/11/android-studio-352-available.html). Can anyone confirm?

I can confirm that it works for one of our projects now!
Currently, this project, though: https://github.com/sellmair/mpp-playground/tree/android-conflicting-classpath-after-jvmJar cannot be imported into AS 3.5.2 for me right now. This is actually a demo project showcasing another issue: https://youtrack.jetbrains.com/oauth?state=%2Fissue%2FKT-34618
Trying to open the project did not result in any error message, but just did nothing. There is also no action shown when clicking on the build.gradle.kts file to import it (like in IntelliJ)