This is Xamarin's bug tracking system. For product support, please use the support links listed in your Xamarin Account.
Bug 44633 - Enabling <AndroidUseSharedRuntime> in some projects causes `classes.dex` to not deploy to device.
Summary: Enabling <AndroidUseSharedRuntime> in some projects causes `classes.dex` to n...
Status: VERIFIED FIXED
Alias: None
Product: Android
Classification: Xamarin
Component: MSBuild (show other bugs)
Version: 7.0 (C8)
Hardware: Macintosh Mac OS
: High critical
Target Milestone: 7.0.1 (C8SR1)
Assignee: dean.ellis
URL:
: 43241 44439 44480 44485 44681 44704 (view as bug list)
Depends on:
Blocks:
 
Reported: 2016-09-22 17:26 UTC by Jon Douglas [MSFT]
Modified: 2016-11-11 16:38 UTC (History)
30 users (show)

See Also:
Tags:
Is this bug a regression?: ---
Last known good build:


Attachments

Description Jon Douglas [MSFT] 2016-09-22 17:26:49 UTC
*Description:

Having the MSBuild property <AndroidUseSharedRuntime>true</AndroidUseSharedRuntime> or option set to "True" in the Android Build options is throwing a ClassNotFoundException in certain projects on Xamarin Studio. It is complaining about certain classes not being found in the 'classes.dex' file (Also known as the main dex list). In the stack trace below, it is trying to find a custom application class which is the entry point to the application:

https://gist.github.com/JonDouglas/9195de21cb1558af01e798ceb56f2dd2

However after directly investigating the `classes.dex` file in the `obj/Debug/android/bin` folder, the class is indeed in the dex list and thus this is a potential red herring to the actual issue at hand.

I then decided to check the actual .apk that is being added to the device. To do so I used the following:

1) `adb backup -apk com.companyname.applicationname'

2) Skip Encryption by not setting a password

3) `dd if=backup.ab bs=24 skip=1 | openssl zlib -d > backup.tar`

4) Extract the .tar

5) Navigate to the `a` folder and find the `base.apk` file

6) `unzip base.apk`

This now shows us the original `classes.dex` list in the project. However when the Shared Runtime is enabled in some projects, there is no such file and thus it makes sense why the exception above is being thrown. In other apps that have the Shared Runtime enabled and do work, you can find the `classes.dex` list.

*Current Behavior:

`classes.dex` is not being deployed with the `base.apk` in some circumstances when the Shared Runtime is enabled

*Expected Behavior:

`classes.dex` should be deployed with the `base.apk` when the Shared Runtime is enabled

*Platforms Affected:

Xamarin Studio (Known)

*Reproduction:

Reproduction will be attached separately as a private comment with reproduction steps.

*Related Issues:

https://bugzilla.xamarin.com/show_bug.cgi?id=43241

https://forums.xamarin.com/discussion/77142/help-with-new-deployment-issue-for-my-forms-app-install-failed-dexopt-from-xamarin-studio

https://forums.xamarin.com/discussion/77722/crashes-on-application-start-after-the-latest-update-xs-6-1-xamarin-android-7

*Version Information

Xamarin Studio - 6.1 (build 5441)

Mono - 4.6.0 (mono-4.6.0-branch/746756c)

Xamarin.Android - 7.0.0.18

JDK - 1.8.0_102 64-bit
Comment 2 Jon Douglas [MSFT] 2016-09-22 17:56:49 UTC
As a secondary note. I added https://bugzilla.xamarin.com/show_bug.cgi?id=43241 as a related bug/duplicate as this is the behavior on any device <= API 19. On Devices >= API 21, it will throw a ClassNotFoundException.
Comment 3 Jimmy [MSFT] 2016-09-22 18:26:11 UTC
Marking as CONFIRMED as I am able to reproduce this issue with the repo project in comment 1 on a API 23 device.
Comment 4 Kent Green [MSFT] 2016-09-22 20:18:39 UTC
I was able to confirm this symptom for my LG Volt API 19 device:
> Deployment failed because of an internal error: Failure [INSTALL_FAILED_DEXOPT]

=== Xamarin Studio Enterprise ===
Version 6.1 (build 5441)
Installation UUID: 8ef63a7c-1b18-40de-a334-7f78777fcb55
Runtime:
	Mono 4.6.0 (mono-4.6.0-branch/746756c) (64-bit)
	GTK+ 2.24.23 (Raleigh theme)

	Package version: 406000245

=== NuGet ===
Version: 3.4.3.0

=== Xamarin.Profiler ===
Not Installed

=== Apple Developer Tools ===
Xcode 8.0 (11246)
Build 8A218a

=== Xamarin.iOS ===
Version: 10.0.0.6 (Visual Studio Enterprise)
Hash: 6c3fee4
Branch: xcode8
Build date: 2016-09-09 13:01:32-0400

=== Xamarin.Android ===
Version: 7.0.0.18 (Visual Studio Enterprise)
Android SDK: /Users/kentgreen/Library/Developer/Xamarin/android-sdk-macosx
	Supported Android versions:
		4.0.3  (API level 15)
		4.1    (API level 16)
		4.2    (API level 17)
		4.3    (API level 18)
		4.4    (API level 19)
		4.4.87 (API level 20)
		5.0    (API level 21)
		5.1    (API level 22)
		6.0    (API level 23)
		7.0    (API level 24)

SDK Tools Version: 25.2.2
SDK Platform Tools Version: 24.0.3
SDK Build Tools Version: 24.0.2

Java SDK: /usr
java version "1.8.0_65"
Java(TM) SE Runtime Environment (build 1.8.0_65-b17)
Java HotSpot(TM) 64-Bit Server VM (build 25.65-b01, mixed mode)

Android Designer EPL code available here:
https://github.com/xamarin/AndroidDesigner.EPL

=== Xamarin Android Player ===
Not Installed

=== Xamarin.Mac ===
Version: 2.10.0.99 (Visual Studio Enterprise)

=== Xamarin Inspector ===
Version: 0.7.1.0
Hash: 545e74c
Branch: master
Build date: Fri Apr  8 17:34:53 UTC 2016

=== Build Information ===
Release ID: 601005441
Git revision: 68292d1ab289911c815ddc715dd7cc29a9752f9f
Build date: 2016-09-09 04:43:23-04
Xamarin addins: ed25d008672663eeb9db55f1ccecb3c24d2fd3b2
Build lane: monodevelop-lion-cycle8

=== Operating System ===
Mac OS X 10.11.6
Darwin Kents-MBP 15.6.0 Darwin Kernel Version 15.6.0
    Mon Aug 29 20:21:34 PDT 2016
    root:xnu-3248.60.11~1/RELEASE_X86_64 x86_64

=== Enabled user installed addins ===
Xamarin Inspector 0.7.1.0
Comment 5 dean.ellis 2016-09-22 22:49:28 UTC
Can someone who has replicated this provide a full diagnostic output of the msbuild /t:Install target. 

1. Clean the project (i.e no bin/obj)
2. run 'xbuild <project.csproj> /t:Install /v:d > build.log 2>&1'

this will do a complete build and install. 
Confirm that the problem still happens by running up the app. 

Hopefully the diagnostic output should let us see what is going on with the classes.dex file.
Comment 6 dean.ellis 2016-09-23 11:16:04 UTC
Does this only happen on devices? I am running all the latest stable versions and the app deploys fine to the XAP emulator.
Comment 7 Ione Souza Junior 2016-09-23 11:23:43 UTC
This is weird. In my case, an app that I am already developing more than a year happens this problem, but in a new app that I just create everything works perfectly.
I trying found any differences between projects to try solve this.
Comment 9 Jonathan Pryor 2016-09-23 19:58:51 UTC
We think we know the problem, or at least the direction of the problem.

The problem is when Xamarin Studio runs the BuildApk-related targets, the MSBuild AfterTargets properties are apparently ignored.

Consider:

1. Command-line build:
https://gist.githubusercontent.com/pjcollins/9b71054d79e33f644f82a9ec4b1d6c6c/raw/820c9c95f1ee1c0bf3c50c48dfaff2c5da09ef7a/gistfile1.txt

2. XS build:
https://gist.githubusercontent.com/pjcollins/62e90ae4e3736594eca12693378a9fce/raw/b89059d12208dfcf0e8af33d219681be9fc0cf59/gistfile1.txt
https://gist.github.com/pjcollins/aad8baba302409f9a628654baa99f8c4#file-gistfile1-txt-L5112

(The second XS gist is the packaging output.)

There's a notable difference in the BuildApk task output:

Command-line:

> 		  DalvikClasses:
> 		    obj/Debug/android/bin/classes.dex

XS:

> 		  DalvikClasses:
# no output

If we look at `/Library/Frameworks/Xamarin.Android.framework/Libraries/xbuild/Xamarin/Android/Xamarin.Android.Common.Debugging.targets`, we see:

    <Target Name="_BuildApkFastDev"
        DependsOnTargets="_PrepareBuildApk"

The `<BuildApk/>` task in the `_BuildApkFastDev` target uses the `@(_DexFileForFastDev)` item group; this item group is *empty* in XS.

`@(_DexFileForFastDev)`, in turn, is filled by the `_CompileFastDevDex` target:

    <Target Name="_CompileFastDevDex" AfterTargets="_CompileDex">

Note that the `_CompileFastDevDex` target is NOT executed in the XS packaging output, and the only thing that would trigger it to run is the //Target/@AfterTargets attribute.

We can thus theorize that, perhaps, //Target/@AfterTargets should be AVOIDED by anything that is executed within Xamarin Studio.

If we fix `Xamarin.Android.Common.Debugging.targets` so that the `_BuildApkFastDev` target has additional dependencies:

    DependsOnTargets="_CompileFastDevDex;_PrepareBuildApk"

classes.dex *is* present in the BuildApk task output, and it is present in the generated .apk.

(Yay.)

Alas, the app still fails to launch. Investigation is ongoing.
Comment 10 dean.ellis 2016-09-29 10:12:13 UTC
PR is up https://github.com/xamarin/monodroid/pull/510 and ready to merge
Comment 11 alex 2016-09-29 21:16:04 UTC
Any workaround meanwhile? To have fast compilation and working app?
Comment 12 dean.ellis 2016-09-30 10:37:11 UTC
Fixed in monodroid/master/a07a63ab
Comment 13 dean.ellis 2016-09-30 10:38:20 UTC
@alex the only work around would be to hack the 

Xamarin.Android.Common.targets

as mentioned in comment 9. 

But you still might hit the other error it mentions.
Comment 14 Peter Collins 2016-10-05 17:24:35 UTC
*** Bug 44480 has been marked as a duplicate of this bug. ***
Comment 15 Peter Collins 2016-10-05 17:25:01 UTC
*** Bug 44485 has been marked as a duplicate of this bug. ***
Comment 16 Brendan Zagaeski (Xamarin Support) 2016-10-05 19:57:38 UTC
*** Bug 43241 has been marked as a duplicate of this bug. ***
Comment 17 Mohit Kheterpal 2016-10-07 17:31:47 UTC
I am able to reproduce this issue with the sample project in comment 1 and I also observed that this issue is fixed is build xamarin.android-7.0.99-120_d46688705d068fc89e1e315fa7bb932cfb70ea3c


Device Logs : https://gist.github.com/Mohit-Kheterpal/d14d8218cb4c52bbc97dc3cadf42fada

Hence closing this issue by marking it as Verified.

thanks
Comment 18 Jonathan Pryor 2016-10-11 16:03:55 UTC
*** Bug 44704 has been marked as a duplicate of this bug. ***
Comment 19 Jonathan Pryor 2016-10-17 16:35:29 UTC
*** Bug 44681 has been marked as a duplicate of this bug. ***
Comment 20 Jonathan Pryor 2016-11-04 18:47:25 UTC
*** Bug 44439 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.