page.title=Serviços vinculados parent.title=Serviços parent.link=services.html @jd:body
Um serviço vinculado é o servidor em uma interface servidor-cliente. Um serviço vinculado permite que componentes (como atividades) sejam vinculados ao serviço, enviem solicitações, recebam respostas e até estabeleçam comunicação entre processos (IPC). Um serviço vinculado, geralmente, vive somente enquanto serve outro componente do aplicativo e não é executado em segundo plano indefinidamente.
Este documento mostra como criar um serviço vinculado, inclusive como criar vínculos com o serviço a partir de outros componentes do aplicativo. No entanto, você também deve consultar a documentação Serviços para obter informações adicionais sobre serviços de forma geral, por exemplo: como enviar notificações de um serviço, como definir o serviço a ser executado em primeiro plano etc.
Um serviço vinculado é uma implementação da classe {@link android.app.Service} que permite que outros aplicativos sejam vinculados e interajam com ele. Para fornecer a vinculação a um serviço, você deve implementar o método de retorno de chamada {@link android.app.Service#onBind onBind()}. Este método retorna um objeto {@link android.os.IBinder} que define a interface de programação que os clientes podem usar para interagir com o serviço.
Como discutido na documentação Serviços, é possível criar um serviço que já foi iniciado e vinculado. Ou seja, o serviço pode ser iniciado chamando {@link android.content.Context#startService startService()}, que permite que ele permaneça em execução indefinidamente e também permite que um cliente vincule-o chamando {@link android.content.Context#bindService bindService()}.
Se você permitir que o serviço seja iniciado e vinculado, então, quando ele for iniciado, o sistema não o destruirá quando todos os clientes desfizerem a vínculo. Em vez disso, você deve interromper o serviço explicitamente chamando {@link android.app.Service#stopSelf stopSelf()} ou {@link android.content.Context#stopService stopService()}.
Apesar de normalmente se implementar {@link android.app.Service#onBind onBind()} ou {@link android.app.Service#onStartCommand onStartCommand()}, às vezes é necessário implementar ambos. Por exemplo, um reprodutor de música pode achar útil permitir que o seu serviço permaneça em execução indefinidamente, além de fornecer vinculação. Desta forma, uma atividade pode iniciar o serviço para reproduzir algumas músicas e a música continuará em reprodução mesmo quando o usuário sair do aplicativo. Em seguida, quando o usuário voltar ao aplicativo, a atividade poderá vincular-se ao serviço para retomar o controle da reprodução.
Certifique-se de ler a seção sobre Gerenciamento do ciclo de vida de um serviço vinculado para obter mais informações sobre o ciclo de vida do serviço ao adicionar vinculação a um serviço iniciado.
Um cliente pode vincular-se ao serviço chamando {@link android.content.Context#bindService bindService()}. Quando isto ocorre, é preciso fornecer uma implementação de {@link android.content.ServiceConnection}, que monitora a conexão com o serviço. O método {@link android.content.Context#bindService bindService()} retorna imediatamente sem um valor, mas quando o sistema Android cria a conexão entre o cliente e o serviço, ele chama {@link android.content.ServiceConnection#onServiceConnected onServiceConnected()} em {@link android.content.ServiceConnection} para fornecer o {@link android.os.IBinder} que o cliente pode usar para comunicar-se com o serviço.
Vários clientes podem conectar-se ao serviço de uma vez. No entanto, o sistema chama o método {@link android.app.Service#onBind onBind()} do serviço para recuperar o {@link android.os.IBinder} somente quando o primeiro cliente é vinculado. Em seguida, o sistema entrega o mesmo {@link android.os.IBinder} para quaisquer clientes adicionais que vincularem-se, sem chamar {@link android.app.Service#onBind onBind()} novamente.
Quando o último cliente desvincular-se do serviço, o sistema destruirá o serviço (a não ser que ele também seja iniciado por {@link android.content.Context#startService startService()}).
Ao implementar o serviço vinculado, o mais importante é definir a interface que o método de retorno de chamada {@link android.app.Service#onBind onBind()} retornará. Há poucas maneiras diferentes de definir a interface {@link android.os.IBinder} do serviço e a seção a seguir discute cada técnica.
Ao criar um serviço que fornece vinculação, você deve fornecer um {@link android.os.IBinder} que ofereça a interface de programação que os clientes podem usar para interagir com o serviço. Há três maneiras possíveis de definir a interface:
Esta é a técnica preferencial quando o serviço é meramente um trabalhador de segundo plano para o aplicativo. O único motivo pelo qual não se criaria a interface desta maneira é porque o serviço está sendo usado por outros aplicativos ou em processos separados.
Esta é a maneira mais simples de estabelecer comunicação entre processos (IPC), pois o {@link android.os.Messenger} coloca todas as solicitações em fila em um único encadeamento para que você não precise projetar o serviço de modo que seja seguro para encadeamentos.
Para usar a AIDL diretamente, deve-se criar um arquivo {@code .aidl} que defina a interface de programação. As ferramentas SDK do Android usam este arquivo para gerar uma classe abstrata que implemente a interface e lide com a IPC, que pode ser estendida dentro do serviço.
Observação: a maioria dos aplicativos não deve usar a AIDL para criar um serviço vinculado, pois isto requer capacidade de se trabalhar com encadeamentos múltiplos e pode resultar em uma implementação mais complicada. Portanto, a AIDL não é adequada para a maioria dos aplicativos e este documento não discute o seu uso para o serviço. Caso tenha certeza de que precisa usar a AIDL diretamente, consulte a documentação AIDL.
Se o serviço for usado somente pelo aplicativo local e não precisar trabalhar entre processos, então será possível implementar a própria classe {@link android.os.Binder} que fornece ao cliente acesso direto aos métodos públicos no serviço.
Observação: isto funciona somente se o cliente e o serviço estiverem no mesmo aplicativo e processo, o que é muito comum. Por exemplo, isto funcionaria bem para um aplicativo de música que precise vincular uma atividade ao próprio serviço que está reproduzindo música em segundo plano.
Como configurar:
Observação: o motivo pelo qual o serviço e o cliente devem estar no mesmo aplicativo é para que o cliente possa lançar o objeto retornado e chamar as APIs adequadamente. O serviço e o cliente também devem estar no mesmo processo, pois esta técnica não possui nenhuma ingerência entre processos.
Por exemplo, a seguir há um serviço que fornece aos clientes acesso aos métodos no serviço por meio de uma implementação de {@link android.os.Binder}:
public class LocalService extends Service {
// Binder given to clients
private final IBinder mBinder = new LocalBinder();
// Random number generator
private final Random mGenerator = new Random();
/**
* Class used for the client Binder. Because we know this service always
* runs in the same process as its clients, we don't need to deal with IPC.
*/
public class LocalBinder extends Binder {
LocalService getService() {
// Return this instance of LocalService so clients can call public methods
return LocalService.this;
}
}
@Override
public IBinder onBind(Intent intent) {
return mBinder;
}
/** method for clients */
public int getRandomNumber() {
return mGenerator.nextInt(100);
}
}
O {@code LocalBinder} fornece o método {@code getService()} para que os clientes recuperem a instância atual de {@code LocalService}. Isto permite que os clientes chamem métodos públicos no serviço. Por exemplo, eles podem chamar {@code getRandomNumber()} a partir do serviço.
Abaixo há uma atividade que vincula-se a {@code LocalService} e chama {@code getRandomNumber()} quando um botão é pressionado:
public class BindingActivity extends Activity {
LocalService mService;
boolean mBound = false;
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.main);
}
@Override
protected void onStart() {
super.onStart();
// Bind to LocalService
Intent intent = new Intent(this, LocalService.class);
bindService(intent, mConnection, Context.BIND_AUTO_CREATE);
}
@Override
protected void onStop() {
super.onStop();
// Unbind from the service
if (mBound) {
unbindService(mConnection);
mBound = false;
}
}
/** Called when a button is clicked (the button in the layout file attaches to
* this method with the android:onClick attribute) */
public void onButtonClick(View v) {
if (mBound) {
// Call a method from the LocalService.
// However, if this call were something that might hang, then this request should
// occur in a separate thread to avoid slowing down the activity performance.
int num = mService.getRandomNumber();
Toast.makeText(this, "number: " + num, Toast.LENGTH_SHORT).show();
}
}
/** Defines callbacks for service binding, passed to bindService() */
private ServiceConnection mConnection = new ServiceConnection() {
@Override
public void onServiceConnected(ComponentName className,
IBinder service) {
// We've bound to LocalService, cast the IBinder and get LocalService instance
LocalBinder binder = (LocalBinder) service;
mService = binder.getService();
mBound = true;
}
@Override
public void onServiceDisconnected(ComponentName arg0) {
mBound = false;
}
};
}
O exemplo acima mostra como o cliente vincula um serviço usando uma implementação de {@link android.content.ServiceConnection} e o retorno de chamada {@link android.content.ServiceConnection#onServiceConnected onServiceConnected()}. A próxima seção fornece mais informações sobre este processo de vinculação ao serviço.
Observação: o exemplo acima não desfaz a vinculação explicitamente a partir do serviço, mas todos os clientes devem fazê-lo no momento adequado (como quando a atividade pausa).
Para obter mais códigos de exemplo, consulte a classe {@code LocalService.java} e a classe {@code LocalServiceActivities.java} em ApiDemos.
Quando é necessário fazer uma IPC, usar o {@link android.os.Messenger} para a interface é mais simples do que implementá-la com AIDL, pois o {@link android.os.Messenger} enfileira todas as chamadas do serviço, enquanto que uma interface de AIDL pura envia solicitações simultâneas ao serviço, que deve então lidar com vários encadeamentos.
Para a maioria dos aplicativos, o serviço não precisa realizar vários encadeamentos. Portanto, usar {@link android.os.Messenger} permite que o serviço lide com uma chamada por vez. Caso seja importante que o serviço realize vários encadeamentos, deve-se usar a AIDL para definir a interface.
Caso precise que o serviço comunique-se com processos remotos, é possível usar o {@link android.os.Messenger} para fornecer a interface ao serviço. Esta técnica permite estabelecer comunicação entre processos (IPC) sem precisar usar a AIDL.
A seguir há um resumo sobre como usar um {@link android.os.Messenger}:
Desta forma, não há "métodos" para o cliente chamar no serviço. Em vez disso, o cliente envia "mensagens" (objetos {@link android.os.Message}) que o serviço recebe no {@link android.os.Handler}.
Abaixo há um exemplo simples de serviço que usa uma interface {@link android.os.Messenger}:
public class MessengerService extends Service {
/** Command to the service to display a message */
static final int MSG_SAY_HELLO = 1;
/**
* Handler of incoming messages from clients.
*/
class IncomingHandler extends Handler {
@Override
public void handleMessage(Message msg) {
switch (msg.what) {
case MSG_SAY_HELLO:
Toast.makeText(getApplicationContext(), "hello!", Toast.LENGTH_SHORT).show();
break;
default:
super.handleMessage(msg);
}
}
}
/**
* Target we publish for clients to send messages to IncomingHandler.
*/
final Messenger mMessenger = new Messenger(new IncomingHandler());
/**
* When binding to the service, we return an interface to our messenger
* for sending messages to the service.
*/
@Override
public IBinder onBind(Intent intent) {
Toast.makeText(getApplicationContext(), "binding", Toast.LENGTH_SHORT).show();
return mMessenger.getBinder();
}
}
Observe que o método {@link android.os.Handler#handleMessage handleMessage()} no {@link android.os.Handler} é onde o serviço recebe a {@link android.os.Message} e decide o que fazer, com base no membro {@link android.os.Message#what}.
Tudo que o cliente precisa fazer é criar um {@link android.os.Messenger} com base no {@link android.os.IBinder} retornado pelo serviço e enviar uma mensagem usando {@link android.os.Messenger#send send()}. Por exemplo, a seguir há uma atividade simples que vincula-se ao serviço e envia a mensagem {@code MSG_SAY_HELLO} a ele:
public class ActivityMessenger extends Activity {
/** Messenger for communicating with the service. */
Messenger mService = null;
/** Flag indicating whether we have called bind on the service. */
boolean mBound;
/**
* Class for interacting with the main interface of the service.
*/
private ServiceConnection mConnection = new ServiceConnection() {
public void onServiceConnected(ComponentName className, IBinder service) {
// This is called when the connection with the service has been
// established, giving us the object we can use to
// interact with the service. We are communicating with the
// service using a Messenger, so here we get a client-side
// representation of that from the raw IBinder object.
mService = new Messenger(service);
mBound = true;
}
public void onServiceDisconnected(ComponentName className) {
// This is called when the connection with the service has been
// unexpectedly disconnected -- that is, its process crashed.
mService = null;
mBound = false;
}
};
public void sayHello(View v) {
if (!mBound) return;
// Create and send a message to the service, using a supported 'what' value
Message msg = Message.obtain(null, MessengerService.MSG_SAY_HELLO, 0, 0);
try {
mService.send(msg);
} catch (RemoteException e) {
e.printStackTrace();
}
}
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.main);
}
@Override
protected void onStart() {
super.onStart();
// Bind to the service
bindService(new Intent(this, MessengerService.class), mConnection,
Context.BIND_AUTO_CREATE);
}
@Override
protected void onStop() {
super.onStop();
// Unbind from the service
if (mBound) {
unbindService(mConnection);
mBound = false;
}
}
}
Observe que este exemplo não mostra como o serviço pode responder ao cliente. Caso queira que o serviço responda, é necessário criar um {@link android.os.Messenger} no cliente também. Em seguida, quando o cliente receber o retorno de chamada de {@link android.content.ServiceConnection#onServiceConnected onServiceConnected()}, ele enviará uma {@link android.os.Message} para o serviço que inclui o {@link android.os.Messenger} no parâmetro {@link android.os.Message#replyTo} do método {@link android.os.Messenger#send send()}.
É possível ver um exemplo de como fornecer mensagens de duas vias nos exemplos {@code MessengerService.java} (serviço) e {@code MessengerServiceActivities.java} (cliente).
Um componente de aplicativo (cliente) pode vincular-se a um serviço chamando {@link android.content.Context#bindService bindService()}. O sistema Android, em seguida, chama o método {@link android.app.Service#onBind onBind()} do serviço, que retorna um {@link android.os.IBinder} para interagir com o serviço.
A vinculação é assíncrona. {@link android.content.Context#bindService bindService()} retorna imediatamente e não retorna o {@link android.os.IBinder} ao cliente. Para receber {@link android.os.IBinder}, o cliente deve criar uma instância de {@link android.content.ServiceConnection} e passá-la para {@link android.content.Context#bindService bindService()}. O {@link android.content.ServiceConnection} inclui um método de retorno de chamada que o sistema chama para entregar o {@link android.os.IBinder}.
Observação: somente atividades, serviços e provedores de conteúdo podem vincular-se a um serviço — você não pode fazer isto a partir de um receptor de transmissão.
Portanto, para vincular-se a um serviço a partir do cliente, deve-se:
Sua implementação deve substituir dois métodos de retorno de chamada:
Quando um cliente é destruído, o vínculo com o serviço acaba. No entanto, sempre desvincule-se ao terminar a interação com o serviço ou quando a atividade pausar para que o serviço possa ser encerrado enquanto não estiver em uso (os momentos adequados para vincular ou desvincular são abordados mais abaixo).
Por exemplo, o fragmento a seguir conecta o cliente ao serviço criado acima estendendo a classe Binder para que tudo que ele tenha que fazer seja lançar o {@link android.os.IBinder} retornado para a classe {@code LocalService} e solicitar a instância de {@code LocalService}:
LocalService mService;
private ServiceConnection mConnection = new ServiceConnection() {
// Called when the connection with the service is established
public void onServiceConnected(ComponentName className, IBinder service) {
// Because we have bound to an explicit
// service that is running in our own process, we can
// cast its IBinder to a concrete class and directly access it.
LocalBinder binder = (LocalBinder) service;
mService = binder.getService();
mBound = true;
}
// Called when the connection with the service disconnects unexpectedly
public void onServiceDisconnected(ComponentName className) {
Log.e(TAG, "onServiceDisconnected");
mBound = false;
}
};
Com este {@link android.content.ServiceConnection}, o cliente pode vincular-se a um serviço passando-o para {@link android.content.Context#bindService bindService()}. Por exemplo:
Intent intent = new Intent(this, LocalService.class); bindService(intent, mConnection, Context.BIND_AUTO_CREATE);
A seguir há algumas observações importantes sobre a vinculação com um serviço:
Observação: geralmente, não se realiza o vínculo e o seu rompimento durante o {@link android.app.Activity#onResume onResume()} e o {@link android.app.Activity#onPause onPause()} da atividade, pois esses retornos de chamada ocorrem em todas as transições do ciclo de vida e deve-se usar menos processamento possível nessas transações. Além disso, se várias atividades no aplicativo vincularem-se ao mesmo serviço e houver uma transação entre duas dessas atividades, o serviço poderá ser destruído e recriado à medida que a atividade desvincula-se, durante a pausa, antes do próximo vínculo, durante a retomada (esta transição de atividade para como as atividades coordenam os ciclos de vida é descrita no documento Atividades ).
Para obter mais códigos de exemplo mostrando como vincular a um serviço, consulte a classe {@code RemoteService.java} no ApiDemos.
Quando um serviço é desvinculado de todos os clientes, o sistema Android o destrói (a não ser que ele também tenha sido inicializado com {@link android.app.Service#onStartCommand onStartCommand()}). Portanto, não é necessário gerenciar o ciclo de vida do serviço se ele for puramente um serviço vinculado — o sistema Android o gerencia com base nos vínculos com os clientes.
No entanto, se você escolher implementar o método de retorno de chamada {@link android.app.Service#onStartCommand onStartCommand()}, interrompa o serviço explicitamente, pois o serviço já terá sido considerado como iniciado. Neste caso, o serviço permanece em execução até ser interrompido com {@link android.app.Service#stopSelf()} ou outras chamadas de componente {@link android.content.Context#stopService stopService()}, independente de vínculo com qualquer cliente.
Além disso, se o serviço for iniciado e aceitar vínculos, quando o sistema chamar o método {@link android.app.Service#onUnbind onUnbind()}, será possível retornar {@code true} opcionalmente se você quiser receber uma chamada de {@link android.app.Service#onRebind onRebind()} na próxima vez em que um cliente vincular-se ao serviço (em vez de receber uma chamada de {@link android.app.Service#onBind onBind()}). {@link android.app.Service#onRebind onRebind()} retorna vazio, mas o cliente ainda recebe {@link android.os.IBinder} no retorno de chamada {@link android.content.ServiceConnection#onServiceConnected onServiceConnected()}. Abaixo, a figura 1 ilustra a lógica para este tipo de ciclo de vida.
Figura 1. O ciclo de vida para um serviço que é iniciado e também permite vínculos.
Para obter mais informações sobre o ciclo de vida de um serviço iniciado, consulte o documento Serviços.