Servicio enlazado para Android: ¿debo volver a conectarlo manualmente en onServiceDisconnected o intenta volver a conectarlo automáticamente?

Question

Si me desconecto del servicio encuadernado debido a circunstancias inesperadas, después de llamar, ¿debo volver a conectarlo manualmente en el dispositivo desconectado o si intenta volver a conectarlo automáticamente?

public class MyServiceConnection extends Activity implements ServiceConnection { 

    MyBinder binder; 

    @Override 
    protected void onStart() { 
     super.onStart(); 

     connect(); 
    } 

    private void connect() { 
     bindService(new Intent(this, MyService.class), 
       this, Service.BIND_AUTO_CREATE); 
    } 

    @Override 
    public void onServiceConnected(ComponentName name, IBinder service) { 
     binder = (MyBinder) service; 
    } 

    @Override 
    public void onServiceDisconnected(ComponentName name) { 

     binder = null; 

     //should i reconnect here ? 
     connect(); 
    } 
} 

Answer 1

De acuerdo con la ServiceConnection API:

public abstract void onServiceDisconnected (nombre ComponentName)

llama cuando una conexión con el servicio se ha perdido. Esto generalmente ocurre cuando el proceso que aloja el servicio se ha bloqueado o ha sido eliminado. Esto no elimina ServiceConnection en sí mismo: este enlace al servicio permanecerá activo y recibirá una llamada a onServiceConnected (ComponentName, IBinder) cuando se ejecute el servicio.

Volver a su pregunta:

@Override 
public void onServiceDisconnected(ComponentName name) { 
    binder = null; 
    //should i reconnect here ? 
    connect(); 
} 

Es todo depende de qué proceso las vidas reales de servicio.

Servicio Local:

servicio se ejecuta en el mismo proceso que otros componentes (es decir, actividad que une a él) de la misma aplicación, cuando este proceso de aplicación de ámbito de solo se ha estrellado o hayan sido sacrificados, se Es muy probable que todos los componentes de este proceso (incluida la actividad vinculada a este servicio) también se destruyan. En este caso, llamar a connect() dentro deServiceDisconnected() no tiene ningún efecto, ya que cuando se recupera el proceso de la aplicación, todo se reanuda desde el principio y la actividad se vuelve a crear y el servicio se enlaza en la devolución de llamada onStart() de la actividad.

servicio remoto:

servicio se está ejecutando en el proceso separado, cuando este proceso se ha estropeado o muerto, sólo el servicio real es destruida, la actividad vive en otro proceso que se unió al servicio se mantuvo, así que probablemente sea correcto llamar a connect() en su devolución de llamada onServiceDisconnected() para volver a crear/volver a enlazar el servicio.

Consulte here para ver cómo configurar el servicio ejecutándose en un proceso separado en AndroidManifest.xml.

Answer 2

Me metí en esta vieja pregunta al hacer una búsqueda para una publicación de blog. La respuesta aceptada es bastante buena, pero no muestra la imagen completa cuando se trata de servicios IPC (remoto) encuadernados.

diagrama de estado de una conexión con el servicio IPC cota se ve así:

Y la respuesta a la pregunta de OP es: depende.

En primer lugar, cuando el servicio se bloquea o es destruido por el sistema operativo, permanece vinculado. Entonces la pregunta es si el sistema volverá a crear el servicio o no ...

• En caso ligado servicio IPC está siendo asesinados por el sistema operativo, que será re-creado y obtendrá una llamada a onServiceConnected(), por lo tanto, no hay necesidad de "volver a conectar".
• En caso de que el servicio IPC se bloquee, el sistema intentará volver a crearlo una vez; si se bloquea por segunda vez, el sistema no volverá a crearlo (probado en JellyBean, Lollipop y Marshmallow).

En teoría, se podría unbindService() y luego bindService() en cada llamada a onServiceDisconnected() - esto debería funcionar (creo).

Sin embargo, escribir un cliente realmente confiable para el servicio IPC encuadernado es un poco más trabajo, y la idea general (junto con la aplicación tutorial) se puede encontrar en here.