Bem-vindos de volta, pessoal.
Após os receptores de transmissão.
Vamos dar uma olhada nos serviços, que é o terceiro componente principal do nosso aplicativo Android.
Então, quando precisamos lidar com serviços em nosso aplicativo móvel?
Às vezes, temos que lidar com muitas coisas.
Por exemplo, em nosso jogo, temos que renderizar todos os gráficos, controlar os objetos
e coisas assim.
Além dos jogos, talvez tenhamos que lidar, por exemplo, com solicitações de rede ou reprodução de música, interação de arquivos,
operações complexas, coisas desse tipo.
Todos eles exigem um pouco de tempo.
E esse é o problema, por exemplo, se você estiver tentando fazer uma solicitação de rede na atividade
principal, ou seja, no método on create, teremos que esperar até que essa solicitação de rede seja concluída e isso
pode demorar um pouco.
O problema agora é que o aplicativo deixa de responder, digamos, por dois, três ou quatro segundos.
E isso é algo que o sistema Android não aceita.
Portanto, depois de bloquear o menu, esqueço nosso tópico de atividade por um determinado período de tempo.
O sistema Android encerrará nosso aplicativo.
Portanto, se a operação simplesmente demorar muito, o sistema de chamadas do Android fechará nosso aplicativo.
E isso é algo que, obviamente, não queremos que o sistema Android não queira ter aplicativos que bloqueiem
o thread da interface do usuário e não queremos que os aplicativos sejam fechados.
A solução para isso são os serviços, pois eles são executados em segundo plano, não bloqueiam
o thread da interface do usuário e, portanto, podem ser usados para tarefas demoradas, por exemplo, como tocar
música ou fazer algumas solicitações de rede.
E, de modo geral, temos dois tipos de serviços.
A primeira é o serviço de início, e essa é a abordagem mais comum.
Como se tivéssemos presumido isso.
Simplesmente iniciamos nosso serviço.
O serviço está executando alguma tarefa e, em seguida, é fechado.
Por exemplo, reproduzir um arquivo de música, fazer uma solicitação de rede, coisas desse tipo.
Ok, este é o serviço inicial.
Além disso, também temos um serviço vinculado e agora ele está ficando um pouco complexo, mas
não muito complexo.
Portanto, o serviço de entrada está vinculando clientes ao serviço, o que significa que podemos ter outros aplicativos
interagindo com o nosso serviço neste momento.
O conceito, quero dizer, é muito bom que coisas como essa sejam possíveis, mas também é um pouco
complicado porque esses clientes estão vinculados ao nosso serviço.
Eles podem interagir com este, mas agora temos que esperar até que todos os clientes se desconectem do nosso serviço,
até que ele seja encerrado.
Esses são os nossos dois serviços.
Temos o método start service e temos um método on bind.
Esses são os principais métodos relacionados a esses dois serviços.
Tudo bem.
A desvantagem do serviço é que não podemos fazer uma atualização da interface do usuário.
Isso não é possível porque, como já mencionado, o serviço está sendo executado em segundo
plano e não tem conexão com o thread principal da interface do usuário.
Portanto, se você quiser realizar coisas como essa, precisamos usar receptores de transmissão.
Mas isso é perfeitamente aceitável.
Já estamos familiarizados com isso.
Portanto, no passado, a interação de serviço comum era a seguinte.
Temos o nosso aplicativo Android e esse aplicativo Android registrou e transmitiu o receptor para
o evento de transmissão de inicialização concluída.
Assim, depois que o smartphone termina a inicialização, ele informa os aplicativos sobre esse evento
com a transmissão de inicialização concluída.
Agora, em nosso aplicativo, podemos implementar um receptor de transmissão e, no método receptor, podemos iniciar
nosso serviço que está sondando nosso servidor.
Se houver alguma atualização para esse aplicativo, isso significa que o usuário não precisará abrir esse aplicativo.
O smartphone foi finalizado, mas esse evento de transmissão foi acionado.
Nosso próprio método receive está obtendo esse evento e iniciando em segundo plano nosso serviço que
está se conectando ou solicitando nosso servidor em relação à óptica.
Sim, esse comportamento não era comum até o Android 8, porque então não estamos mais permitindo
essa execução em segundo plano.
Está bem.
Isso é incrível porque todos esses componentes do Android podem se unir, interagir
uns com os outros e realizar muitas coisas interessantes.
Além disso, é claro, coisas vulneráveis.
Por falar em vulnerabilidade, o que devemos procurar e atender se quisermos atacá-la?
E a resposta para essa pergunta já é não, pelo menos para o serviço START, porque o serviço START
não é o serviço bind.
O serviço START está sendo invocado por meio de uma intenção e, portanto, temos que fazer isso.
Temos que dar uma olhada nesse método de comando, porque lá estamos fornecendo essa intenção.
Mais uma vez, temos que descobrir quais dados estão sendo passados para essa função e quais coisas podemos
acionar.
Exatamente da mesma forma que vimos no exemplo do receptor de transmissão.
Muito bem.
Está bem.
Com relação aos serviços de bein, é um pouco mais complicado, porque lá temos uma opção diferente.
Temos um objeto de mensagem e, ainda assim, temos que descobrir o que está acontecendo
com esse objeto de mensagem.
Mas, quero dizer, a abordagem é.
É bastante idêntico.
À esquerda, estamos lidando com intenso.
E, à direita, estamos lidando com mensagem, objeto de ataque e serviço.
Mais uma vez, o serviço precisa ser exportado e precisamos ter a permissão para interagir com
ele.
Se estiver usando uma permissão personalizada, não há problema.
Até a proteção que se tornará assinatura, então estamos tendo um pequeno problema.
Mas, a menos que o nível de proteção não esteja sendo definido para uma assinatura, poderemos interagir
com ela se tiver sido exportada.
OC Perfeito, porque isso é tudo o que precisamos saber sobre o serviço.