Gestión de energía OEM

Dominando ahorradores de batería agresivos

Incluso si configura todo perfectamente y solicita un servicio de primer plano con POST_NOTIFICATIONS, ciertos fabricantes de Android (OEM) han integrado motores patentados de “ahorro de batería” altamente agresivos en sus bifurcaciones personalizadas de Android (como MIUI, EMUI, ColorOS).

Estos agresivos asesinos de tareas finalizarán su aplicación después de unos minutos de apagado de la pantalla, independientemente de las reglas estándar de la API de Android. La API de estado de configuración de Tracelet proporciona un conjunto completo para detectar estos dispositivos y dirigir automáticamente al usuario al menú de configuración oculta correcto para incluir su aplicación en la lista blanca.

Fabricantes y comportamientos admitidos

Tracelet mantiene un registro interno de más de 100 estructuras de intenciones específicas de OEM. Cuando llamas a Tracelet.showPowerManager(), el motor detecta automáticamente la marca del dispositivo y activa el enlace profundo correcto.

Estos son los principales OEM que admitimos y lo que abre showPowerManager():

📱 Xiaomi / POCO / Redmi (MIUI / HyperOS)

• El problema: MIUI tiene un administrador de “inicio automático” notoriamente estricto y un “ahorro de batería” que finaliza los servicios en segundo plano después de 5 minutos de suspensión.
• Qué se abre Tracelet:

1. El menú oculto Inicio automático (el usuario debe activar la aplicación).
2. El menú específico de Ahorro de batería de la aplicación (el usuario debe seleccionar “Sin restricciones”).

📱Huawei/Honor (EMUI)

• El problema: El administrador de “Inicio de aplicación” de EMUI elimina aplicaciones a menos que estén configuradas explícitamente para administrarse manualmente.
• Qué abre Tracelet: La pantalla de configuración de Inicio de aplicación. El usuario debe desmarcar su aplicación y asegurarse de que “Inicio automático”, “Inicio secundario” y “Ejecutar en segundo plano” estén habilitados.

📱Samsung (OneUI)

• El problema: Samsung agrega agresivamente aplicaciones a su lista de “Aplicaciones para dormir profundamente” si no se han abierto en unos días, cortando permanentemente toda ejecución en segundo plano.
• Qué abre Tracelet: El menú Aplicaciones no monitoreadas/que nunca duermen, que permite al usuario agregar su aplicación a la lista blanca permanente.

📱OnePlus/Oppo (OxygenOS/ColorOS)

• El problema: “Administración de batería de aplicaciones” agresiva que optimiza automáticamente las tareas en segundo plano.
• Qué abre Tracelet: Las pantallas Inicio automático de la aplicación y Optimización de la batería.

📱 Vivo (sistema operativo Funtouch)

• El problema: Impide que las aplicaciones consuman mucha energía en segundo plano.
• Qué abre Tracelet: El menú de lista blanca Alto consumo de energía en segundo plano.

🌐 Otros dispositivos y DontKillMyApp

Para dispositivos no cubiertos explícitamente por el motor de enlace profundo de Tracelet, o si desea comprender las restricciones técnicas exactas impuestas por fabricantes específicos, le recomendamos encarecidamente que consulte DontKillMyApp.com . Es un increíble recurso impulsado por la comunidad que clasifica los teléfonos inteligentes según la agresividad de sus tareas en segundo plano y proporciona pasos de configuración manual para casi todos los dispositivos Android.

Implementación del flujo de mitigación

Debes ejecutar esta verificación durante el flujo de incorporación de tu aplicación o en el panel principal:

import 'package:tracelet/tracelet.dart' as tl;
 
// 1. Check the device health
// Returns a Map<String, dynamic> containing the boolean flags
final health = await tl.Tracelet.getSettingsHealth();
 
