android - firebase crash reporting to crashlytics

Crashlytics de Android: restringe el acceso a la red (6)

He estado trabajando por un tiempo en torno a la falta de capacidad para restringir el uso de la red de Crashlytics bajo ciertas condiciones. Por ejemplo, en roaming, en redes medidas, etc.

De acuerdo con la documentación del SDK, solo dos opciones encontré tratando de alguna manera esto:

"Opt Out" en el tiempo de ejecución simplemente no inicializa Crashlytics
diálogo de consentimiento del usuario incorporado antes de enviar un informe de bloqueo

Estas API son muy limitadas, porque:

No inicializar Crashlytics no solo impide el acceso a la red, sino que también evita cualquier posibilidad de que Crashlytics guarde localmente el informe del fallo para que finalmente se envíe el evento. Por no mencionar que no hay una buena manera de optar por no participar en el tiempo de ejecución, además de anular brutalmente Thread.setUncaughtExceptionHandler
El diálogo de consentimiento no tiene ningún sentido para el usuario si se produce un bloqueo en segundo plano.

Mi pregunta básicamente: ¿Me estoy perdiendo algo? ¿Hay alguna forma de restringir el acceso a la red de Crashlytics?

Mi motivación proviene de la necesidad de evitar una situación en la que mi aplicación utiliza el ancho de banda de la red, lo que puede costarle dinero al usuario en determinadas condiciones, aunque la configuración del dispositivo de "red celular" o "usar datos en itinerancia" está habilitada.

Estaba leyendo los documentos en la tela y acabo de encontrar algo interesante

Crashlytics procesa excepciones en un hilo de fondo dedicado, por lo que el impacto en el rendimiento de su aplicación es mínimo. Para reducir el tráfico de red de sus usuarios, Crashlytics agrupa las excepciones y las envía la próxima vez que se inicie la aplicación.

Así que estaba pensando en una solución ya que los bloqueos sin red se están enviando cuando se inicializa la aplicación, usted podría enviar un cuadro de diálogo al usuario en el inicio indicando si desean conectarse a Internet para enviar informes de fallos para resolver problemas actuales en el la aplicación (por lo que está utilizando sus datos de red con el consentimiento del usuario)

Lo que ocurre aquí es que no sabemos cómo detener el bloqueo de envío de estos informes, lo almacenarán en el dispositivo si el dispositivo está fuera de línea y lo enviarán después de que el dispositivo se conecte nuevamente, como se indica here

Otra salida podría ser simplemente registrar problemas fatales importantes con el inicio de sesión personalizado que ofrecen y simplemente enviarlos, puede encontrar más información here

Para asegurarse de que el envío de informes de errores tenga el menor impacto en los dispositivos de sus usuarios, los registros de Crashlytics tienen un tamaño máximo de 64 KB. Cuando un registro supera los 64 KB, los primeros valores registrados se eliminarán para mantener este umbral.

En conclusión, después de leer los documentos, no hay forma de deshabilitar los métodos de bloqueo para enviar informes constantemente, solo puede administrar la conexión de red del usuario cuando desea enviar o no informes. Su conectividad similar es el encendido y apagado de crashlytics en este momento.

solo habla de "Reducir el tráfico de red", pero no de deshabilitar la red de crashlytics.

Otra forma que me viene a la cabeza es hacer una bandera para iniciar crashlytics y luego usarla dentro de una condición Crashlytics.start()

Cuando quieras deshabilitarlo solo haz lo siguiente

CrashlyticsCore core = new CrashlyticsCore.Builder().disabled(BuildConfig.DEBUG).build(); Fabric.with(this, new Crashlytics.Builder().core(core).build());

Jugar con estas dos cosas es la única manera en la que creo que es posible reducir el uso de la red de crashlytics en este momento

Hay un proceso de dos pasos que estamos usando en nuestra aplicación, esto no está usando Mobile Network y tampoco not related to roaming .

