Support for legacy multidex test APK [37324038]

Fixed

Bug

NeedsInfo

Migrated-Tools-Gradle

Status Update

No update yet.

Description

ma...@gmail.com

created issue #1

Apr 6, 2017 10:48AM

Android Studio 2.4 Preview 4
Build #AI-171.3870562, built on April 1, 2017
JRE: 1.8.0_112-release-b736 x86_64
JVM: OpenJDK 64-Bit Server VM by JetBrains s.r.o

gradle-3.4.1
classpath 'com.android.tools.build:gradle:2.4.0-alpha4'
buildTools : '25.0.1',
compileSdk : 25,
javaVersion: JavaVersion.VERSION_1_8,
minSdk : 16,
targetSdk : 25

Multidex is setup and works fine (compile, assemble and espresso test) with:
classpath 'com.android.tools.build:gradle:2.3.0'

When we bump up to 2.4 alpha 4 we get multidex issue when we try to run the tests:
(I repeat multidex is setup properly and everything works fine on plugin 2.3.0)

This is a scaffold-like very close to our project setup that I created to reproduce various gradle issues we encounter with our enteprise project:

https://github.com/originx/Gradle_troubles_android_enteprise
(sadly I did not update it and maintain it in some time I can refresh it if you really need it or feel free to fork or PR)

This is the stacktrace of the issue

https://gist.github.com/originx/c79f75517b7b2cef09e8c8904086eee4

This is the command I ran on our project (should be the same on example project I attached)
./gradlew clean connectedNonpayUnitedStatesBleedingDebugAndroidTest --stacktrace

but I repeat I do not know yet does that project compiles even with the new plugin I can update it later on if you need it.

Comments

uc...@google.com <uc...@google.com> #2Apr 6, 2017 06:08PM

For the KSerializer to Saver direction,

val <T : Any> KSerializer<T>.saver: Saver<T, SavedState> get() = Saver(
    save = { encodeToSavedState(this@saver, it) },
    restore = { decodeFromSavedState(this, it) },
)

is working well.

It would be great if this was provided somewhere in a library.

je...@google.com <je...@google.com> Apr 12, 2017 04:39PM

Assigned to ga...@google.com.

ga...@google.com <ga...@google.com> #3Apr 13, 2017 11:01AM

Status: New

We're focusing our support on KSerializer.toSaver(). We won't be implementing Saver.toSerializer() because KSerializer works with any Encoder/Decoder and trying to use a Saver to encode any other format besides SavedState/Bundle would be an error.

ga...@google.com <ga...@google.com> #4Apr 20, 2017 04:32PM

We plan to introduce KSerializer.toSaver() in androidx.compose.runtime.saveable as an optional feature. We will include an dependency on KTX Serialization (if not used by clients, R8 will remove it) but will not depend on savedstate, as the implementation here does not rely on any savedstate-specific symbols.

ha...@googlemail.com <ha...@googlemail.com> #5Apr 21, 2017 10:41AM

Project: platform/frameworks/support
Branch: androidx-main
Author: Marcello Galhardo <mgalhardo@google.com>
Link: https://android-review.googlesource.com/3497596

Expose SavedStateConfig properties as public

Expand for full commit details

Expose `SavedStateConfig` properties as public 
 
- We have cases where `SavedStateConfig` properties need to be used in other modules, such as handling fallbacks with `serializersModule.serializer()` to support contextual and polymorphic serializers. 
- To follow KTX Serialization convention, we are keeping `SavedStateConfig` properties public, similar to how `JsonConfiguration` does. 
 
RelNote: "`SavedStateConfig` properties are now public, enabling other modules to use these configurations." 
Bug: 378897438 
Test: N/A 
Change-Id: Ie5f4997bc61932de390da3699339e01b2e91b514

Files:

M savedstate/savedstate/api/current.txt
M savedstate/savedstate/api/restricted_current.txt
M savedstate/savedstate/bcv/native/current.txt
M savedstate/savedstate/src/commonMain/kotlin/androidx/savedstate/serialization/SavedStateConfig.kt

Hash: ec92c9e6c519cd5c3b3ea54ea523e4b7dc2a15dc
Date: Tue Feb 18 14:27:58 2025

ha...@googlemail.com <ha...@googlemail.com> #6Apr 21, 2017 11:54AM

We’ve decided not to provide a public helper function for converting from Saver to KSerializer, as we’re planning to implement a rememberSaveable function that accepts a KSerializer (see b/376028110). At this time, we haven’t identified any use case where manual conversion would be preferred over using the new rememberSaveable variant.

(Please note that we introduced an internal helper function in aosp/3498639, which will be used internally by the new rememberSaveable variant.)

ha...@googlemail.com <ha...@googlemail.com> #7Apr 22, 2017 11:09AM

The following release(s) address this bug.It is possible this bug has only been partially addressed:

androidx.compose.runtime:runtime-saveable:1.9.0-alpha01
androidx.compose.runtime:runtime-saveable-android:1.9.0-alpha01
androidx.compose.runtime:runtime-saveable-jvmstubs:1.9.0-alpha01
androidx.compose.runtime:runtime-saveable-linuxx64stubs:1.9.0-alpha01
androidx.compose.ui:ui-tooling:1.9.0-alpha01
androidx.compose.ui:ui-tooling-android:1.9.0-alpha01
androidx.compose.ui:ui-tooling-jvmstubs:1.9.0-alpha01

je...@google.com <je...@google.com> Apr 24, 2017 05:27PM

Assigned to ga...@google.com.

ga...@google.com <ga...@google.com> #8Apr 27, 2017 03:05PM

Verified by ga...@google.com.

Your tests do not fit into a single dex file. I've tried plugin 2.3.0 (I've also had to enable retrolambda for app, core, and pay modules), and the number of references that are generated is higher than 64k.
Please note that if you are using plugin's internal or Retrolamba support for Java 8 language features, for each lambda expression you will generate 3 additional references, so it might affect your reference count quite significantly.

ma...@gmail.com <ma...@gmail.com> #9Apr 27, 2017 04:03PM

Hello and thank you for the reply. What is the expected fix for this the ticket status was moved to "verified (fixed)" it is rather confusing for me. Do you suggest we have too many tests and that's it?
Could you please clarify?
Thank you for your time

ga...@google.com <ga...@google.com> #10Apr 27, 2017 05:29PM

Status: Won't Fix (Intended Behavior)

Your test sources and test-only dependencies are generating too many references. Java 8 language features are not related to this, as even when I remove compileOptions from all modules, the test dependencies cannot fit into a single dex file.

I suggest you take a look at Proguard rules that you can specify when running the tests -

https://google.github.io/android-gradle-dsl/current/com.android.build.gradle.internal.dsl.ProductFlavor.html#com.android.build.gradle.internal.dsl.ProductFlavor:testProguardFile(java.lang.Object). I've also updated the bug status, not to be confusing.

ma...@gmail.com <ma...@gmail.com> #11Apr 27, 2017 05:36PM

Hello,

Thank you for the link and clarification.
Pardon my many questions I just want to understand the problem better.

We use proguard for the app and define proguard rules which classes to keep for the test runner that we need early on in the start of the test run.
Why did it work with older build tools?
Also why doesnt multidex work for the test app or proguard rules from the debug builds?

Thank you for the quick response

ga...@google.com <ga...@google.com> #12Apr 28, 2017 10:46AM

Status: Assigned (reopened)

No worries Mario, I would also like to understand where the issue is coming from :)

The fact that it worked with 2.3.0 and not with 2.4.0-alpha4 is worrying. Because I am unable to reproduce with the test project you've provided, can you please compare the contents of build/intermediates/transforms/preDex/androidTest/ when building tests:
- from clean, with 2.3.0
- from clean, with 2.4.0-alpha4, with -Pandroid.useDexArchive=false
The content of these 2 directories should be the same. Please report any differences.

The support in the test runner is missing to be able to run test apk with multiple DEX files. I don't have much more info on it, sorry.

ma...@gmail.com <ma...@gmail.com> #13May 2, 2017 08:49AM

Hello,

sorry I am a bit restricted in the work environment so I cannot build the demo project from this location but I executed a diff on a real project where the issue happens for dex folders (predex is not available in 2.3.0) its disabled for our project.

this is for 2.3.0 and 2.4.0-alpha4 in location build/intermediates/transforms/dex/androidTest/nonPayMexicoBleeding for following command:
./gradlew clean connectedNonpayMexicoBleedingDebugAndroidTest
I used flag -Pandroid.useDexArchive=false for 2.4.0 only.

diff -rq nonpayMexicoBleeding\ 2.3.0/ nonpayMexicoBleeding\ 2.4.0-alpha4/
Result:
Only in nonpayMexicoBleeding 2.3.0/debug/folders/1000: 1
Only in nonpayMexicoBleeding 2.3.0/debug/folders/1000: 10
Only in nonpayMexicoBleeding 2.4.0-alpha4/debug/folders/1000: 1f

Does this help?

ma...@gmail.com <ma...@gmail.com> #14May 4, 2017 12:01PM

I updated the demo project so you have reproducable example:

https://github.com/originx/Gradle_troubles_android_enteprise

./gradlew clean connectedNonpayMexicoBleedingDebugAndroidTest

Gradle 3.4.0-alpha7 breaks
Commit: ca9e7f7134e5418f9e27e3164efe25521a324a46

Gradle 3.1.2 works
Commit: cfa48cf0b25427d48b328ef6cf80d51fc4e5933b

Cheers

ga...@google.com <ga...@google.com> #15May 4, 2017 12:17PM

Thanks for creating a repro project. I'll try it asap.

ga...@google.com <ga...@google.com> #16May 4, 2017 07:50PM

It works with 2.3.1 because we do not merge the individual dex files, so every test dependency gets dexed individually, and packaged in the test APK. In 2.4.0-alpha7, we are merging all test dependencies to a DEX file, and in this case, they do not fit.

