search

dotnet / android

.NET for Android provides open-source bindings of the Android SDK for use with .NET managed languages such as C#
MIT License
1.94k stars 533 forks source link

VS 16.6.0 Prev 2.0 App crashes while displaying splash screen #4471

Closed gmck closed 4 years ago

gmck commented 4 years ago

My prototype app which was uploaded a couple of days ago crashes at startup. It was cleaned, rebuilt and deployed and immediately just hung on the splash screen. Once the update was installed the only thing I noticed was that the layout screen that was opened when the installation began went through its compiling, rendering stuff and ultimately came up with an error reported previously that all the layouts of this app have displayed. So no difference there with the new Android Designer. I tried to debug but it crashed in the debugger immediately.

The only changes since I uploaded it to @jonathanpeppers and @grendello is that I've been changing the theme to use MaterialComponents.

The following is from the log as best as I could determine where the problem is.

2020-03-27 18:02:22.926 12838-12838/com.glmsoftware.obdnowproto D/Mono: Requesting loading reference 0 (of 2) of Mono.Security.dll 2020-03-27 18:02:22.926 12838-12838/com.glmsoftware.obdnowproto D/Mono: Loading reference 0 of Mono.Security.dll asmctx DEFAULT, looking for mscorlib, Version=2.0.5.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e 2020-03-27 18:02:22.926 12838-12838/com.glmsoftware.obdnowproto D/Mono: Assembly Ref addref Mono.Security[0x7878f94780] -> mscorlib[0x790e4c6c00]: 5 2020-03-27 18:02:22.990 12838-12838/com.glmsoftware.obdnowproto E/mono: Unhandled Exception: System.MissingMethodException: Method not found: void .CreationOptions.set_JniAddNativeMethodRegistrationAttributePresent(bool) at Android.Runtime.AndroidRuntime..ctor (System.IntPtr jnienv, System.IntPtr vm, System.Boolean allocNewObjectSupported, System.IntPtr classLoader, System.IntPtr classLoader_loadClass, System.Boolean jniAddNativeMethodRegistrationAttributePresent) [0x00000] in :0 at Android.Runtime.JNIEnv.Initialize (Android.Runtime.JnienvInitializeArgs args) [0x000ed] in :0 2020-03-27 18:02:22.990 12838-12838/com.glmsoftware.obdnowproto E/mono-rt: [ERROR] FATAL UNHANDLED EXCEPTION: System.MissingMethodException: Method not found: void .CreationOptions.set_JniAddNativeMethodRegistrationAttributePresent(bool) at Android.Runtime.AndroidRuntime..ctor (System.IntPtr jnienv, System.IntPtr vm, System.Boolean allocNewObjectSupported, System.IntPtr classLoader, System.IntPtr classLoader_loadClass, System.Boolean jniAddNativeMethodRegistrationAttributePresent) [0x00000] in :0 at Android.Runtime.JNIEnv.Initialize (Android.Runtime.JnienvInitializeArgs args) [0x000ed] in :0 2020-03-27 18:02:23.037 1429-10735/? I/ActivityManager: Process com.glmsoftware.obdnowproto (pid 12838) has died: fore TOP

grendello commented 4 years ago

@gmck this commit addresses the issue https://github.com/xamarin/xamarin-android/commit/d2e9a3ff3795e20d91e56204c2944fe1b4cf001d

Your app should work fine once you remove bin and obj directories and rebuild from scratch.

gmck commented 4 years ago

@grendello Just tried your suggestion. Exactly the same error again. Any other ideas?

grendello commented 4 years ago

@gmck not really. What you're seeing is a result of mixing two different versions of XA. The property the exception cannot find was added to Xamarin.Android in this commit and your build somehow mixes "the old" with "the new" - thus the suggestion to clear bin and obj. Make absolutely sure your app is rebuilt from scratch - with all the bin and obj directories removed prior to the build.

gmck commented 4 years ago

@grendello I deleted both the bin and the obj directory. Neither existed when I rebuilt. Same error. I repeated it and did it all over again. Same result. Looks like exactly the same as in Issue 4472. You have the project why don't you try? If you need the project updated, then I'll send again. Please don't close the issue until it is resolved.

grendello commented 4 years ago

@gmck I've just ran tests on two different systems (Linux and mac) with apps built from scratch and had no problem with them running on device. My diagnosis still stands - maybe in your case is a cross between the VS Stable and VS Preview installations? @jonathanpeppers might be able to help you more as he works on Windows with VS

gmck commented 4 years ago

@grendello This app has never seen any version of VS stable, its a prototype, only with new stuff. You have the app, please try it. What is the point of asking for reproducible examples if you don't look at them? It was also sent to @jonathanpeppers. Thanks for reopening the issue and the improved subject heading.

