IssueTracker

Adding "api 'com.android.support:multidex:1.0.2'" to the application module fixes the issue. But adding "implementation 'com.android.support:multidex:1.0.2'" doesn't.

Can you please share your build.gradle files (for application and android library), as I am unable to reproduce?

From the screenshot, classes8.dex contains only references to the MultiDexApplication, it does not contain definitions of the class. If you execute `dexdump <path_to_apk>` are you able to see the definition of MultiDexApplication?

See attachments for more info.

The difference when building from Studio is that we take into consideration the API of the device you are deploying to, so we might change legacy multidex build to a native multidex one. It looks like the device you are deploying to has API 25, so that is why APK differs when building from the command line and when building from the IDE. In legacy multidex we have requirements due to DalvikVM which classes are in the main dex, and that's why MultiDexApplication is in the classes.dex. However, for native multidex, ART is able to load classes from any classes<N>.dex file. So it is strange that the runtime is unable to find MultiDexApplication, when it's clearly in classes13.dex.

What is the device that you are trying to deploy the app to? From the screenshots it looks like it's a Chromebook?

I tested if the Chromebook was the issue by trying the same on the Nexus 6P running Oreo. And the Nexus 6P has the same issue.

The logcat says:

09-06 11:33:09.672 10942-10942/? E/dex2oat: Failed to open dex file from oat file. File: base.apk:classes8.dex Error: Failure to verify dex file 'base.apk:classes8.dex': Non-zero padding 65 before section start at ace
09-06 11:33:09.678 20659-10988/? I/CheckinUtil: Classify the device as Phone.
09-06 11:33:09.686 10942-10942/? I/dex2oat: dex2oat took 754.758ms (472.528ms cpu) (threads: 4)
09-06 11:33:09.693 581-23895/? E/installed: DexInv: --- END '/data/app/vmdl1021122682.tmp/base.apk' --- status=0x0100, process failed
09-06 11:33:09.694 581-23895/? E/installd: Failed to dexopt (256)
09-06 11:33:09.695 795-829/? W/PackageManager.DexOptimizer: Failed to dexopt
                                                            com.android.server.pm.Installer$InstallerException: android.os.ServiceSpecificException: Failed to dexopt (code 256)
                                                                at com.android.server.pm.Installer.dexopt(Installer.java:290)
                                                                at com.android.server.pm.PackageDexOptimizer.dexOptPath(PackageDexOptimizer.java:220)
                                                                at com.android.server.pm.PackageDexOptimizer.performDexOptLI(PackageDexOptimizer.java:175)
                                                                at com.android.server.pm.PackageDexOptimizer.performDexOpt(PackageDexOptimizer.java:123)
                                                                at com.android.server.pm.PackageManagerService.installPackageLI(PackageManagerService.java:18185)
                                                                at com.android.server.pm.PackageManagerService.installPackageTracedLI(PackageManagerService.java:17780)
                                                                at com.android.server.pm.PackageManagerService.-wrap33(Unknown Source:0)
                                                                at com.android.server.pm.PackageManagerService$6.run(PackageManagerService.java:15251)
                                                                at android.os.Handler.handleCallback(Handler.java:789)
                                                                at android.os.Handler.dispatchMessage(Handler.java:98)
                                                                at android.os.Looper.loop(Looper.java:164)
                                                                at android.os.HandlerThread.run(HandlerThread.java:65)
                                                                at com.android.server.ServiceThread.run(ServiceThread.java:46)
09-06 11:33:09.701 795-810/? I/ActivityManager: Force stopping com.visiolink.reader.wrapper appid=10264 user=-1: installPackageLI

See the attached file for the complete logcat.

I think it might be a 3. party library causing the issue. I will try to remove it and see what happens.

Logcat was missing in #6

It is this library that causes the issue:
https://github.com/chartbeat-labs/android_sdk

The library is initialized in Application.onCreate.

