reloj quitar premium poner pantalla nombre mensaje inicio como bloqueo bloquear c# ios xamarin.ios crash-reports testflight

c# - premium - quitar el reloj de la pantalla de bloqueo del iphone sin jailbreak



¿Cómo evitar que los reporteros de bloqueo de iOS bloqueen las aplicaciones MonoTouch? (2)

Comenzando con Xamarin.iOS 10.4 ahora hay una forma compatible de hacer esto:

static void EnableCrashReporting () { try { } finally { Mono.Runtime.RemoveSignalHandlers (); try { EnableCrashReportingUnsafe (); } finally { Mono.Runtime.InstallSignalHandlers (); } } } static void EnableCrashReportingUnsafe () { // Run your crash reporting library initialization code here-- // this example uses HockeyApp but it should work well // with TestFlight or other libraries. // Verify in documentation that your library of choice // installs its sigaction hooks before leaving this method. // Have in mind that at this point Mono will not handle // any NullReferenceExceptions, if there are any // NullReferenceExceptions on any thread (not just the current one), // then the app will crash. var manager = BITHockeyManager.SharedHockeyManager; manager.Configure (HockeyAppId, null); manager.StartManager (); }

Hay muchas bibliotecas de informes de fallas de iOS en iOS, incluyendo TestFlight y HockeyApp . Si no desea depender de los servicios, aún puede usar bibliotecas como PLCrashReporter . El enlace de estas bibliotecas es bastante trivial porque su API pública generalmente consiste en un par de clases con varios métodos de inicialización.

Sin embargo, cuando intentamos usar TestFlight y luego HockeyApp en nuestra aplicación, nuestra aplicación comenzó a fallar aleatoriamente. Resulta que este es un problema conocido que se ha reported several times , pero Xamarin no lo advierte, es relativamente oscuro y lo encontramos de la manera más difícil.

Hemos aprendido que todos los reporteros de fallas de iOS evitan que Mono detecte excepciones de referencia nulas:

try { object o = null; o.GetHashCode (); } catch { // Catch block isn''t called with crash reporting enabled. // Instead, the app will crash. }

¿Por qué pasó esto? Citando a Rolf, un desarrollador de Xamarin,

Una excepción de referencia nula es en realidad una señal SIGSEGV al principio. Por lo general, el tiempo de ejecución mono se encarga de esto y lo convierte en una excepción de referencia nula, lo que permite que la ejecución continúe. El problema es que las señales SIGSEGV son algo muy malo en las aplicaciones ObjC (y cuando se produce fuera del código administrado), por lo que cualquier solución de informes de fallas lo reportará como un fallo (y eliminará la aplicación); esto sucede antes de que MonoTouch tenga una oportunidad. para manejar el SIGSEGV, por lo que no hay nada que MonoTouch pueda hacer al respecto.

Estoy seguro de que muchos usan TestFlight en las aplicaciones MonoTouch sin saber que causa bloqueos.
¿No es irónico?

¿Cómo hacer que las bibliotecas de informes de fallos no bloqueen las aplicaciones MonoTouch?


Pon esto en AppDelegate.cs :

[DllImport ("libc")] private static extern int sigaction (Signal sig, IntPtr act, IntPtr oact); enum Signal { SIGBUS = 10, SIGSEGV = 11 } static void EnableCrashReporting () { IntPtr sigbus = Marshal.AllocHGlobal (512); IntPtr sigsegv = Marshal.AllocHGlobal (512); // Store Mono SIGSEGV and SIGBUS handlers sigaction (Signal.SIGBUS, IntPtr.Zero, sigbus); sigaction (Signal.SIGSEGV, IntPtr.Zero, sigsegv); // Enable crash reporting libraries EnableCrashReportingUnsafe (); // Restore Mono SIGSEGV and SIGBUS handlers sigaction (Signal.SIGBUS, sigbus, IntPtr.Zero); sigaction (Signal.SIGSEGV, sigsegv, IntPtr.Zero); Marshal.FreeHGlobal (sigbus); Marshal.FreeHGlobal (sigsegv); } static void EnableCrashReportingUnsafe () { // Run your crash reporting library initialization code here-- // this example uses HockeyApp but it should work well // with TestFlight or other libraries. // Verify in documentation that your library of choice // installs its sigaction hooks before leaving this method. var manager = BITHockeyManager.SharedHockeyManager; manager.Configure (HockeyAppId, null); manager.StartManager (); }

Llame a EnableCrashReporting () al principio del método FinishedLaunching .
Envuelva esta llamada en la directiva #if !DEBUG si lo desea.

¿Como funciona?

Seguí la sugerencia de Rolf:

Una posible solución es permitir que mono maneje todas las señales SIGSEGV (técnicamente hablando, la biblioteca de informes de fallos no debería manejar la señal SIGSEGV o debería encadenarse al manejador de mono y no realizar ningún procesamiento por sí mismo). Si mono determina que la señal SIGSEGV no es del código administrado (es decir, sucedió algo muy malo), generará una señal SIGABORT (que la biblioteca de informes de fallos ya debería manejar y tratar como un fallo). Como puede comprender, esto es algo que debe hacerse en la biblioteca de informes de fallos.

Y la implementación del Objetivo C de Landon Fuller :

#import <signal.h> @implementation AppDelegate - (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions { /* Save Mono''s signal handler actions */ struct sigaction sigbus_action, sigsegv_action; sigaction(SIGBUS, NULL, &sigbus_action); sigaction(SIGSEGV, NULL, &sigsegv_action); // Enable the crash reporter here. Ie, [[PLCrashReporter sharedReporter] enableCrashReporterAndReturnError:], // or whatever is the correct initialization mechanism for the crash reporting service you''re using /* Restore Mono''s signal handlers */ sigaction(SIGBUS, &sigbus_action, NULL); sigaction(SIGSEGV, &sigsegv_action, NULL); return YES; }

sigaction código fuente de Banshee como punto de referencia para sigaction cómo llamar a sigaction desde MonoTouch.

¡Espero eso ayude!