Guardar registros de bloqueo para archivar en la partición de datos de la aplicación, es decir, en el dispositivo :
Consulte este link
Cargue los datos de bloqueo al servidor cuando la red WiFi está conectada :
public class ConnectivityStatusReceiver extends BroadcastReceiver { @Override public void onReceive(Context context, Intent intent) { final ConnectivityManager connMgr = (ConnectivityManager) context.getSystemService(Context.CONNECTIVITY_SERVICE); NetworkInfo activeNetworkInfo = connMgr.getActiveNetworkInfo(); if (activeNetworkInfo != null && activeNetworkInfo.getTypeName() == "WIFI") { // post your crash logs to server } } }

No hay una manera de restringir el uso de Internet para Crashlytics en una aplicación. Pero la forma en que lo solucionaría es proporcionarle al usuario información de que Crashlytics está usando roaming o simplemente guardar el informe de fallos localmente y enviarlos una vez que el usuario esté conectado a una red wifi. También puede dar al usuario la opción si prefiere guardar los informes de fallos localmente o enviarlos inmediatamente a través del roaming.

Guarde el ErrorLog localmente en el dispositivo
Cargue el ErrorLog una vez que se establezca una conexión con un wifi

Debería poder usar el Administrador de conectividad para obtener el estado del adaptador de Wi-Fi. Desde allí puede comprobar si está conectado o incluso disponible .

ConnectivityManager connManager = (ConnectivityManager) getSystemService(Context.CONNECTIVITY_SERVICE); NetworkInfo mWifi = connManager.getNetworkInfo(ConnectivityManager.TYPE_WIFI); if (mWifi.isConnected()) { // post error logs }

No hay una manera de restringir el uso de Internet para Crashlytics en una aplicación. Puede elegir al usuario si prefiere guardar los informes de fallos localmente o enviarlos de inmediato a través del roaming.

Guarde el ErrorLog localmente en el dispositivo

Cargue el ErrorLog una vez que se establezca una conexión con un wifi.

Puede usar ConnectivityManager para obtener el estado de la red. Puede comprobar si está conectado o incluso disponible.

El código anterior se puede agregar en broadcastreceiver que notificará la conexión

Ejemplo:

public class ConnectivityStatusReceiver extends BroadcastReceiver { @Override public void onReceive(Context context, Intent intent) { ConnectivityManager connManager = (ConnectivityManager) getSystemService(Context.CONNECTIVITY_SERVICE); NetworkInfo mWifi = connManager.getNetworkInfo(ConnectivityManager.TYPE_WIFI); if (mWifi.isConnected()) { // send error logs } } }

Puede restringir el uso de la red Crashlytics por un campo estático.

Defina una variable global estática, de acuerdo con su lógica de escritura de valor para sus Crashlytics.

private static boolean INROAMING = false;

Ahora puedes usar la lógica inferior para tu propósito. Como no proporcionar co

if(isInternetIsConnected(this).equals("MOBILE")){ if(INROAMING){ //write your logic for context here, when phone is in roaming //restrict logic for crashlytics }else{ //write your logic for context herem, when phone is not in roaming //un-restrict logic for crashlytics } } public boolean checkForRoaming() { final TelephonyManager telephonyManager = (TelephonyManager) getSystemService(Context.TELEPHONY_SERVICE); PhoneStateListener phoneStateListener = new PhoneStateListener() { @Override public void onServiceStateChanged(ServiceState serviceState) { super.onServiceStateChanged(serviceState); if (telephonyManager.isNetworkRoaming()) { // In Roaming INROAMING = true; } else { // Not in Roaming INROAMING = false; } // You can also check roaming state using this if (serviceState.getRoaming()) { // In Roaming INROAMING = true; } else { // Not in Roaming INROAMING = false; } } }; } public String isInternetIsConnected(Context context) { try { ConnectivityManager cm = (ConnectivityManager) context.getSystemService(Context.CONNECTIVITY_SERVICE); assert cm != null; @SuppressLint("MissingPermission") NetworkInfo activeNetwork = cm.getActiveNetworkInfo(); if (activeNetwork != null) { // connected to the internet if (activeNetwork.getType() == ConnectivityManager.TYPE_WIFI) { // connected to wifi return "WIFI"; } else if (activeNetwork.getType() == ConnectivityManager.TYPE_MOBILE) { // connected to the mobile provider''s data plan checkForRoaming(); return "MOBILE"; } } else { // not connected to the internet return "NO CONNECTION"; } } catch (Exception e) { e.printStackTrace(); } return "NO CONNECTION"; } }

Soy el antiguo mantenedor del SDK de Crashlytics para iOS / macOS. No estoy familiarizado con la versión de Android del SDK, y definitivamente no estoy familiarizado con Android en general. Pero, voy a darle una oportunidad a esto.

Lo que quieres hacer es algo que se ha solicitado en el lado de iOS varias veces. Me hubiera encantado hacerlo en realidad, porque parece bastante terrible obligar a los usuarios finales a incurrir en estos costos. Sin embargo, la red y la rutina de inicio del SDK de iOS son muy complejas y muy delicadas. Es un gran desafío garantizar que se produzcan choques y que haya cero posibilidades para estados inconsistentes. Creo que Android es más simple aquí, pero no puedo decir esto con autoridad.

El SDK de iOS, sin embargo, tiene algunos enlaces para una funcionalidad adicional de nivel de cliente. Echa un vistazo a la advertencia en torno a una de esas API:

* @warning Just implementing this delegate method will disable all forms of synchronous report submission. This can * impact the reliability of reporting crashes very early in application launch.

Básicamente, para satisfacer el contrato de esta API en particular, algunas técnicas para mejorar la confiabilidad de los informes tienen que ser deshabilitadas. La cosa es que a veces vale la pena. Muchas aplicaciones deciden hacer esta compensación. Muchas aplicaciones también demoran la inicialización de Crashlytics para obtener un rendimiento adicional. Esto tiene un gran impacto en la confiabilidad de los informes, pero eso es otro compromiso que los desarrolladores de aplicaciones deben hacer.

Creo que deberías considerar seriamente no habilitar a Crashlytics en estas situaciones, si puedes detectarlos fácilmente. ¿Tal vez Android incluso permita a los usuarios finales hacer esto por aplicación? En ese caso, nunca obtendrías ningún informe de todos modos. Me imagino que su base de usuarios es lo suficientemente diversa para que faltar algunos informes en estas situaciones no sería tan terrible. O tal vez le gustaría mostrarlo como una opción orientada al usuario.

Incluso podrías hacer algo totalmente loco, como anular Thread.setUncaughtExceptionHandler , y almacenar las excepciones durante esta situación en el disco. Y luego, reprodúzcalos en Crashlytics cuando las cosas estén mejor. Conviértelo en una biblioteca de código abierto. ¡Apuesto a que a la gente le encantará! Posiblemente no sea el equipo de Android de Crashlytics;) (¡Hola!)

Esta es también básicamente la misma recomendación que Gastón ofreció anteriormente, con un poco de contexto adicional sobre lo que he visto en el lado de iOS. También dispárale un correo electrónico a la gente de Crashlytics pidiendo esto. Pienso que es una idea genial.