studio permisos oreo android multithreading widget background-process android-8.0-oreo

permisos - api level 26 android studio



Cómo actualizar correctamente un widget en Android 8.0-Oreo-API 26 (1)

No indicas cuál es el mecanismo de activación de actualización. Pareces preocupado por la latencia ("Tu widget puede o no actualizarse por un tiempo"), por lo que asumiré que tu preocupación está vinculada a la interacción del usuario con el widget de la aplicación, como tocar un botón.

Use JobScheduler para programar un trabajo lo más rápido posible. Su widget puede o no ser actualizado por un tiempo.

Esta es una variación de "use JobIntentService ", que AFAIK es la solución recomendada para este tipo de escenario.

Otras opciones incluyen:

  • Utilice getForegroundService() con PendingIntent . Con esto, usted efectivamente "jura" que su servicio llamará startForeground() dentro del marco de tiempo ANR. Si el trabajo toma más de unos pocos segundos, llame a startForeground() para asegurarse de que Android no se ponga molesto. Esto debería minimizar el número de veces que aparece la notificación de primer plano. Y, si el usuario pulsó un botón y aún está ocupado trabajando unos segundos más tarde, es probable que desee mostrar una notificación o hacer algo para que el usuario sepa que lo que pidieron todavía está en progreso.

  • Utilice goAsync() en BroadcastReceiver , para trabajar en el contexto del receptor sin interrumpir el hilo principal de la aplicación. No he probado esto con Android 8.0+, así que YMMV.

Digamos que tengo un widget para una aplicación que tiene targetSDKVersion configurado en 26. Este widget tarda entre 100 ms y 10 segundos en actualizarse. La mayor parte del tiempo bajo 1s. Antes de Android O, si se llamaba a onUpdate () en mi AppWidgetProvider, podía iniciar un servicio en segundo plano para actualizar este widget. Sin embargo, Android O devuelve una excepción IllegalStateException si intenta ese comportamiento. La solución obvia de iniciar un servicio en primer plano parece ser una medida extrema para algo que se hará en menos de 10 años, el 99% del tiempo.

Soluciones posibles

  • Iniciar un servicio de primer plano para actualizar el widget. Molestar al usuario con una notificación que desaparecerá en 10s.
  • Use JobScheduler para programar un trabajo lo más rápido posible. Su widget puede o no ser actualizado por un tiempo.
  • Intente hacer el trabajo en un receptor de difusión. Bloquea el hilo de la interfaz de usuario para cualquier otra aplicación. Puaj
  • Intenta hacer trabajo en el widget widget. Bloquea el hilo de la interfaz de usuario para cualquier otra aplicación. Puaj
  • Abuso de GCM para obtener un servicio en segundo plano en ejecución. Mucho trabajo y se siente hacky.

Personalmente no me gusta ninguna de las soluciones anteriores. Ojalá me esté perdiendo algo.

(Aún más frustrante es que mi aplicación ya está cargada en la memoria por el sistema que llama onUpdate (). No veo cómo cargar mi aplicación en la memoria para llamar a onUpdate (), pero luego no le doy 1s a la aplicación para actualizar el widget el hilo de la interfaz de usuario está salvando a nadie la duración de la batería.)