broadcast receiver android oreo example
Android O: límite de transmisión PHONE_STATE (6)
Como no hay una solución adecuada para leer PHONE_STATE desde Android O. La mejor alternativa que podemos elegir es activar un trabajo en una nueva entrada de registro de llamadas del proveedor de contenido . Con esto, se mantiene el comportamiento de mostrar una pantalla (con unos segundos de retraso) después de que finaliza la llamada.
NOTA: La desventaja es que no podemos obtener el estado de la llamada (timbre o off_the_hook, etc.). La devolución de llamada solo se recibirá después de que se haya agregado el nuevo registro de llamadas al DB del sistema.
He estado tratando de hacer algo similar a la aplicación truecaller, donde se supone que mi aplicación debe mostrar una pantalla después de que una llamada se cuelga. Estaba logrando esto al registrar la transmisión implícita de android.intent.action.PHONE_STATE en el archivo de manifest .
Pero no funciona si cambio la aplicación para apuntar a Android O, debido a la limitación de la transmisión de Android O , y estoy tratando de encontrar una solución alternativa a este caso de uso.
Soluciones alternativas sugeridas en los documentos de Android: Job scheduler o registro de un service con context .
Programador de trabajos: Debido a las optimizaciones del Job scheduler habrá un poco de retraso para recibir la devolución de llamada. Por lo tanto, afectará la experiencia del usuario si la pantalla de la aplicación se muestra unos minutos después de que la llamada telefónica y el sondeo para verificar si hay nuevos registros de llamadas cada pocos segundos ocasionan problemas de pérdida de batería.
Servicio de registro con contexto en Java : quiero que el comportamiento funcione incluso si la aplicación no está activa o activa. Esto no funcionará si el sistema mata el Service .
Registre un Servicio de primer plano : Esto requiere que se muestre una notificación al usuario todo el tiempo, lo que sería spam para el usuario, y la ejecución de un servicio 24/7 consume muchos recursos que anulan el propósito de la limitación de difusión.
Sugiera una solución alternativa para que la experiencia del usuario siga siendo la misma.
Gracias por adelantado
Como se menciona aquí: https://issuetracker.google.com/37273064#comment4 , ACTION_PHONE_STATE_CHANGED (android.intent.action.PHONE_STATE) se incluirán en la lista blanca para el lanzamiento de Android O. Aunque pueden ser reemplazados con un mecanismo diferente en una versión futura.
Eventualmente, la acción se agregó a la lista "Excepciones implícitas de transmisión" para que pueda agregar ACTION_PHONE_STATE_CHANGED a su manifiesto y funcionará:
https://developer.android.com/guide/components/broadcast-exceptions
ACTION_CARRIER_CONFIG_CHANGED, TelephonyIntents.ACTION _ * _ SUBSCRIPTION_CHANGED, "TelephonyIntents.SECRET_CODE_ACTION", ACTION_PHONE_STATE_CHANGED, ACTION_PHONE_ACCOUNT_REGISTERED, ACTION_PHONE_ACCOUNT_UNREGISTERED
Las aplicaciones de telefonía OEM pueden necesitar recibir estas transmisiones.
Para mí, y mi aplicación de producción, la solución sería evitar apuntar a API 25 y superior , hasta que aparezca una mejor solución / api.
Si su aplicación está orientada al nivel 24 o inferior, no se verá afectado por las nuevas limitaciones implícitas de transmisión y su aplicación aún podrá escuchar transmisiones PHONE_STATE incluso cuando su aplicación no se esté ejecutando.
Una aplicación que apunte a API más bajas todavía puede descargarse e instalarse normalmente en las nuevas versiones de Android, la única razón para actualizar su valor de sdkTarget es si su aplicación requiere el uso de nuevas API.
Parece haber una excepción de transmisión para ACTION_NEW_OUTGOING_CALL pero no para una llamada entrante (o cuando finaliza la llamada). Parece un error tener uno para los salientes pero no uno para los entrantes. Se ha presentado un informe de error en el rastreador de problemas de Google. Esperemos que su respuesta aclare lo que deberíamos estar haciendo.
Actualizaré esta respuesta si / cuando el rastreador de errores se actualiza.
Solo tiene una solución, utiliza un servicio en primer plano y registra el receptor de difusión en el servicio.