je...@google.com <je...@google.com> #17May 4, 2017 08:39PM

so we would need to turn on multidex on the test APK to make this work ?

ga...@google.com <ga...@google.com> #18May 4, 2017 08:44PM

I think we can do the following:
- If the tested app is mono-dex, test will be mono dex for < 21, and multidex for 21+.
- If the tested app is native multidex, test is as well.
- And if the tested app is legacy multidex, test is mono dex (because currently the test runner does not support pre 21 test multidex apks).
WDYT?

ma...@gmail.com <ma...@gmail.com> #19May 4, 2017 08:51PM

Hello,

Sounds like a solution that would make it work on gradle 3.4.0>= ?

What are the side effects from the architecture point of view, performance etc, depending on the effort there would it pay off to bring full multidex support to test runner and test apk both?

I always find it confusing what is the difference between:
-multidex test apk
-multidex test runner

I thought that multidex apk is already supported by MultidexInstrumentationTestRunner

https://developer.android.com/reference/com/android/test/runner/MultiDexTestRunner.html

so that should work, or are you suggesting to introduce the multidex support to the test runner also (what is less effort and more benefit from your side? )

Best regards & thanks for your time

ga...@google.com <ga...@google.com> #20May 5, 2017 03:06PM

I am not sure when the fix would land (hopefully in the next 1-2 canary releases).
For api levels 21+, ART supports multidex for both the test apk and tested apk, so nothing needs to be done there, and there is no performance penalty. However, multidex for < 21 requires patching the class loader, which is done by the test runner for the tested APK. The test runner is unable to patch the class loader for the test apk though, and we this change is not going to change that. So if you are testing your application with min sdk below 21, you will still have to make sure that the test apk contains a single DEX file.

ma...@gmail.com <ma...@gmail.com> #21May 5, 2017 03:09PM

Hello,

thank you for the explanation. But I still dont understand why did it work before for api <21, what broke it?

Will that be fixed?

Thank you for your time.

ga...@google.com <ga...@google.com> #22May 5, 2017 03:58PM

You might have been able to build a multidex test apk for api < 21, but I am pretty sure you were not able to run all tests on a device < 21 unless you've written your own test runner that patches the class loader. I'd like to avoid this runtime failure scenario. We should break the build until the support for legacy multidex test apk is added.

ma...@gmail.com <ma...@gmail.com> #23May 5, 2017 04:03PM

Hello,

If this is a decision from the Android team, could you at least give us instructions how to do this patching on our own. I am amazed that we did not see so much breaking problems up until now, but you are telling us that technically we had a bug/s that is now exposed with the change you guys did now.
Is there a way to add this manual patching by ourselves then, and how to do it?

Thx for the support.

ga...@google.com <ga...@google.com> #24May 5, 2017 04:07PM

There is a work in progress to add the support for the legacy multidex test apks, but I am not sure when it might land -

https://android-review.googlesource.com/#/c/276561/.

ma...@gmail.com <ma...@gmail.com> #25May 5, 2017 04:21PM

I understand I will take a look at the commits and try to understand what was done there.
Is there a way to connect this bug to that commit and somehow get an ETA, we rely heavily on our instrumentation for a safety net and this is a show stopper for us so I need to relay and prioritize this information accordingly in the company.

To be honest the biggest worry for me here is that some of the classes you have there are package protected e.g. MultidexExtractor (from the first glance) so I would have to find a way to find proper list of dex files created from test apk, instrumentation and the app and sum them together in the test runner, not sure can I duplicate this behaviour but I will take a look in it in more detail starting next work week.

ga...@google.com <ga...@google.com> May 5, 2017 04:35PM

Accepted by ga...@google.com.

ma...@gmail.com <ma...@gmail.com> #26May 8, 2017 09:16AM

Hello, the merge strategy for commits you sent is: "Strategy Merge if Necessary"
Could we link this bug to the commits and merge them in 2.4.0?

Thanks

ga...@google.com <ga...@google.com> #27May 9, 2017 09:39AM

Marked as fixed.

ag/I6425e061a2d5e97e36c56fc01c009475af62c086 allows native multidex test apks. Legacy multidex tested app still requires mono-dex test apk. It should be released in the next canary release of the plugin.

@Mario The change is part of the multidex support library, and that is released as part of the SDK (not plugin nor Android Studio). Once the change is in, I will work on adding the support in the plugin. Unfortunately, I cannot provide any ETA. The owner of that change is aware of this bug (it is referenced from an internal bug report that is assigned to him).

jw...@gmail.com <jw...@gmail.com> #28May 13, 2017 05:16PM

So the TL;DR is:

1. using native multidex, the fix will be available in the next gradle plugin releases (after 2.4.0-alpha7)
2. using legacy (i.e. support) multidex, we'll have to wait until a new release of com.android.support:multidex:1.0.x library

Do I have that right?

ga...@google.com <ga...@google.com> #29May 15, 2017 08:28AM

Yes, that is correct.

dr...@gmail.com <dr...@gmail.com> #30Jun 4, 2017 06:34AM

