Acesso à rede e sincronização no Wear OS

Com o Wear OS by Google, um smartwatch pode se conectar diretamente a uma rede, sem acesso a um smartphone Android ou iOS. Não use a API Data Layer para conectar um app do Wear OS a uma rede. Em vez disso, siga as diretrizes e as etapas apresentadas neste guia.

Acesso à rede

Os apps Wear OS podem fazer solicitações de rede. Quando um relógio tem conexão Bluetooth com um smartphone, o tráfego de rede do relógio geralmente usa o smartphone como proxy.

Quando um smartphone não está disponível, o Wi-Fi e as redes celulares são usados, dependendo do hardware do relógio. A plataforma Wear OS processa as transições entre redes.

Você pode usar protocolos como HTTP, TCP e UDP. No entanto, as APIs android.webkit (incluindo a classe CookieManager) não estão disponíveis. Você pode usar cookies lendo e gravando cabeçalhos em solicitações e respostas.

Também recomendamos o uso da API WorkManager para solicitações assíncronas, incluindo pesquisas em intervalos regulares.

Se for necessário se conectar a tipos de rede específicos, consulte Como ler o estado da rede.

Acesso à rede de alta largura de banda

A plataforma Wear OS gerencia a conectividade de rede para proporcionar a melhor experiência geral do usuário. A plataforma escolhe a rede padrão ativa considerando dois requisitos:

  • Bateria de longa duração
  • Largura de banda da rede

Quando a prioridade é a economia da bateria, a rede ativa pode não ter uma largura de banda suficiente para executar tarefas que precisam de rede, como enviar arquivos grandes ou fazer streaming de mídia.

Esta seção apresenta orientações sobre como usar a classe ConnectivityManager para garantir que a largura de banda necessária esteja disponível para o app. Para informações gerais sobre controle detalhado de recursos de rede, consulte Gerenciar o uso da rede.

Solicitar conectividade Wi-Fi

Para casos de uso que exigem acesso à rede de alta largura de banda, como transferência de arquivos grandes ou streaming de mídia, solicite conectividade com um transporte desse tipo, como Wi-Fi. Essa solicitação é mostrada neste exemplo:

Kotlin

val callback = object : ConnectivityManager.NetworkCallback() {
    override fun onAvailable(network: Network) {
        super.onAvailable(network)
        // The Wi-Fi network has been acquired. Bind it to use this network by default.
        connectivityManager.bindProcessToNetwork(network)
    }

    override fun onLost(network: Network) {
        super.onLost(network)
        // Called when a network disconnects or otherwise no longer satisfies this request or callback.
    }
}
connectivityManager.requestNetwork(
    NetworkRequest.Builder().addTransportType(NetworkCapabilities.TRANSPORT_WIFI).build(),
    callback
)

Java

ConnectivityManager.NetworkCallback callback = new ConnectivityManager.NetworkCallback() {
    public void onAvailable(Network network) {
        super.onAvailable(network);
        // The Wi-Fi network has been acquired. Bind it to use this network by default.
        connectivityManager.bindProcessToNetwork(network);
    }

    public void onLost(Network network) {
        super.onLost(network);
        // Called when a network disconnects or otherwise no longer satisfies this request or callback.
    }
};
connectivityManager.requestNetwork(
        new NetworkRequest.Builder().addTransportType(NetworkCapabilities.TRANSPORT_WIFI).build(),
        callback
);

A conexão a uma rede pode não ser instantânea, porque o rádio celular ou o Wi-Fi do relógio pode estar desativado para economizar bateria. Se não for possível conectar o relógio a uma rede, o método onAvailable() da instância NetworkCallback não vai ser chamado.

Depois que onAvailable() é chamado, o dispositivo tenta permanecer conectado à rede Wi-Fi até que o NetworkCallback seja liberado. Para preservar a duração da bateria, quando a rede Wi-Fi não for mais necessária, libere o callback, conforme mostrado no exemplo abaixo.

Kotlin

connectivityManager.bindProcessToNetwork(null)
connectivityManager.unregisterNetworkCallback(callback)

Java

connectivityManager.bindProcessToNetwork(null);
connectivityManager.unregisterNetworkCallback(callback);

Iniciar a atividade de configuração de Wi-Fi

Ao solicitar uma rede Wi-Fi, o sistema tenta se conectar a uma rede salva, caso alguma tenha sido configurada e esteja dentro do alcance. No entanto, se nenhuma rede Wi-Fi salva estiver disponível, o método de callback onAvailable() da instância NetworkCallback não vai ser chamado.