From the multidex docs:
Caution: Do not execute MultiDex.install() or any other code through reflection or JNI before MultiDex.install() is complete. Multidex tracing will not follow those calls, causing ClassNotFoundException or verify errors due to a bad class partition between DEX files.

So this library must be loading through reflection. But when is attachBaseContext called in relation to onCreate? And why does having the multidex dependency in the application module fix the issue?

I don't even need to initialize it. It fails just be including it as a dependency in the application module:
implementation 'com.chartbeat:sdk:1.3.4'

When running on Android N and above, MultiDex.install() is a no-op, so that is not where to problem is coming from.

However, your classes8.dex is corrupt, and all classes from classes8, 9, 10 etc will not be loaded. Considering that MultiDex is in classes13.dex, exception is thrown. When you add the multidex suppor library directly, we just end up packaging dex files in a way that does not break dex2oat.

This issue might be in the dex merger. Can you add android.useDexArchive=false to gradle.properties? After that, can you set android.useDexArchive=true and add android.enableD8=true?

android.useDexArchive=false => Fixes the issue

android.useDexArchive=true, android.enableD8=true: => Also fixes the issue.

Can you upload the dex file that breaks dex2oat i.e. classes8.dex from comment #7?

Broken classes8.dex

classes8.dex from #13, contains only Lorg/jetbrains/anko/IntentsKt.

Which version of Anko are you using? Do you maybe have your own fork of the anko library?

I am using the official version 0.10.1. I have been using that version since 3. of july.

Can you run with android.useDexArchive=true and android.enableBuildCache=false? I am wondering if we have a broken cached version of the library.

Thanks a ton to cmw@ for figuring this one out.

This is an actual bug in our dexing pipeline, because we reuse the array for writing out the result. Dx had an assumption that array will always be initialized with 0s, so whenever it had to add padding, it just didn't. This was a dx performance optimization, but it also breaks us, as some dex file might pick up remains of the previous one (and that was happening here).

I am working on a fix, should have something ready soon.

Great! For the record android.useDexArchive=true and android.enableBuildCache=false also fixes the issue.

Thanks for the bug report, the fix should land in the plugin 3.0.0-beta6.

ag/I5fbd7fad2fb70de709e03e71476222f967ad8a5a

Project: platform/dalvik
Branch: master

commit d67961b03525d8b58cfa55d33c8ca669dc16f563
Author: Jerome Dochez <jedo@google.com>
Date:   Fri Jun 16 18:28:03 2017

    Provide APIs to allow reusing the passed buffer.
   
    no functional changes.
   
    Test: existing.
   
    Change-Id: I30fbf02b92e804238807b4c98c3536c5c4c60ca4
   
    Consider DEX size for signature and checksum
   
    When calculating signature and checksum for a DEX
    file, consider the size of the DEX file, instead of
    the array. An array bigger than the file can be
    allocated, and this would lead to wrong signature
    and checksum calculation.
   
    Test: manually verified, existing tests
    Change-Id: I0b6ae946cca7c0e71bb5e1f0ecbe209b91347c9d
   
    Write zeros to byte array output
   
    Because we reuse the output array
    between seprate dx invocations, we
    must write zeros to array. Otherwise, we might
    end up picking up the output from
    previous invocation.
   
    Dx had an assumption that a new output
    array is always allocated, and it was
    a performance optimization not to write
    zeros out. That does not apply any more.
   
    BUG=65363025
    Test: ByteArrayAnnotatedOutputTest
   
    Change-Id: I984076e8078f9ed977f10cacb9b1b135b1d6358e

A       dx/junit-tests/com/android/dx/util/ByteArrayAnnotatedOutputTest.java
M       dx/src/com/android/dx/dex/file/DexFile.java
M       dx/src/com/android/dx/util/ByteArray.java
M       dx/src/com/android/dx/util/ByteArrayAnnotatedOutput.java

https://android-review.googlesource.com/479697
https://goto.google.com/android-sha1/d67961b03525d8b58cfa55d33c8ca669dc16f563