"We should break the build until the support for legacy multidex test apk is added."

This causes quite a bit of pain for my team. We currently have a test apk with more than 65k referenced methods (we're already running proguard on the test apk), and we're depending on it building properly. Our minSdkVersion is 18, but we only run our instrumentation tests on API 21+, so the old behavior allowed us to continue running our tests.

With the new behavior in AGP 3.0, our test apk fails to even build. It seems like my only options are:
1) Reduce the number of referenced methods
2) Create a new variant or flavor with minSdk 21+ and use that for running tests
3) Use minSdk 21 for all debug builds

The first option isn't really feasible, and the second is massively painful because it requires us to retrain 50+ devs on which gradle commands to use to run tests (since the commands change when adding a variant or flavor). The third option also isn't ideal because then we lose lint validation for our real minSdkVersion and lose the ability to easily run debug builds on older android versions manually.

Is there any way to keep the behavior from AGP 2.3.x for building test apks until a proper solution for legacy multidex is available?

jw...@gmail.com <jw...@gmail.com> #31Jun 5, 2017 02:15AM

@dr... for your specific situation, why not just stay on 2.3 until 2.4 (or 3.0) is out of alpha? Having 50 devs on alpha anything seems really iffy.

dr...@gmail.com <dr...@gmail.com> #32Jun 5, 2017 02:30AM

Yeah, definitely. We're not planning to upgrade until 3.0 is stable, but I'm worried that it will get to the stable channel without this being fixed. If legacy multidex support for test apks is ready before 3.0 is stable, then I don't have a problem :)

ma...@gmail.com <ma...@gmail.com> #33Jul 18, 2017 07:04AM

Hello,
since the multidex 1.0.2 is live I would expect that multidex works fine on api <21 for test apks, but this is not the case.
Did I misunderstand something when you said this will be backported to legacy multidex so test apk can contain multiple dex files also or?

classpath 'com.android.tools.build:gradle:3.0.0-alpha7'
multidex : '1.0.2',
Android Studio 3.0 Canary 7
Build #AI-171.4182969, built on July 14, 2017
JRE: 1.8.0_152-release-884-b01 x86_64
JVM: OpenJDK 64-Bit Server VM by JetBrains s.r.o
Mac OS X 10.12.4

ga...@google.com <ga...@google.com> #34Jul 20, 2017 04:43PM

The support for legacy multidex test apks has been merged in AOSP, but a new version of com.android.support:multidex has not been published yet. We need this artifacts published in order to add support for legacy multidex test apks in the Android plugin for Gradle.

ma...@gmail.com <ma...@gmail.com> #35Jul 20, 2017 05:29PM

Hello,
Thank you for the answer but I don't understand what is inside multidex 1.0.2 then.

in support lib Revision 25.4.0 it is stated:
Concurrent with this support library release, we are also releasing multidex version 1.0.2. This version includes the following important changes:
Allows multidexing of instrumentation APK.
Deprecates MultiDexTestRunner (AndroidJUnitRunner should be used instead).

We use multidex 1.0.2. Does this mean this fix will come out in 1.0.3, do you have any eta window on this topic?

Cheers

ga...@google.com <ga...@google.com> #36Jul 21, 2017 01:44PM

Indeed, 1.0.2 contains all the necessary support, but the support in the plugin is missing. I will try to get the plugin changes published in the next few preview releases, but I cannot give any hard guarantees when it will happen.

ma...@gmail.com <ma...@gmail.com> #37Jul 21, 2017 03:57PM

Thank you for the clarification. Could you please update the documentation that the new support/ multidex lib is not integrated in tooling yet. Also in gradle build files lint recommends removing the "dev" flavor since it is not needed anymore but then it would break tests, instant run etc. also an important thing to note.
Looking forward to the integration let us know when you manage to merge it.
Have a nice weekend!

ga...@google.com <ga...@google.com> #38Aug 3, 2017 05:41PM

Status: In Progress (Accepted) (reopened)

I am reopening this, as we have too many reports. It is blocked on internal issue

b/62286076

ma...@gmail.com <ma...@gmail.com> #39Aug 28, 2017 08:44AM

hello, what is the current progress of this issue?

thank you

ga...@google.com <ga...@google.com> #40Aug 30, 2017 02:28PM

@39 The support in the plugin is ready, however we need a new version of build tools published. Hopefully that will happen soon.

ma...@gmail.com <ma...@gmail.com> #41Aug 30, 2017 02:36PM

this is amazing news, could you please update the status of this ticket when this happens?

does this mean this will come out with beta4?

ga...@google.com <ga...@google.com> #42Aug 30, 2017 02:50PM

Build tools are published independently of the plugin and Android Studio, but I hope that will happen in the next week or two. I'll update the bug once it happens.

ja...@gmail.com <ja...@gmail.com> #43Aug 30, 2017 02:58PM

@42 1.0.2 does provide support for multidex android test APKs.

Simply create a "CustomerTestRunner" and override "onCreate" to call "MultiDex.installInstrumentation(context, targetContext)". See this example:

https://github.com/jaredsburrows/android-gif-example/blob/master/src/androidTest/kotlin/test/CustomTestRunner.kt#L12.

ja...@gmail.com <ja...@gmail.com> #44Sep 10, 2017 01:18AM

It seems that multidex 1.0.2 works with multidex test apks for AGP 2.3.0, not 3.0.0+.

yo...@gmail.com <yo...@gmail.com> #45Sep 11, 2017 04:21PM

#44 Make sure you use ATSL runner 1.0.1 or later.

ja...@gmail.com <ja...@gmail.com> #46Sep 11, 2017 04:26PM

I am:

https://github.com/jaredsburrows/android-gif-example/blob/master/gradle/versions.gradle.kts#L75.

st...@gmail.com <st...@gmail.com> #47Sep 14, 2017 06:26PM

We discovered this problem too. It's quite annoying for us and we will have to reverse switching to GAP 3 if there is no fix in the next 2 days...

Can anyone give us an update and an ETA for this ?
We use build tools 26.0.1, gap 3 beta 5, ASTL runner 1.0.1.

st...@gmail.com <st...@gmail.com> #48Sep 14, 2017 07:14PM

As a workaround, how can we run proguard on the instrumentation apk, when it is not enabled in our debug variant for the main app ?

ja...@gmail.com <ja...@gmail.com> #49Sep 14, 2017 07:46PM

You do not want to proguard a debug apk. It would take forever to write and
run new tests.

Jared Burrows

*jaredsburrows@gmail.com <jaredsburrows@gmail.com>*
LinkedIn:

https://www.linkedin.com/in/jaredsburrows

On Thu, Sep 14, 2017 at 12:14 PM, <buganizer-system@google.com> wrote:

- Show quoted text -

dr...@gmail.com <dr...@gmail.com> #50Sep 14, 2017 08:25PM

Until this issue is fixed, many apps will have no choice but to proguard their test apk :)

st...@gmail.com <st...@gmail.com> #51Sep 14, 2017 08:48PM

I agree, this workaround is not a good solution.

st...@gmail.com <st...@gmail.com> #52Sep 15, 2017 07:17AM

On our side, we fixed the issue by cutting down on our dependencies in the instrumentation apk. Though the dex count is still in the red zone and we will be happy to see the issue fix, but there is no more emergency on our side.

je...@google.com <je...@google.com> #53Sep 18, 2017 06:18PM

Marked as fixed.

Fixed, bug tracking the release :

https://buganizer.corp.google.com/issues/65838025

ja...@gmail.com <ja...@gmail.com> #54Sep 18, 2017 06:47PM

I see it is tracked in Moma. Is this set for marked release for 3.0.0-beta7? or release?

[Deleted User] <[Deleted User]> #55Sep 22, 2017 12:57PM

was the fix included in the latest release of build tools 26.1? I think the link to track the release is not public.

za...@gmail.com <za...@gmail.com> #56Oct 5, 2017 11:51AM

It still doesn't work for me on 3.0.0-beta7 and Build tools 26.0.2 - I still get the error.

[Deleted User] <[Deleted User]> #57Oct 5, 2017 02:08PM

Status says fixed but could we get instructions on how to make it work? Is this already included in Build tools 26.0.2 and AGP 3.0.0-beta7?

le...@gmail.com <le...@gmail.com> #58Oct 5, 2017 06:47PM

Same problem here... I don't see this issue as fixed

ga...@google.com <ga...@google.com> #59Oct 6, 2017 12:46PM

Status: In Progress (Accepted) (reopened)

The issue has not been fixed in beta7, as build tools 26.0.2 are missing some of the pieces to have this working. Re-opening.

ja...@gmail.com <ja...@gmail.com> #60Oct 6, 2017 05:00PM

Thank you.

vy...@pinterest.com <vy...@pinterest.com> #61Oct 26, 2017 03:11PM

Is there an ETA? Looks like build tools 27.0.0 shipped without this fix.

cm...@google.com <cm...@google.com> Nov 2, 2017 04:01PM

Assigned to cm...@google.com.

gl...@fitbit.com <gl...@fitbit.com> #62Nov 7, 2017 04:59AM

Any ETA on this? Or which components we should watch for updates? Is the the build tools 2x.0.y? Is it a new multidex support lib 1.0.3? 3.1 plugin?

cm...@google.com <cm...@google.com> #63Nov 7, 2017 10:05AM

Sorry, we don't commit to timelines on public bugs.

All the changes needed are submitted to the four components (build tools, MultidexTestRunner, AndroidJunitRunner and android gradle plugin) and we'll update this bug as soon as it is released, so it will be in Android Gradle Plugin 3.1.

Note that both the deprecated MultiDexTestRunner and the replacement AndroidJUnitRunner will support legacy multidex test APKs

sz...@gmail.com <sz...@gmail.com> #64Nov 7, 2017 11:19AM

