Android System WebView bloquea las aplicaciones de Android! "Las piedras sepulcrales están deshabilitadas en las compilaciones de usuarios de JB MR2 +"

EDIT : Resulta que no era Chrome, pero Android System WebView . Varios usuarios de Google Play Store han dejado respuestas como las aplicaciones de Crashes sin ningún error .

Poste original:

Esta noche mi ~~aplicación de Chrome se~~ actualizó (Android 5.0.2) y cuando intento crear mi aplicación de Android de Xamarin en el modo de DEBUGO, obtengo el error:

[Google-breakpad] ### ### ### ### ### ### ### ### ### ###

[Google-breakpad] Huella digital de construcción de cromo:

[Google-breakpad] 1.0

[Google-breakpad] 1

[Google-breakpad] 5c230f07-455f-4c1f-91eb-9c44019cd813

[Google-breakpad] ### ### ### ### ### ### ### ### ### ###

[Google-breakpad] Las piedras sepulcrales están deshabilitadas en las compilaciones de usuarios de JB MR2 +.

[Google-breakpad] ### ### ### ### ### ### ### ### ### ###

En la consola puedo encontrar el mensaje de error:

E / SysUtils: ApplicationContext es null en ApplicationStatus

Lo que parece ser parte del cromo.

El error aparece en la consola y la aplicación vuelve a la parte de atrás (pero no se destruye) cuando aparece la vista web. La vista web se publica en otro marco.

No he hecho cambios desde ayer, cuando todo funcionó.

Después de crear (y fallar) ejecutar la aplicación desde las funciones del dispositivo como exceptuado.

Mi versión de compilación de destino es API 21 y mínimo de API es 14 (pero también falla en 19).

Presenté un fallo de cromo por lo que parece ser la causa subyacente. http://code.google.com/p/chromium/issues/detail?id=481420

Resulta que no era Chrome, sino Android System WebView que causó la caída de la aplicación. Varios usuarios de Google Play Store han dejado respuestas como las aplicaciones de Crashes sin ningún error .

EDITAR:

Jonathan Pryor en Xamarin Bugzilla ha publicado este comentario :

Como se mencionó en el Comentario # 2 y en el Comentario # 3, el problema es que el WebView de Google Play Service y los tipos relacionados está bloqueando los manejadores SIGSEGV existentes, que anulan todo el código nativo que se basa en manejadores de señales (por ejemplo, Houdini).

Como solución, es posible eliminar la necesidad de un controlador SIGSEGV para la elevación NullReferenceException, estableciendo la variable MONO_DEBUG para que contenga el valor "explicit-null-checks":

http://docs.go-mono.com/?link=man%3amono(1)

Esto se puede hacer agregando un archivo a su proyecto de aplicación con una acción de Build de AndroidEnvironment:

http://developer.xamarin.com/guides/android/advanced_topics/environment/

A continuación, agregar la siguiente línea al archivo:

 MONO_DEBUG=explicit-null-checks

Puede desinstalar las actualizaciones de WebView, para que pueda trabajar en su proyecto mientras esto esté arreglado.

Descubrimos que en nuestro caso se estrelló cuando se lanzó una excepción. Si utilizamos Java.Lang.Exception en lugar de las excepciones de C #, dejó de funcionar.

Encontré una solución para Unity. Ha sido verificado y probado.

1) Instale este script bajo Under YOUR_UNITY_PROJECT / Assets / Editor (Créditos a Prime31 para este guión impresionante):

https://github.com/prime31/P31UnityAddOns/blob/master/Editor/GlobalDefinesWizard.cs

2) Como se ha mencionado en @fhl, debe agregar MONO_DEBUG = explicit-null-checks a las definiciones globales, puede hacerlo haciendo clic en su etiqueta global definida recientemente y asegúrese de que se vea así: Introduzca aquí la descripción de la imagen