Se você estiver usando um Handler para definir o tempo limite da solicitação de rede, vai ser possível direcionar o usuário a uma rede Wi-Fi quando o tempo limite for atingido. Envie o usuário diretamente à atividade para adicionar uma rede Wi-Fi usando a intent abaixo:

Kotlin

context.startActivity(Intent("com.google.android.clockwork.settings.connectivity.wifi.ADD_NETWORK_SETTINGS"))

Java

context.startActivity(new Intent("com.google.android.clockwork.settings.connectivity.wifi.ADD_NETWORK_SETTINGS"));

Para iniciar a atividade de configuração, o app precisa ter esta permissão: android.permission.CHANGE_WIFI_STATE.

Considerações sobre a interface do usuário

Se o app precisar de uma conexão com uma nova rede Wi-Fi para uma operação de alta largura de banda, verifique se o motivo para a conexão está claro para o usuário antes de iniciar as configurações de Wi-Fi. Só peça ao usuário para adicionar uma nova rede Wi-Fi quando a rede de alta largura de banda for necessária. Não bloqueie o acesso a recursos do app que não precisem de uma rede de alta largura de banda.

A Figura 1 mostra um app de música. O app deixa o usuário procurar músicas usando uma rede de largura de banda menor e só exige que ele adicione uma nova rede Wi-Fi para fazer o download ou streaming de músicas.

Download de música

Figura 1. Fluxo de um app para download de música.

Considerações sobre uso de energia e dados

Para ajudar a preservar a duração da bateria e minimizar o uso de dados móveis, adie tarefas de rede não essenciais, como relatórios de análise ou coleta de registros, até que o dispositivo Wear OS restaure uma conexão Bluetooth ou Wi-Fi.

Mensagens na nuvem

Para enviar notificações, os apps podem usar diretamente o Firebase Cloud Messaging (FCM).

Nenhuma API para acesso à rede ou FCM é específica do Wear OS. Consulte a documentação atual sobre como se conectar a uma rede e mensagens na nuvem.

O FCM funciona bem com a Soneca e é a forma recomendada de enviar notificações para um smartwatch.

Forneça mensagens do FCM coletando um token de registro para um dispositivo quando o app Wear OS for executado. Em seguida, inclua o token como parte do destino quando o servidor enviar mensagens para o endpoint REST do FCM. O FCM enviará mensagens para o dispositivo identificado pelo token.

As mensagens do FCM são enviadas no formato JavaScript Object Notation (JSON) e podem incluir um destes payloads ou ambos:

  • Payload de notificação: ao receber um payload de notificação no relógio, os dados são mostrados para o usuário no stream de notificações. Quando o usuário toca na notificação, o app é iniciado.
  • Payload de dados: o payload tem um conjunto de pares personalizados de chave ou valor. O payload é enviado como dados para o app do Wear OS.

Para mais informações e exemplos de payloads, consulte Sobre as mensagens do FCM.

Por padrão, as notificações são compartilhadas de um app do smartphone para o relógio. Se você tiver um app Wear OS independente e um app de smartphones correspondente, pode haver notificações duplicadas. Por exemplo, uma mesma notificação do FCM, recebida tanto pelo smartphone como pelo relógio, pode ser mostrada em ambos os dispositivos de maneira independente. Para evitar isso, use as APIs de ponte.

Usar serviços em segundo plano

Para que sejam executadas corretamente, as tarefas em segundo plano precisam considerar o modo Soneca e de App em espera.

Quando uma tela é desligada ou entra no modo ambiente por um certo período, um subconjunto do modo Soneca pode ser ativado, adiando as tarefas em segundo plano por algum tempo. Depois disso, quando o dispositivo fica inativo por um tempo prolongado, o modo Soneca normal é ativado. Agende solicitações usando a API WorkManager, que permite que o app execute um código que não seja afetado pelo modo Soneca.

Programar com restrições

É possível usar restrições para configurar solicitações para preservar a duração da bateria. Selecione e inclua nas solicitações uma ou mais das restrições abaixo:

  • Agende uma solicitação que exija rede. Especifique se NetworkType é CONNECTED (conectado) ou UNMETERED (ilimitado). UNMETERED serve para grandes transferências de dados e CONNECTED para transferências pequenas.
  • Programe uma solicitação ao carregar.
  • Programe uma solicitação enquanto o dispositivo estiver inativo. Isso é útil para sincronizações ou trabalhos em segundo plano de menor prioridade, especialmente quando o dispositivo está carregando.

Observe que algumas redes de baixa largura de banda, como Bluetooth LE, são consideradas limitadas.

Para saber mais, consulte o guia do WorkManager: Efeito das restrições no trabalho periódico.