// 2. Check if the device is a known aggressive OEM
if (health['isAggressiveOem'] == true) {
  
  // 3. Check if the user has already whitelisted your app
  if (health['isIgnoringBatteryOptimizations'] == false) {
    
    // 4. Show a custom Flutter dialog explaining WHY they need to do this
    showDialog(
      context: context,
      builder: (context) => AlertDialog(
        title: Text("Background Tracking Required"),
        content: Text("To ensure your route is recorded, please select 'No Restrictions' on the next screen."),
        actions: [
          TextButton(
            onPressed: () async {
              Navigator.pop(context);
              // 5. Open the specific manufacturer's hidden power menu
              // Returns true if the intent successfully launched the screen, false otherwise.
              final success = await tl.Tracelet.showPowerManager();
              
              if (!success) {
                // Fallback: Open standard Android battery settings
                await tl.Tracelet.openBatterySettings();
              }
            },
            child: Text("Configure"),
          )
        ]
      )
    );
  }
}

Fiabilidad de seguimiento de flotas/conductores en tiempo real

La pregunta más común de los equipos que crean aplicaciones de taxis, entregas y flotas es: “¿Puede Tracelet seguir el seguimiento todo el día en Xiaomi, Poco, Infinix, Tecno y otros OEM agresivos?” Aquí está la respuesta honesta y práctica.

Qué maneja Tracelet automáticamente

Estas mitigaciones se aplican por usted, no se requiere configuración:

• Servicio en primer plano con FOREGROUND_SERVICE_TYPE_LOCATION: la prioridad en segundo plano más alta que otorga Android.
• START_STICKY: el sistema operativo recrea el servicio después de que desaparece la presión de la memoria.
• Wakelocks seguros para OEM: en Huawei, una etiqueta de wakelock incluida en la lista blanca de PowerGenie para que el proceso no se interrumpa por mantener un wakelock “desconocido”.
• Wakelock del receptor de arranque: un breve wakelock durante BOOT_COMPLETED para que el proceso sobreviva hasta que se establezca el servicio en primer plano después del reinicio.
• Reglas de Consumer ProGuard/R8: evita que las compilaciones de lanzamiento eliminen servicios, receptores y entidades de sala.

El paso manual inevitable

Puerta de inicio del turno de un conductor bajo exención:

final ignoring = await tl.Tracelet.isIgnoringBatteryOptimizations();
final health = await tl.Tracelet.getSettingsHealth();
 
if (health['isAggressiveOem'] == true && !ignoring) {
  // Walk the user through showPowerManager() + battery-optimization exemption
  // BEFORE letting them go "on shift".
}

Detectar cuando el OEM ha acelerado o detenido el seguimiento

• Tracelet.getHealth(): una llamada devuelve el estado de seguimiento, el estado del proveedor, el permiso/autorización, el modo de ahorro de energía, la exención de optimización de la batería y el recuento pendiente no sincronizado, con advertencias detectadas automáticamente. Perfecto para un panel de “Estado del dispositivo”.
• Eventos onProviderChange: se activa cuando cambian los servicios de ubicación/estado del GPS.
• Control de estancamiento del backend: cada corrección tiene una marca de tiempo y persiste, así que compare la última hora de corrección de cada dispositivo con su cadencia esperada en su servidor y marque un dispositivo cuya transmisión se silenció (la firma clásica de una eliminación de OEM) en cuestión de minutos.

Lista de verificación de configuración recomendada para el seguimiento durante todo el día

1. Solicite el permiso Always/ubicación en segundo plano con un flujo justificativo claro.
2. Ejecute un servicio en primer plano con una notificación continua: no negociable para un seguimiento continuo.
3. Configure stopOnTerminate: false y startOnBoot: true para que el seguimiento sobreviva al cierre y reinicio de la aplicación.
4. Durante la incorporación, llame a getSettingsHealth(); si isAggressiveOem es verdadero, guíe al usuario a través de showPowerManager() y la exención de optimización de la batería. Inicio del cambio de puerta en isIgnoringBatteryOptimizations().
5. Utilice HTTP Sync (cargas por lotes) para que las breves brechas en la red nunca pierdan datos.
6. Agregue un controlador de obsolescencia del backend para que las operaciones detecten que un dispositivo se apaga rápidamente.
7. Envíe tracelet_doctor (o getHealth()) en una pantalla de soporte oculta para que los problemas de campo se puedan diagnosticar en dispositivos reales.