grendello commented 4 years ago

@gmck do you have VS Stable and VS Preview installed side-by-side?

jonathanpeppers commented 4 years ago

I tried the app, and both versions of VS worked for me:

> $msbuild = "C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Current\Bin\MSBuild.exe"
> git clean -dxf ; adb uninstall com.glmsoftware.obdnowproto ; $msbuild .\OBDNowProto.csproj /t:Install,_Run /bl /r
> $msbuild = "C:\Program Files (x86)\Microsoft Visual Studio\2019\Preview\MSBuild\Current\Bin\MSBuild.exe"
> git clean -dxf ; adb uninstall com.glmsoftware.obdnowproto ; $msbuild .\OBDNowProto.csproj /t:Install,_Run /bl /r

I deleted the .vs, bin, and obj directories that were in the zip file.

If I get this far, it worked?

image

grendello commented 4 years ago

The problem you're seeing is caused by two different versions of Xamarin.Android ending up in a single .apk - to be exact, Java.Interop.dll in the apk is too old for the Xamarin.Android version. And, indeed, if you look inside your .vs directory, you will find a file named storage.ide which is an sqlite3 database with a cache of locations the solution uses (assemblies among others). And there we can find:

$ sqlite3 storage.ide .dump|grep Java\.Interop
INSERT INTO SolutionData2 VALUES('<SymbolTreeInfo>_Metadata_C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\Common7\IDE\ReferenceAssemblies\Microsoft\Framework\MonoAndroid\v1.0\Java.Interop.dll' [some data cut]
INSERT INTO SolutionData2 VALUES('<SymbolTreeInfo>_SpellChecker_C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\Common7\IDE\ReferenceAssemblies\Microsoft\Framework\MonoAndroid\v1.0\Java.Interop.dll' [some data cut]

Which points to a location of the stable Xamarin.Android installation, not the preview one. If, for some reason, that version of the dll is resolved first and placed in the apk with the preview version of Xamarin.Android you will end up with precisely the error message you're seeing. Please remove .vs, bin and obj again and rebuild - it should work.

gmck commented 4 years ago

Yes, both machines have VS Stable and VS Preview side-by-side. Both machines don't necessarily run the same versions, I'm not that brave. Where are you going with this?

grendello commented 4 years ago

Yes, both machines have VS Stable and VS Preview side-by-side. Both machines don't necessarily run the same versions, I'm not that brave. Where are you going with this?

Please see the comment above yours

jonathanpeppers commented 4 years ago

@gmck if you uninstall the app does that fix anything?

My steps here did that: https://github.com/xamarin/xamarin-android/issues/4471#issuecomment-605005513

gmck commented 4 years ago

@grendello Sorry for the slow reply, but I was sleeping. Deleted the 3 directories built/deployed and exactly the same error.

I've never even considered the .vs folder and have no knowledge of what it is meant to do. I get what you are saying but don't understand how or what made that situation come about. It would be good to know for possible problems in the future. Prior to deleting it, I could see the file storage.ide, but I've no idea of how you are meant to open it.

After rebuilding and deploying there is just a v16 folder under the obdnowproto folder and it contains a .suo file. Now, no storage.ide file. Is that expected?

Prior to doing the upgrade I was working on changing the theme to using MaterialComponents, some problems there and I was working on fixes for each problem as I came across them. I was building/deploying regularly all day with Preview 1 and it was fine. Didn't seem to have the usual problems I've been having re having to clean each time. Got to the end of the day, so I decided to run the upgrade and that was it.

@jonathanpeppers certainly seems to have it running, but not me. I'm not sure how you want me to proceed. I don't think it is possible to go back to Preview 1 - seem to remember Brendan saying that to someone a few days ago.

jonathanpeppers commented 4 years ago

Can you just use 16.5 stable for now?

gmck commented 4 years ago

@grendello @jonathanpeppers. This laptop with the problem project is only 10 days old and I've just upgraded the stable version to 16.5.1. I've just copied the project to another folder and it builds/deploys fine with 16.5.1. The .vs folder is as I described above. I went back to my older laptop and checked the .vs folder of the project there (dated 12/03). It does have Server/sqlite3/ folders and the storage.ide file, so I guess that is where that stuff came from. Can one of you explain or point to documentation re the Sql stuff and the .vs folder, would really like to know now.

When I wake up again I'll uninstall the preview and then reinstall and see if I can copy the project back to the original folder. Sort of points to a stuff up in the installation. Since the older laptop still has Preview 1 I'll also copy to there and see if I can reproduce. Anything else you want me to try?

Thanks for your help

jonathanpeppers commented 4 years ago

When you're "copying", are you bringing the .vs/bin/obj folders along?

I would make sure these are not getting passed/shared between two computers.

brendanzagaeski commented 4 years ago

to be exact, Java.Interop.dll in the apk is too old for the Xamarin.Android version

@grendello, @jonathanpeppers, is Java.Interop.dll part of the shared platform APK when running in fast deployment mode? Given @jonathanpeppers's results with this same error on https://github.com/xamarin/xamarin-android/issues/4415#issuecomment-601707337, it sounded like perhaps the shared platform APK was not being rebuilt and redeployed as expected on the first try after a switching environments from Visual Studio 2019 version 16.6 Preview 1 to Visual Studio 2019 version 16.6 Preview 2.

Is a stale shared platform APK on device a likely culprit?

brendanzagaeski commented 4 years ago

For my question about Java.Interop.dll, when using fast deployment:

Candidate workaround

  1. Ensure the desired target Android device is attached.

  2. Open Tools > Android > Android Adb Command Prompt.

  3. Run:

    adb uninstall Mono.Android.DebugRuntime

  4. Rebuild and redeploy the application.

The theory on the root cause of the problem would be that the Mono Shared Runtime package is not getting updated as expected, as seen before in https://github.com/xamarin/xamarin-android/issues/3784.

brendanzagaeski commented 4 years ago

Cross-references for the Xamarin.Android team:

VS bug #1085494

https://developercommunity.visualstudio.com/content/problem/965021/systemmissingmethodexception-method-not-found-void-2.html

brendanzagaeski commented 4 years ago

The theory on the root cause of the problem would be that the Mono Shared Runtime package is not getting updated as expected, as seen before in #3784.

I have now confirmed this theory. If I manually install the Mono Shared Runtime package from Xamarin.Android 10.2.100.7 to my device and then fast deploy an app using using Visual Studio 2019 version 16.6 Preview 2, I get the exception as mentioned in the issue description:

Unhandled Exception:
System.MissingMethodException: Method not found: void .CreationOptions.set_JniAddNativeMethodRegistrationAttributePresent(bool)

The candidate workaround of manually uninstalling Mono.Android.DebugRuntime successfully resolves the issue.

(Deleting the bin, obj, and .vs directories and manually uninstalling the app APK does not resolve the issue, at least when using this custom technique to reproduce it.)

gmck commented 4 years ago

@grendello, @jonathanpeppers, @brendanzagaeski, I can confirm that manually uninstalling Mono.Android.DebugRuntime, as suggested by Brendan, fixed the original problem of this report for Preview 2. The only thing in the .vs folder now is the .suo file. I'd appreciate your comments about how that folder got the original contents as reported by Marek.

gmck commented 4 years ago

@jonathanpeppers When you're "copying", are you bringing the .vs/bin/obj folders along?

Yes, that is how I've always copied a project from one folder to another. Whenever I zip a project for someone else I always delete the bin/obj folders before zipping, but that was a space-saving consideration. Are you saying the original copying technique is ok between folders on the same computer and that you only need the delete .vs, bin, obj folders when copying to another computer? For instance, the .vs folder would have still have been in that zip file I uploaded for you.

gmck commented 4 years ago

@grendello, @jonathanpeppers, @brendanzagaeski, Further problems with this app. After adding a Fragment class from another app to this project, it was ok to start with, built and deployed ok. Now even with just the smallest of changes, I'm getting the following:

System.NotSupportedException. Can't create an instance of type insert fully qualified fragment class name no java peer type found. This class was added as "add existing item" from a project already on this computer, so nothing to do with copying a project re @jonathanpeppers earlier question.

Clean fixes it, until the next time. I thought I saw the "no java peer type found" in another issue, but now I can't locate it to check.

Do you want this reported as a separate issue?

brendanzagaeski commented 4 years ago

System.NotSupportedException. Can't create an instance of type insert fully qualified fragment class name no java peer type found

Apologies for the slow reply about that symptom. In case any other user finds this issue first when searching for that error message, the item to follow for updates about that error message is https://github.com/xamarin/xamarin-android/issues/4415.

dellis1972 commented 4 years ago

@gmck can I ask what device you are using to test? We have had issues in the past where the broadcast we use to get the Shared runtime versions does not return the expected information.

I will try to dig out the command we send to see if you can invoke it manually on the device so we can see what is being returned.

brendanzagaeski commented 4 years ago

@dellis1972 , for what it's worth, I was able to reproduce with an Android 9.0 (API level 28) Google Pixel 3 device https://github.com/xamarin/xamarin-android/issues/4471#issuecomment-605327168.

dellis1972 commented 4 years ago

@brendanzagaeski do you have the deployment diagnostic log for that? I have tried installing an old Shard Runtime locally, and then run the Install using the latest master and the runtime is upgraded. You should see the following in the log

[BEGIN] Removing old runtimes
[MESSAGE] Removing old runtime: Mono.Android.DebugRuntime [1579216741]..
  Removing old runtime: Mono.Android.DebugRuntime [1579216741].. (TaskId:242)
  DEBUG RunShellCommand 00bc87cc59512a02 pm uninstall "Mono.Android.DebugRuntime" (TaskId:242)
  DEBUG RunShellCommand 00bc87cc59512a02 pm uninstall "Mono.Android.DebugRuntime" (TaskId:242)
  TASK: UninstallPackage 741ms, pm uninstall "Mono.Android.DebugRuntime" completed?: 
  Exception occurred while executing:
  java.lang.IllegalArgumentException: Unknown package: Mono.Andro... (TaskId:242)
[END] 
[BEGIN] Installing shared runtime
[MESSAGE] Target device is arm64-v8a.
[MESSAGE] Installing the Mono shared runtime (debug - 1584714880)...
  TASK: UninstallPackage 1035ms, pm uninstall "Mono.Android.DebugRuntime" completed?: Success
   (TaskId:242)
  Target device is arm64-v8a. (TaskId:242)
  Installing the Mono shared runtime (debug - 1584714880)... (TaskId:242)
  DEBUG RunShellCommand 00bc87cc59512a02 pm install-create -i Mono.Android.DebugRuntime -S 42764799 -d (TaskId:242)
  DEBUG RunShellCommand 00bc87cc59512a02 "pm" "install-commit" "141324576" (TaskId:242)
  TASK: InstallPackageFromStream 8485ms, Mono.Android.DebugRuntime completed?: Success
   (TaskId:242)
[END]

or something similar. The only way I can get the Install target to not replace the runtime is if it doesn't run. i.e It thinks the app is completely up to date and does not run the Install Target.

gmck commented 4 years ago

@dellis1972 Sorry for the slow reply, I missed your question. Usual devices I deploy to are Pixel3a, Samsung S8 (Android 9) and Samsung S20

brendanzagaeski commented 4 years ago

Root cause

The problem is that the Mono Shared Runtime .apk files have the same android:versionCode.

From Xamarin.Android.Sdk-10.2.100.7.vsix:

C:\Temp> & 'C:\Program Files (x86)\Microsoft Visual Studio\2019\Preview\MSBuild\Xamarin\Android\aapt2.exe' dump xmltree --file AndroidManifest.xml '.\$MSBuild\Xamarin\Android\Mono.Android.DebugRuntime-x86_64.apk' | sls android:versionCode

    A: http://schemas.android.com/apk/res/android:versionCode(0x0101021b)=1580759142

From Visual Studio 2019 version 16.6 Preview 2:

C:\> & 'C:\Program Files (x86)\Microsoft Visual Studio\2019\Preview\MSBuild\Xamarin\Android\aapt2.exe' dump xmltree --file AndroidManifest.xml 'C:\Program Files (x86)\Microsoft Visual Studio\2019\Preview\MSBuild\Xamarin\Android\Mono.Android.DebugRuntime-x86_64.apk' | sls android:versionCode

    A: http://schemas.android.com/apk/res/android:versionCode(0x0101021b)=1580759142

If I'm reading the info from monodroid correctly, the reason the numbers are the same is that the versionCode is generated from the monodroid commit history info.

Since there haven't been any monodroid changes between these previews, the number hasn't changed. It looks like the fix might be to update mk/helper.mk so that UPDATE_INT is generated from the xamarin-android commit history instead.

brendanzagaeski commented 4 years ago

Release status update

A new Preview version of Xamarin.Android has now been published that includes a fix for this item, brought in by 2b9a019b91e30c8627080c0fe635ba434cef66b6, that will prevent an outdated Mono Shared Runtime from being left on device between future Xamarin.Android version updates. The fix is not yet included in a Release version. I will update this again when a Release version is available that includes the fix.

Fix included in Xamarin.Android 10.3.99.259.

Fix included on Windows in Visual Studio 2019 version 16.7 Preview 2. To try the Preview version that includes the fix, check for the latest updates in Visual Studio Preview.

Fix included on macOS in Visual Studio 2019 for Mac version 8.7 Preview 2. To try the Preview version that includes the fix, check for the latest updates on the Preview updater channel.

brendanzagaeski commented 4 years ago

Release status update

A new Release version of Xamarin.Android has now been published that includes the fix for this item.

Fix included in Xamarin.Android SDK version 11.0.0.3.

Fix included on Windows in Visual Studio 2019 version 16.7. To get the new version that includes the fix, check for the latest updates or install the most recent release from https://visualstudio.microsoft.com/downloads/.

Fix included on macOS in Visual Studio 2019 for Mac version 8.7. To get the new version that includes the fix, check for the latest updates on the Stable updater channel.