Algoritmos de política, bancos y uso¶
Esta página describe los algoritmos de la implementación Android en Java, no un diseño idealizado. Presenta límites superiores derivados de topes explícitos y tamaños de entrada, no mediciones de rendimiento de dispositivos. Consulte los conceptos de política, descanso, crédito del banco y funcionamiento sin conexión para conocer las explicaciones dirigidas a usuarios.
Evaluación local de la política¶
El acceso pasa por una serie de condiciones. Este diagrama resume los controladores de política y banco juntos; el evaluador descrito después se encarga de la rama de política y autorizaciones.
flowchart TD
A[Se reevalúa el acceso] --> B{¿Aplicación esencial o sin restricciones?}
B -->|Sí| Y[Permitir según estas reglas]
B -->|No| C{¿Seleccionada por la política actual?}
C -->|No| Y
C -->|Sí| D{¿Horario de descanso?}
D -->|Sí| E{¿Excepción explícita de descanso válida?}
E -->|Sí| Y
E -->|No| N[Mantener bloqueada]
D -->|No| F{¿Autorización aceptada aún vigente?}
F -->|Sí| Y
F -->|No| G{¿Sesión de banco activa con saldo y medición fiable?}
G -->|Sí| Y
G -->|No| NEl vencimiento provoca una reevaluación, no un bloqueo incondicional. Una notificación o un recibo antiguo no permite saltarse estas condiciones. La ausencia de una política verificable no convierte una aplicación antes administrada en una aplicación no seleccionada.
AccessPolicy.evaluate recibe una política ya validada, un nombre de paquete, una hora con zona horaria y el estado de una autorización verificada. Calcula ventanas de descanso para cinco mañanas del calendario local: el día anterior y los tres días siguientes, además de hoy. Revisar la mañana anterior detecta intervalos que cruzan la medianoche; mirar hacia adelante permite determinar el siguiente límite del horario.
Para cada paquete, el evaluador comprueba primero la lista de aplicaciones sin restricciones y después recorre los grupos y sus listas de paquetes. Si un paquete no aparece en la política seleccionada, esta evaluación lo permite. Un paquete seleccionado se bloquea durante el descanso, salvo que una autorización válida incluya explícitamente el alcance de excepción al descanso y la política permita esa excepción. Fuera del descanso, este evaluador requiere una autorización activa; el acceso con banco pertenece a otro controlador y no es un efecto secundario de esa decisión.
El esquema limita los grupos a 32, cada lista de paquetes a 256, el total de paquetes seleccionados y sin restricciones a 256, y tanto las excepciones de fecha como los feriados personalizados a 366. Sean \(U\) las entradas sin restricciones, \(G\) los grupos, \(P\) las entradas de paquetes en los grupos, \(E\) las excepciones de fecha y \(H\) los feriados personalizados. El evaluador recorre una vez las entradas sin restricciones, los grupos y sus paquetes, y las listas de excepciones y feriados para un número fijo de cinco fechas. Por tanto, el trabajo es:
La lista fija de ventanas, el conjunto calculado de feriados colombianos y el estado temporal de pertenencia usan memoria auxiliar acotada. El validador admite las palabras clave usadas por este formato de política; no implementa todo JSON Schema.
Ledger del banco de tiempo¶
TimeBankLedger guarda por banco el saldo, el resto parcial de tiempo elegible y la marca de la última aplicación del mínimo diario. Durante intervalos fuera del descanso protegido, cada banco cuyo grupo siga configurado por la política actual acumula un depósito por cada intervalo elegible configurado, incluso si no hay una sesión de consumo activa. Aquí, «elegible» significa fuera del horario de descanso de la política; no significa que el teléfono esté encendido, desbloqueado o con la pantalla activa. La evidencia de pantalla y actividad limita los débitos por separado. Los depósitos se detienen al alcanzar la capacidad y, al llegar a ella, se borra el resto parcial.
Al salir de un período de descanso, el ledger eleva el saldo al mínimo diario si está por debajo, una vez por cada fecha local posterior. Si el saldo supera ese mínimo, lo conserva. Es un piso, no un reinicio a medianoche: el crédito sin usar no vence cada día. Una actualización de política puede reducir la capacidad configurada; en ese caso, los saldos guardados se limitan al nuevo máximo.
La reconciliación avanza desde el cursor persistido a través de los límites del horario. El bucle está limitado por MAX_BOUNDARIES_PER_ADVANCE (5.000); si no llega a la hora solicitada dentro del límite, lanza un error en lugar de afirmar que completó la reconciliación. nextRefill tiene el mismo límite de transiciones y nextCredit examina como máximo ocho transiciones para hallar el siguiente piso diario útil.
Para el modelo de costo, sean \(K\leq 5000\) los límites procesados, \(B\) los registros de bancos conservados en el estado local, \(G\) los grupos de la política actual y \(A\) el costo de una evaluación de política descrita arriba. El procesamiento de recargas y pisos recorre los registros y comprueba si cada banco sigue configurado, buscando en los grupos actuales. El límite conservador es:
El mapa puede conservar saldos de grupos eliminados de la política; por eso \(B\) también incluye esos registros históricos. Los límites de esquema acotan los grupos y paquetes actuales, pero no hacen que un mapa de bancos históricos creciente tenga tamaño constante. El límite de 5.000 transiciones detiene el cálculo por seguridad; no es una aproximación.
Contabilidad de uso en primer plano¶
ForegroundUsage.read solicita UsageEvents para una ventana de hasta 30 minutos y empieza la consulta hasta 24 horas antes del comienzo solicitado para reconstruir el estado inicial. Recorre en flujo los eventos crudos del sistema, conserva solo los tipos que entiende y falla si la lista de eventos mapeados supera 10.000. Pantalla apagada, pantalla bloqueada, ambigüedad entre paquetes, permiso denegado y fallos de consulta se representan como estados de salud, no como una suposición de uso en primer plano.
UsageEventReducer ordena los eventos mapeados por marca de tiempo y lleva el seguimiento de actividades reanudadas y visibles. Para cada evento recalcula qué paquete es elegible y detecta superposición sostenida. Sean \(R\) los eventos crudos que devuelve la plataforma, \(F\leq 10{,}000\) los eventos mapeados y \(V\) la cantidad máxima de identidades de actividad seguidas simultáneamente. La lectura recorre eventos de plataforma en \(O(R)\); la reducción cuesta \(O(F\log F+F\cdot V)\), porque las comprobaciones de elegibilidad construyen o recorren conjuntos de identidades. En el peor caso \(V\leq F\), así que el tiempo del reductor es \(O(F^2)\); la lista de eventos y su estado usan \(O(F+V)\) de memoria. El código no impone un límite numérico aparte a los eventos crudos \(R\), por lo que la ventana temporal y el límite de 10.000 eventos mapeados no son un límite estricto al recorrido de la plataforma.
Los débitos requieren una muestra nueva y aceptable y solo se aplican a intervalos cuyo paquete pertenezca al grupo del banco activo. Para cada intervalo, el débito queda limitado por la duración medida, el saldo disponible y el tiempo restante de la sesión:
donde \(\Delta t_i\) es el intervalo conocido en primer plano, \(b_i\) el saldo justo antes y \(s_i\) el límite de sesión todavía disponible. El tiempo desconocido no se reemplaza por el tiempo transcurrido del reloj.
En palabras: se descuenta el menor valor entre uso medido, saldo disponible y tiempo restante de la sesión. La regla sigue siendo comprensible aunque el motor de fórmulas no esté disponible.
Ejemplo ilustrativo¶
Considere una política ilustrativa, sin relación con una cuenta o dispositivo. Agrega 5 minutos por cada 60 minutos fuera del horario de descanso protegido, limita el saldo a 90 minutos y define un piso diario de 10 minutos. La recarga se acumula haya o no una sesión de consumo; esos 60 minutos no significan uso con la pantalla activa. Si un banco sin uso tiene 4 minutos al terminar el descanso, el piso lo eleva a 10; si tiene 14, conserva 14. Tras 60 minutos elegibles fuera del descanso, un banco que no esté lleno recibe 5 minutos.
Suponga que una persona inicia explícitamente una sesión con 12 minutos disponibles. Una muestra nueva y no ambigua de Usage Events identifica 7 minutos en una aplicación que pertenece al grupo del banco, y quedan 20 minutos del límite de sesión. La ecuación descuenta 7 minutos y deja 5. Si un reinicio o un historial ambiguo deja incierto el último intervalo, ese tramo queda registrado para recuperación, pero no se cobra. La sesión se cierra hasta que la persona vuelva a iniciarla.
La sesión usa una ventana de acceso renovable de cinco segundos. El monitor solo la renueva tras una consulta de evidencia exitosa y liquida eventos recientes con 1,5 segundos de demora. Si hay un reinicio abrupto, el cálculo de recuperación del ledger limita a 6,5 segundos cualquier tramo guardado pero aún no medido y lo deja sin cobrar; los débitos anteriores conservados permanecen. No es un plazo físico garantizado para suspender la aplicación: Android puede retrasar la entrega de alarmas y prolongar el tiempo real sin suspensión. Consulte las limitaciones para conocer este límite de la plataforma. Un cambio de política termina la sesión activa del banco y exige iniciarla de nuevo con las reglas actualizadas.
Compromisos¶
La contabilidad prefiere un cobro defendible a descontar cada segundo que avanzó el reloj. Puede contar menos tiempo cuando se pierden eventos o se reinicia el teléfono, pero evita consumir crédito con tiempo incierto. Los eventos de uso son evidencia de actividad en primer plano, no una grabación de pantalla ni una prueba de atención. Este mecanismo no mide pestañas individuales ni el contenido dentro de una aplicación.