Could you consider releasing the fix under 3.0.x (if that's even possible)?
Doing it in 3.1 will require everyone who wants to have multidex for test APK working to start using unstable version of AS and AGP.

zt...@gmail.com <zt...@gmail.com> #65Nov 15, 2017 05:25PM

Please update documentation to reflect that legacy multidex IS supported, except broken by this bug (known issue) in AGP 3.0.

https://developer.android.com/studio/build/multidex.html#testing

> `Using multidex to create a test APK is not currently supported.`

cm...@google.com <cm...@google.com> Dec 20, 2017 05:54PM

Reassigned to ga...@google.com.

ga...@google.com <ga...@google.com> #66Dec 21, 2017 01:40PM

Marked as fixed.

This is fixed starting with 3.1.0-alpha04. Please try it out, and let us know if you are facing any issues. Thanks!

ja...@gmail.com <ja...@gmail.com> #67Dec 21, 2017 11:50PM

Is it not "MultiDex.installInstrumentation(getContext(), getTargetContext());" in the AndroidJUnitRunner?

an...@gmail.com <an...@gmail.com> #68Dec 23, 2017 02:07AM

3.1.0-alpha04 worked for me. Thanks for the fix.

le...@gmail.com <le...@gmail.com> #69Dec 27, 2017 06:26PM

I just trying with 3.1.0-alpha06 and the problem seams to still be there =/

[Deleted User] <[Deleted User]> #70Dec 27, 2017 07:07PM

This isn't working for me either with 3.1.0-alpha06. Can you clarify what was fixed, and what combination of Gradle, Android Gradle Plugin, Multidex library and Android Build Tools we should test against?

[Deleted User] <[Deleted User]> #71Jan 5, 2018 12:31PM

Folks, any news in this issue? Could you explain how to make this work? Simply using AGP 3.1.0-alpha04 doesn't solve the problem

[Deleted User] <[Deleted User]> #72Jan 5, 2018 09:33PM

Never mind. It does solve the problem

ga...@google.com <ga...@google.com> #73Jan 8, 2018 05:49PM

Re #70:
You need to use Android plugin for Gradle 3.1.0-alpha04+, any compatible version of Gradle (e.g. 4.4) and BuildTools (e.g. 27.0.3). Multidex library 1.0.2 will be added by the plugin as a dependency automatically. With this, your build will be successful.

To run tests successfully, the test runner needs to support legacy test APK. AndroidJUnitRunner supports that, so you can use that.

ma...@gmail.com <ma...@gmail.com> #74Jan 9, 2018 10:32AM

Looks much better but I still get an issue with multiDexKeepProguard file, it somehow feels it is not respected which classes should be added to the main dex file.
For example following your suggestion of tl;dr version the test crashes because some files are not found in the main dex file during the app start:

01-09 10:31:06.965 4861-4861/? W/dalvikvm: Class resolved by unexpected DEX: Ltimber/log/Timber$Tree;(0xa75def58):0x99f02000 ref [Lcom/google/devtools/build/android/desugar/runtime/ThrowableExtension;] Lcom/google/devtools/build/android/desugar/runtime/ThrowableExtension;(0xa75def58):0x99caf000
01-09 10:31:06.965 4861-4861/? W/dalvikvm: (Ltimber/log/Timber$Tree; had used a different Lcom/google/devtools/build/android/desugar/runtime/ThrowableExtension; during pre-verification)
01-09 10:31:06.965 4861-4861/? D/AndroidRuntime: Shutting down VM
01-09 10:31:06.965 4861-4861/? W/dalvikvm: threadid=1: thread exiting with uncaught exception (group=0xa66de228)
01-09 10:31:06.975 4861-4861/? E/InstrumentationResultPrinter: Failed to mark test No Tests as finished after process crash
01-09 10:31:06.975 4861-4861/? E/MonitoringInstr: Exception encountered by: Thread[main,5,main]. Dumping thread state to outputs and pining for the fjords.
java.lang.IllegalAccessError: Class ref in pre-verified class resolved to unexpected implementation
at timber.log.Timber$Tree.getStackTraceString(Timber.java:569)
at timber.log.Timber$Tree.prepareLog(Timber.java:544)
at timber.log.Timber$Tree.i(Timber.java:452)
at timber.log.Timber$1.i(Timber.java:288)
at timber.log.Timber.i(Timber.java:63)

Do you have any idea where does this pops out from?

ga...@google.com <ga...@google.com> #75Jan 9, 2018 11:38AM

Re #74:
This seems to be Java 8 specific bug, and I've filled

https://issuetracker.google.com/71737186 to track this. Can we please continue discussion there?

st...@gmail.com <st...@gmail.com> #76Feb 21, 2018 01:58AM

We would love to use this fix, but we need a stable version of the gradle android plugin. When will Gradle Android Plugin 3.1.0 be released ?

fu...@gmail.com <fu...@gmail.com> #77Mar 14, 2018 03:35PM

"Please " help me i want update oreo 8.0 without computer

[Deleted User] <[Deleted User]> #78Mar 27, 2018 06:33PM

The release note for 3.1.0 doesn't mention this issue, is it fixed ?

[Deleted User] <[Deleted User]> #79Mar 27, 2018 06:34PM

We are trying it and it looks like it's not working (though it used to be working in alpha04)

[Deleted User] <[Deleted User]> #80Mar 27, 2018 09:37PM

There is a bug of a new kind in 3.1 + related to instrumented APKs & multidex

Until recently we had a big module, with all our code + all our instrurmentation tests code. Then we could check and the plugin (3.1.alpha and 3.1) work well to enable multidex in tests apks.
But we recently dissociated this big module: one contains the production code, the other one contains the instrumentation code. And then, the new plugin breaks: we can still a multidex production app, but the instrumentation test apk is not generated. We hit the 65K limit and the build reports this as an issue. Also, the android test don't have a task: transformClassesWithMultidexlistFor<variant>AndroidTest

What can go wrong ?

[Deleted User] <[Deleted User]> #81Mar 28, 2018 12:44AM

To be more precise: we have one module named module_apk that contains:
* a few classes in production code
* quite a lot of classes of instrumentation tests

The module_apk wires together all other modules that are all library modules.

When adding multidexEnabled to module_apk, the production apk is multidexed, but not the test apk. There is no transform / task for the AndroidTest variant related to multidex.
When adding multidexEnabled to all default configuration of all modules, all of them have both instrumentation and production multidex tasks & transformations, all except module_apk...

We have no idea what is going wrong.

ga...@google.com <ga...@google.com> #82Mar 28, 2018 09:02AM

Re #81:
I've filled

https://issuetracker.google.com/77183226, let's please continue discussion there. Thanks.

[Deleted User] <[Deleted User]> #83Mar 28, 2018 09:41AM

What went wrong:
Execution failed for task ':app:transformClassesWithMultidexlistForLive'.
> com.android.build.api.transform.TransformException: Error while generating the main dex list.

ga...@google.com <ga...@google.com> #84Mar 28, 2018 10:51AM

Re #83: Please file a new issue, as that is error indicates there is a main dex list task error for the application, not for the test.

pe...@layer.com.c-02odbdyf.appstempdomain.goog <pe...@layer.com.c-02odbdyf.appstempdomain.goog> #85Apr 13, 2018 11:11PM

Echoing #78. Our instrumented tests using multidex worked using the 3.0.0 version of the Android Plugin for gradle. Updated to 3.1.1 and it would just say empty test suite. I found this bug then reverted back to 3.1.0-alpha04 and the tests work again. Should this be working in 3.1.1?

pa...@gmail.com <pa...@gmail.com> #86Apr 14, 2018 11:57AM

We (whoever has a repro) should probably file a new issue against 3.1.1 referencing this issue. This has been "marked as Fixed" 3 times... so it's possible the current problems are far from the original.

ga...@google.com <ga...@google.com> #87Apr 16, 2018 01:53PM

Re #85, #86:

Yes, please file a new bug, and paste the link here. Issue in #78 was due to a custom plugin which would disable multidex. Thanks!

pe...@layer.com.c-02odbdyf.appstempdomain.goog <pe...@layer.com.c-02odbdyf.appstempdomain.goog> #88Apr 16, 2018 03:53PM

Cool. Created

https://issuetracker.google.com/u/1/issues/78108767 for this

Issue 37324038

Description

Issue summary

Comments

uc...@google.com <uc...@google.com> #2Apr 6, 2017 06:08PM

je...@google.com <je...@google.com> Apr 12, 2017 04:39PM

ga...@google.com <ga...@google.com> #3Apr 13, 2017 11:01AM

ga...@google.com <ga...@google.com> #4Apr 20, 2017 04:32PM

ha...@googlemail.com <ha...@googlemail.com> #5Apr 21, 2017 10:41AM

ha...@googlemail.com <ha...@googlemail.com> #6Apr 21, 2017 11:54AM

ha...@googlemail.com <ha...@googlemail.com> #7Apr 22, 2017 11:09AM

je...@google.com <je...@google.com> Apr 24, 2017 05:27PM

ga...@google.com <ga...@google.com> #8Apr 27, 2017 03:05PM

ma...@gmail.com <ma...@gmail.com> #9Apr 27, 2017 04:03PM

ga...@google.com <ga...@google.com> #10Apr 27, 2017 05:29PM

ma...@gmail.com <ma...@gmail.com> #11Apr 27, 2017 05:36PM

ga...@google.com <ga...@google.com> #12Apr 28, 2017 10:46AM

ma...@gmail.com <ma...@gmail.com> #13May 2, 2017 08:49AM

ma...@gmail.com <ma...@gmail.com> #14May 4, 2017 12:01PM

ga...@google.com <ga...@google.com> #15May 4, 2017 12:17PM

ga...@google.com <ga...@google.com> #16May 4, 2017 07:50PM

je...@google.com <je...@google.com> #17May 4, 2017 08:39PM

ga...@google.com <ga...@google.com> #18May 4, 2017 08:44PM

ma...@gmail.com <ma...@gmail.com> #19May 4, 2017 08:51PM

ga...@google.com <ga...@google.com> #20May 5, 2017 03:06PM

ma...@gmail.com <ma...@gmail.com> #21May 5, 2017 03:09PM

ga...@google.com <ga...@google.com> #22May 5, 2017 03:58PM

ma...@gmail.com <ma...@gmail.com> #23May 5, 2017 04:03PM

ga...@google.com <ga...@google.com> #24May 5, 2017 04:07PM

ma...@gmail.com <ma...@gmail.com> #25May 5, 2017 04:21PM

ga...@google.com <ga...@google.com> May 5, 2017 04:35PM

ma...@gmail.com <ma...@gmail.com> #26May 8, 2017 09:16AM

ga...@google.com <ga...@google.com> #27May 9, 2017 09:39AM

jw...@gmail.com <jw...@gmail.com> #28May 13, 2017 05:16PM

ga...@google.com <ga...@google.com> #29May 15, 2017 08:28AM

dr...@gmail.com <dr...@gmail.com> #30Jun 4, 2017 06:34AM

jw...@gmail.com <jw...@gmail.com> #31Jun 5, 2017 02:15AM

dr...@gmail.com <dr...@gmail.com> #32Jun 5, 2017 02:30AM

ma...@gmail.com <ma...@gmail.com> #33Jul 18, 2017 07:04AM

ga...@google.com <ga...@google.com> #34Jul 20, 2017 04:43PM

ma...@gmail.com <ma...@gmail.com> #35Jul 20, 2017 05:29PM

ga...@google.com <ga...@google.com> #36Jul 21, 2017 01:44PM

ma...@gmail.com <ma...@gmail.com> #37Jul 21, 2017 03:57PM

ga...@google.com <ga...@google.com> #38Aug 3, 2017 05:41PM

ma...@gmail.com <ma...@gmail.com> #39Aug 28, 2017 08:44AM

ga...@google.com <ga...@google.com> #40Aug 30, 2017 02:28PM

ma...@gmail.com <ma...@gmail.com> #41Aug 30, 2017 02:36PM

ga...@google.com <ga...@google.com> #42Aug 30, 2017 02:50PM

ja...@gmail.com <ja...@gmail.com> #43Aug 30, 2017 02:58PM

ja...@gmail.com <ja...@gmail.com> #44Sep 10, 2017 01:18AM

yo...@gmail.com <yo...@gmail.com> #45Sep 11, 2017 04:21PM

ja...@gmail.com <ja...@gmail.com> #46Sep 11, 2017 04:26PM

st...@gmail.com <st...@gmail.com> #47Sep 14, 2017 06:26PM

st...@gmail.com <st...@gmail.com> #48Sep 14, 2017 07:14PM

ja...@gmail.com <ja...@gmail.com> #49Sep 14, 2017 07:46PM

dr...@gmail.com <dr...@gmail.com> #50Sep 14, 2017 08:25PM

st...@gmail.com <st...@gmail.com> #51Sep 14, 2017 08:48PM

st...@gmail.com <st...@gmail.com> #52Sep 15, 2017 07:17AM

je...@google.com <je...@google.com> #53Sep 18, 2017 06:18PM

ja...@gmail.com <ja...@gmail.com> #54Sep 18, 2017 06:47PM

[Deleted User] <[Deleted User]> #55Sep 22, 2017 12:57PM

za...@gmail.com <za...@gmail.com> #56Oct 5, 2017 11:51AM

[Deleted User] <[Deleted User]> #57Oct 5, 2017 02:08PM

le...@gmail.com <le...@gmail.com> #58Oct 5, 2017 06:47PM

ga...@google.com <ga...@google.com> #59Oct 6, 2017 12:46PM

ja...@gmail.com <ja...@gmail.com> #60Oct 6, 2017 05:00PM

vy...@pinterest.com <vy...@pinterest.com> #61Oct 26, 2017 03:11PM

cm...@google.com <cm...@google.com> Nov 2, 2017 04:01PM

gl...@fitbit.com <gl...@fitbit.com> #62Nov 7, 2017 04:59AM

cm...@google.com <cm...@google.com> #63Nov 7, 2017 10:05AM

sz...@gmail.com <sz...@gmail.com> #64Nov 7, 2017 11:19AM

zt...@gmail.com <zt...@gmail.com> #65Nov 15, 2017 05:25PM

cm...@google.com <cm...@google.com> Dec 20, 2017 05:54PM

ga...@google.com <ga...@google.com> #66Dec 21, 2017 01:40PM

ja...@gmail.com <ja...@gmail.com> #67Dec 21, 2017 11:50PM

an...@gmail.com <an...@gmail.com> #68Dec 23, 2017 02:07AM

le...@gmail.com <le...@gmail.com> #69Dec 27, 2017 06:26PM

[Deleted User] <[Deleted User]> #70Dec 27, 2017 07:07PM

[Deleted User] <[Deleted User]> #71Jan 5, 2018 12:31PM

[Deleted User] <[Deleted User]> #72Jan 5, 2018 09:33PM