Los procesos en segundo plano pueden consumir mucha memoria y batería. Por ejemplo, una transmisión implícita puede iniciar muchos procesos en segundo plano registrados para escucharla, aunque esos procesos quizá no desempeñen un trabajo considerable. Esto puede afectar de forma significativa tanto el rendimiento del dispositivo como la experiencia de usuario.
Para corregir este problema, en Android N se aplican las siguientes restricciones:
Si la aplicación utiliza cualquiera de estas intents, debes quitar las dependencias en ellas lo antes posible a fin de poder orientar los dispositivos Android N correctamente. El framework de Android ofrece varias soluciones para mitigar la necesidad de estas transmisiones implícitas. Por ejemplo, {@link android.app.job.JobScheduler} y {@code GcmNetworkManager} proporcionan mecanismos sólidos para programar operaciones de red cuando se cumplen las condiciones especificadas, como una conexión a una red de uso no medido. Ahora también puedes usar {@link android.app.job.JobScheduler} para reaccionar a cambios en relación con los proveedores de contenido. Los objetos {@link android.app.job.JobInfo} encapsulan los parámetros que usa {@link android.app.job.JobScheduler} para programar el trabajo. Cuando se cumplen las condiciones del trabajo, el sistema ejecuta ese trabajo en el {@link android.app.job.JobService} de tu aplicación.
En este documento, aprenderemos cómo usar métodos alternativos, como {@link android.app.job.JobScheduler}, para adaptar tu aplicación a esas nuevas restricciones.
Las aplicaciones orientadas a Android N no reciben transmisiones {@link android.net.ConnectivityManager#CONNECTIVITY_ACTION} si en su manifiesto registran que las reciben, y los procesos que dependan de esta transmisión no se iniciarán. Esto podría ser un problema para aplicaciones que buscan escuchar los cambios en la red o realizar múltiples actividades en red cuando el dispositivo se conecta a una red sin medición de uso. Ya existen varias soluciones en relación con esta restricción en el framework de Android, pero elegir la correcta depende de lo que quieras lograr con tu aplicación.
Nota: Un {@link android.content.BroadcastReceiver} registrado con {@link android.content.Context#registerReceiver Context.registerReceiver()} continúa recibiendo estas transmisiones mientras se ejecuta la aplicación.
Cuando uses la clase {@link android.app.job.JobInfo.Builder JobInfo.Builder} para crear tu objeto {@link android.app.job.JobInfo}, aplica el método {@link android.app.job.JobInfo.Builder#setRequiredNetworkType setRequiredNetworkType()} y pasa {@link android.app.job.JobInfo JobInfo.NETWORK_TYPE_UNMETERED} como parámetro de trabajo. El siguiente ejemplo de código programa la ejecución de un servicio cuando el dispositivo se conecta a una red sin medición de uso y se está cargando:
public static final int MY_BACKGROUND_JOB = 0;
...
public static void scheduleJob(Context context) {
JobScheduler js =
(JobScheduler) context.getSystemService(Context.JOB_SCHEDULER_SERVICE);
JobInfo job = new JobInfo.Builder(
MY_BACKGROUND_JOB,
new ComponentName(context, MyJobService.class))
.setRequiredNetworkType(JobInfo.NETWORK_TYPE_UNMETERED)
.setRequiresCharging(true)
.build();
js.schedule(job);
}
Cuando se cumplan las condiciones para tu trabajo, tu aplicación recibirá un callback para ejecutar el método {@link android.app.job.JobService#onStartJob onStartJob()} en la {@code JobService.class} especificada. Para ver más ejemplos de la implementación de {@link android.app.job.JobScheduler}, consulta la aplicación de ejemplo JobScheduler.
Las aplicaciones que usan servicios de GMSCore y están orientadas a Android 5.0 (API nivel 21) o anterior, pueden usar {@code GcmNetworkManager} y especificar {@code Task.NETWORK_STATE_UNMETERED}.
Las aplicaciones que se ejecutan aún pueden escuchar {@code CONNECTIVITY_CHANGE} con un {@link android.content.BroadcastReceiver} registrado. No obstante, la API {@link android.net.ConnectivityManager} ofrece un método más robusto para solicitar un callback solo cuando se cumplen las condiciones de red especificadas.
Los objetos {@link android.net.NetworkRequest} definen los parámetros del callback de la red en términos de {@link android.net.NetworkCapabilities}. Creas objetos {@link android.net.NetworkRequest} con la clase {@link android.net.NetworkRequest.Builder NetworkRequest.Builder}. {@link android.net.ConnectivityManager#registerNetworkCallback(android.net.NetworkRequest, android.net.ConnectivityManager.NetworkCallback) registerNetworkCallback()} y luego pasa el objeto {@link android.net.NetworkRequest} al sistema. Cuando se cumplen las condiciones de la red, la aplicación recibe un callback para ejecutar el método {@link android.net.ConnectivityManager.NetworkCallback#onAvailable onAvailable()} definido en su clase {@link android.net.ConnectivityManager.NetworkCallback}.
La aplicación continuará recibiendo callbacks hasta que la aplicación salga o llame a {@link android.net.ConnectivityManager#unregisterNetworkCallback unregisterNetworkCallback()}.
En Android N, las aplicaciones no pueden enviar ni recibir transmisiones {@link android.hardware.Camera#ACTION_NEW_PICTURE} ni {@link android.hardware.Camera#ACTION_NEW_VIDEO}. Esta restricción ayuda a aliviar el impacto en el rendimiento y la experiencia de usuario cuando varias aplicaciones deben activarse para procesar una nueva imagen o video. Android N extiende {@link android.app.job.JobInfo} y {@link android.app.job.JobParameters} para proporcionar una solución alternativa.
Para activar trabajos en los cambios del URI de contenido, Android N extiende la API {@link android.app.job.JobInfo} con los siguientes métodos:
Nota: No se puede usar {@code TriggerContentUri()} junto con {@link android.app.job.JobInfo.Builder#setPeriodic setPeriodic()} ni {@link android.app.job.JobInfo.Builder#setPersisted setPersisted()}. Para controlar de forma constante la presencia de cambios en el contenido, programa un nuevo {@link android.app.job.JobInfo} antes de que el {@link android.app.job.JobService} de la aplicación termine de administrar la callback más reciente.
El siguiente código de ejemplo programa la activación de un trabajo cuando el sistema informe un cambio en el URI de contenido, {@code MEDIA_URI}:
public static final int MY_BACKGROUND_JOB = 0;
...
public static void scheduleJob(Context context) {
JobScheduler js =
(JobScheduler) context.getSystemService(Context.JOB_SCHEDULER_SERVICE);
JobInfo.Builder builder = new JobInfo.Builder(
MY_BACKGROUND_JOB,
new ComponentName(context, MediaContentJob.class));
builder.addTriggerContentUri(
new JobInfo.TriggerContentUri(MediaStore.Images.Media.EXTERNAL_CONTENT_URI,
JobInfo.TriggerContentUri.FLAG_NOTIFY_FOR_DESCENDANTS));
js.schedule(builder.build());
}
Cuando el sistema informa un cambio en el(los) URI de contenido especificado(s), tu aplicación recibe un callback y se pasa un objeto {@link android.app.job.JobParameters} al método {@link android.app.job.JobService#onStartJob onStartJob()} en {@code MediaContentJob.class}.
Android N también amplía {@link android.app.job.JobParameters} para permitir que tu aplicación reciba información útil sobre qué autoridades de contenido y URI activaron el trabajo:
El siguiente código de ejemplo anula el método {@link android.app.job.JobService#onStartJob JobService.onStartJob()} y registra las autoridades de contenido y los URI que activaron el trabajo:
@Override
public boolean onStartJob(JobParameters params) {
StringBuilder sb = new StringBuilder();
sb.append("Media content has changed:\n");
if (params.getTriggeredContentAuthorities() != null) {
sb.append("Authorities: ");
boolean first = true;
for (String auth :
params.getTriggeredContentAuthorities()) {
if (first) {
first = false;
} else {
sb.append(", ");
}
sb.append(auth);
}
if (params.getTriggeredContentUris() != null) {
for (Uri uri : params.getTriggeredContentUris()) {
sb.append("\n");
sb.append(uri);
}
}
} else {
sb.append("(No content)");
}
Log.i(TAG, sb.toString());
return true;
}
Optimizar tus aplicaciones para que se ejecuten en dispositivos con poca memoria o en condiciones de niveles bajos de memoria puede mejorar el rendimiento y la experiencia del usuario. Eliminar dependencias en servicios en segundo plano y receptores de transmisiones implícitas registrados estadísticamente puede ayudar a que tu aplicación se ejecute mejor en esos dispositivos. Si bien Android N toma medidas para reducir algunos de estos problemas, te recomendamos que optimices tu aplicación para que pueda ejecutarse sin utilizar esos procesos en segundo plano.
Android N presenta algunos comandos adicionales de Android Debug Bridge (ADB) que puedes usar para probar el comportamiento de la aplicación con esos procesos en segundo plano deshabilitados:
{@code $ adb shell cmd appops set <package> RUN_IN_BACKGROUND ignore}
{@code $ adb shell cmd appops set <package> RUN_IN_BACKGROUND allow}