Este artículo cubre el proceso de registro, incluidos los estándares de registro, las pautas de nivel, las clases, los propósitos y las aproximaciones multipila.

Estándares de registro

Iniciar sesión en Android es complejo debido a la combinación de estándares utilizados que se combinan en logcat . Los principales estándares utilizados se detallan a continuación:

Figura 1: Estándares a nivel de registro.

Aunque cada uno de estos estándares tiene una construcción de niveles similar, varían en granularidad. Los equivalentes aproximados entre los estándares son los siguientes:

Figura 2: niveles de registro syslog , Android y Java.

Directrices de nivel de registro

Existen pautas existentes para cada estándar de registro. El nivel de registro elegido sigue el estándar apropiado que se utiliza, como usar el estándar syslog para el desarrollo del kernel.

Los pedidos a nivel de registro, de menor a mayor, se muestran en las tres figuras siguientes:

Figura 3: android.util.Log

Figura 4: java.util.Logging.Level .

Figura 5: RFC 5424 - Sección 6.2.1 .

Registro de aplicaciones

El registro selectivo se realiza con TAG mediante la clase android.util.Log usando Log#isLoggable , como se muestra a continuación:

if (Log.isLoggable("FOO_TAG", Log.VERBOSE)) {
 Log.v("FOO_TAG", "Message for logging.");
}

Los registros se pueden ajustar en tiempo de ejecución para proporcionar un nivel seleccionado de registro como se muestra a continuación:

adb shell setprop log.tag.FOO_TAG VERBOSE

Las propiedades log.tag.* se restablecen al reiniciar. También hay variantes persistentes que permanecen después de los reinicios. Vea abajo:

adb shell setprop persist.log.tag.FOO_TAG VERBOSE

Las comprobaciones Log#isLoggable dejan rastros de registro en el código de la aplicación. Los indicadores booleanos DEBUG omiten los seguimientos de registros mediante optimizaciones del compilador configuradas en false , como se muestra a continuación:

private final static boolean DEBUG = false;


…
If (DEBUG) {
 Log.v("FOO_TAG", "Extra debug logging.");
}

El registro se puede eliminar por APK a través de los conjuntos de reglas de ProGuard de R8 en el momento de la compilación. El siguiente ejemplo elimina todo lo que se encuentra debajo del registro del nivel INFO para android.util.Log :

# This allows proguard to strip isLoggable() blocks containing only <=INFO log
# code from release builds.
-assumenosideeffects class android.util.Log {
  static *** i(...);
  static *** d(...);
  static *** v(...);
  static *** isLoggable(...);
}
-maximumremovedandroidloglevel 4

Esto es útil para manejar múltiples tipos de compilación de aplicaciones (por ejemplo, compilaciones de desarrollo versus compilaciones de lanzamiento) donde se espera que el código subyacente sea el mismo, pero los niveles de registro permitidos son diferentes. Se debe establecer y seguir una política explícita para que las aplicaciones (particularmente las aplicaciones del sistema) decidan cómo los tipos de compilación y las expectativas de lanzamiento impactan la salida del registro.

Registro del sistema en Android Runtime (ART)

Hay varias clases disponibles que están disponibles para aplicaciones y servicios del sistema:

Figura 6: Clases y propósitos de registros del sistema disponibles.

Aunque android.util.Log y android.util.Slog usan los mismos estándares de nivel de registro, Slog es una clase @hide que solo puede utilizar la plataforma. Los niveles EventLog se asignan a las entradas del archivo event.logtags en /system/etc/event-log-tags .

Registro nativo

El inicio de sesión en C/C++ sigue el estándar syslog con syslog (2) correspondiente al syslog del kernel de Linux que controla el búfer printk , y syslog (3) correspondiente al registrador general del sistema. Android utiliza la biblioteca liblog para el registro general del sistema.

liblog proporciona contenedores para los grupos de sublogs usando la siguiente forma de macro:

RLOGD , por ejemplo, corresponde a [Radio log buffer ID] LOG [Debug Level] . Los principales envoltorios liblog son los siguientes:

Figura 7: envoltorios liblog .

Android tiene interfaces de nivel superior para el registro que se prefieren al uso directo liblog , como se ve a continuación:

Figura 8: Bibliotecas de registros de nivel superior.

Aproximaciones multipila

Debido a las diferencias en la granularidad y la intención del nivel, no existen coincidencias claras o exactas de los diferentes estándares de registro. Por ejemplo, los niveles java.util.logging.Level y android.util.Log para los registros de errores no coinciden 1:1:

Figura 9: Nivel de error en el registro estándar de Java frente al registro de Android.

En casos como este, utilice el estándar individual para determinar qué nivel aplicar.

Durante el desarrollo del sistema con múltiples componentes a nivel de pila, siga la Figura 1 para determinar qué estándar usar por componente. Para obtener una guía aproximada de la mensajería por niveles, siga la Figura 2.

Seguridad y privacidad

No registre información de identificación personal (PII). Esto incluye detalles como:

• Correos electrónicos
• Números telefónicos
• Nombres

De manera similar, ciertos detalles se consideran confidenciales incluso si no son explícitamente identificables personalmente.

Por ejemplo, aunque la información de zona horaria no se considera de identificación personal, sí proporciona una indicación de la ubicación aproximada de un usuario.

La política de registro y los detalles aceptables deben manejarse como parte de la revisión de seguridad y privacidad antes del lanzamiento.

Registros de dispositivos

El acceso a todos los registros del dispositivo, incluido el uso de android.permission.READ_LOGS , está restringido:

• Si una aplicación en segundo plano solicita acceso a todos los registros del dispositivo, la solicitud se deniega automáticamente a menos que la aplicación:
• comparte el UID del sistema.
• utiliza un proceso del sistema nativo ( UID < APP_UID ).
• utiliza DropBoxManager .
• accede sólo al búfer de registro de eventos.
• utiliza la API EventLog .
• Utiliza pruebas instrumentadas.
• Si una aplicación en primer plano con READ_LOGS solicita acceso a los registros del dispositivo, el sistema solicita al usuario que apruebe o rechace la solicitud de acceso.