OnReceive Asynchronous Operations y recolección de basura

Es el hilo de rosca en el método onReceive elegible para la recolección de basura antes de que se complete?

@Override public void onReceive(final Context context, Intent intent) { final int alarmId = intent.getExtras().getInt(EXTRA_ALARM_ID); Log.i(TAG, "/onReceive with an alarmVo.id of " + alarmId); // RUN MY THREAD new Thread(new Runnable() { @Override public void run() { AlarmUtil.setNextAlarm(context, alarmId); } }).start(); }

De lo que entiendo de aquí: http://developer.android.com/reference/android/content/BroadcastReceiver.html es, pero no estoy muy seguro.

"Cualquier cosa que requiera operación asincrónica no está disponible, porque tendrá que volver de la función para manejar la operación asincrónica, pero en ese punto el BroadcastReceiver ya no está activo y por lo tanto el sistema es libre de matar su proceso antes de que la operación asincrónica termine . "

Si obtiene la basura recopilada, ¿cómo puedo solucionar esto? ¿Cuál debería ser mi enfoque?

No. Cualquier objeto de subproceso que se haya iniciado a través del método start () que aún no se ha completado actúa como una raíz de recolección de basura … ni ella ni nada de lo que refiera fuertemente es elegible para ser recolectada hasta que su método run () complete .

Véase también estas respuestas:

Cuando wil el nuevo hilo () sin referencia se recoge basura
Java Thread Basura recolectada o no

EDIT : Ahora que ha agregado contexto adicional a su pregunta las cosas son un poco más claras. El problema es que este caso es algo completamente diferente a la recolección de basura. En el caso de un BroadcastReceiver publicado estáticamente (definido en el manifiesto de una aplicación con la etiqueta <receiver> ), Android es libre de matar su proceso después de que onReceive(Context, Intent) regrese. Su operación asíncrona no se detendría debido a un GC, se detendría debido a Android matando el proceso que lo está hospedando.

En cuanto a su enfoque, todo depende de lo que usted está tratando de lograr. Si el código que desea ejecutar en su BroadcastReceiver se puede ejecutar de forma síncrona, entonces ese sería el enfoque más fácil. Estoy asumiendo que no es posible sin embargo. En ese caso, esta parte de los documentos parece aplicar (énfasis mío):

Una vez que vuelve de onReceive (), BroadcastReceiver ya no está activo, y su proceso de hosting es tan importante como cualquier otro componente de la aplicación que se esté ejecutando en él. Esto es especialmente importante porque si ese proceso sólo alojaba el BroadcastReceiver (un caso común para aplicaciones con las que el usuario nunca ha interactuado o recientemente), al regresar de onReceive () el sistema considerará su proceso vacío y agresivamente matar De manera que se disponga de recursos para otros procesos más importantes.

Esto significa que para operaciones de más larga duración, usará a menudo un Servicio junto con un BroadcastReceiver para mantener activo el proceso de contención durante todo el tiempo de su operación .

Por lo tanto, ejecute su código de receptor de forma síncrona o utilice un servicio para mantener su operación asíncrona en funcionamiento el tiempo suficiente para completarse.

(Por supuesto, todo esto sólo se aplica si está registrando su receptor de forma estática en una aplicación que de otra forma estaría inactiva.) Si está registrándolo dinámicamente desde otro componente activo (por ejemplo, una actividad), entonces ese componente podría gestionar su operación asíncrona. Respuesta para más información sobre eso.)