Wear OS com Kotlin e Jetpack Compose em 2026: guia prático para apps de relógio

Resposta rápida: para criar um app Wear OS com Kotlin em 2026, comece com um módulo Android dedicado ao relógio, use Compose for Wear OS para telas adaptadas ao formato circular, mantenha cada fluxo curto e trate o smartwatch como produto próprio — não como uma miniatura do celular. Use Tiles e complicações para informações rápidas, Health Services para dados de exercício quando aplicável e Data Layer API apenas quando relógio e telefone realmente precisarem trocar dados. O maior desafio não é desenhar uma tela pequena: é entregar valor em poucos segundos sem desperdiçar bateria, rede ou atenção.

Wear OS faz sentido para ações rápidas e contextuais: iniciar um treino, confirmar uma tarefa, ver o próximo compromisso, acompanhar uma entrega, controlar mídia, registrar um hábito ou consultar uma métrica. Se o usuário precisa preencher formulário longo, navegar por cinco telas ou ler um relatório, o fluxo provavelmente pertence ao celular. Este guia mostra como estruturar um app de relógio em Kotlin, quais APIs escolher, como pensar em interface, sincronização, sensores, testes e publicação.

Antes de fixar versões, confira a documentação oficial do Wear OS e as notas de versão do Compose for Wear OS. O ecossistema evolui junto com Android Studio, Gradle, Compose e os serviços do relógio; os princípios de arquitetura deste guia permanecem mais estáveis que qualquer número de versão.

Quando vale criar um app para Wear OS?

Um bom caso de uso responde “sim” a pelo menos uma destas perguntas:

• a ação precisa estar disponível sem tirar o celular do bolso?
• o contexto depende do pulso, de movimento ou de exercício?
• a informação perde valor se demorar mais de alguns segundos para aparecer?
• o usuário repetirá a mesma ação curta várias vezes por dia?
• uma notificação acionável já resolve boa parte do fluxo?

Exemplos fortes:

O relógio não deve copiar a navegação completa do app Android. Se você já desenvolve para celular, use o guia de Kotlin para Android como base, mas reavalie escopo, conteúdo e duração de cada tarefa para o pulso.

App independente, companheiro ou híbrido?

Há três modelos comuns:

1. Standalone: instala e funciona no relógio sem depender do telefone. É adequado quando o wearable tem rede, autenticação e fonte de dados próprias.
2. Companion: complementa o app do celular e depende dele para parte importante da experiência.
3. Híbrido: funciona sozinho para o caminho principal, mas sincroniza preferências ou histórico quando o telefone está disponível.

Sempre que possível, prefira autonomia para o fluxo central. Um usuário pode ter relógio conectado ao Wi-Fi/LTE, telefone temporariamente distante ou pareamento instável. Fazer toda ação depender de uma mensagem instantânea ao celular cria uma experiência frágil.

Uma divisão saudável em projeto existente pode usar módulos separados:

:mobile-app
:wear-app
:core:model
:core:domain
:core:network
:core:database

Compartilhe modelos e regras de negócio que realmente são iguais. Não compartilhe componentes visuais do celular por conveniência: Compose para mobile e Compose for Wear OS resolvem superfícies diferentes. A estratégia combina bem com modularização Android em Kotlin.

Criando o módulo Wear OS

O Android Studio oferece templates específicos para Wear OS. Em um projeto existente, crie um módulo de aplicação separado, com applicationId próprio ou relacionado ao app principal conforme sua estratégia de distribuição.

No Gradle Kotlin DSL, as dependências centrais costumam incluir Activity Compose, lifecycle e bibliotecas Wear Compose. Use seu version catalog e consulte a versão estável atual:

dependencies {
    implementation(platform(libs.androidx.compose.bom))
    implementation(libs.androidx.activity.compose)
    implementation(libs.androidx.lifecycle.runtime.compose)

    implementation(libs.androidx.wear.compose.material3)
    implementation(libs.androidx.wear.compose.foundation)
    implementation(libs.androidx.wear.compose.navigation)
}

Não copie automaticamente todo o catálogo do app mobile. Cada SDK aumenta download, tempo de inicialização, memória e complexidade. Em relógios, esse orçamento é ainda menor. O mesmo raciocínio do AndroidX App Startup vale aqui: inicialize cedo apenas o que precisa existir antes da primeira interação.

Primeira tela com Compose for Wear OS

Uma tela de relógio precisa respeitar área circular, bordas, tamanho de toque e rolagem. Use componentes específicos de Wear em vez de importar componentes mobile com nomes parecidos.

Exemplo conceitual de uma lista curta de hábitos:

@Composable
fun HabitosScreen(
    habitos: List<HabitoUi>,
    onConcluir: (String) -> Unit,
) {
    AppScaffold {
        ScreenScaffold {
            TransformingLazyColumn(
                contentPadding = PaddingValues(horizontal = 10.dp),
            ) {
                item {
                    ListHeader {
                        Text("Hábitos de hoje")
                    }
                }

                items(habitos, key = { it.id }) { habito ->
                    Button(
                        onClick = { onConcluir(habito.id) },
                        label = { Text(habito.titulo) },
                        secondaryLabel = { Text(habito.status) },
                    )
                }
            }
        }
    }
}

Os nomes e assinaturas exatos dos componentes podem mudar entre releases; confirme a API da versão adotada. O princípio é o ponto importante: use scaffold e lista próprios de Wear, preserve espaço nas bordas e deixe a ação principal fácil de tocar.

Regras práticas de UI:

• mostre uma decisão principal por tela;
• use textos curtos e hierarquia visual evidente;
• não encoste informação crítica na borda circular;
• mantenha alvos de toque confortáveis;
• suporte coroa rotativa quando o fluxo tiver rolagem;
• ofereça feedback imediato após uma ação;
• evite teclado sempre que chips, voz ou opções prontas resolverem;
• teste fonte ampliada e relógios de tamanhos diferentes.

As recomendações de acessibilidade com Compose continuam válidas, mas precisam ser verificadas no dispositivo de pulso: contraste ruim e botão pequeno ficam ainda piores em movimento ou sob luz do sol.

Estado, ViewModel e coroutines

A arquitetura pode seguir o mesmo fluxo unidirecional usado no Android: repository, caso de uso, ViewModel e estado imutável. Mantenha a tela simples e cancelável.

data class HabitosUiState(
    val carregando: Boolean = true,
    val itens: List<HabitoUi> = emptyList(),
    val erro: String? = null,
)

class HabitosViewModel(
    private val repository: HabitosRepository,
) : ViewModel() {

    val uiState: StateFlow<HabitosUiState> = repository.observeHoje()
        .map { itens -> HabitosUiState(carregando = false, itens = itens) }
        .catch { emit(HabitosUiState(carregando = false, erro = "Não foi possível atualizar")) }
        .stateIn(
            scope = viewModelScope,
            started = SharingStarted.WhileSubscribed(5_000),
            initialValue = HabitosUiState(),
        )

    fun concluir(id: String) {
        viewModelScope.launch { repository.concluir(id) }
    }
}

Evite polling agressivo. Observe banco local e sincronize em momentos úteis. Para aprofundar o padrão, revise coroutines, Flow e offline-first no Android.

Tiles: informação antes de abrir o app

Tiles são superfícies roláveis acessadas diretamente no relógio. Elas funcionam bem para um resumo ou uma ação recorrente: próximo treino, hidratação, saldo de pontos, previsão ou tarefa do dia.

Use uma Tile quando o usuário precisa:

• consultar uma informação em um gesto;
• iniciar uma ação curta;
• entrar no app já em um destino específico.

Não transforme a Tile em uma tela completa. Ela deve carregar rápido, tolerar dado em cache e ter estado vazio. Salve um resumo local para renderizar mesmo sem rede e atualize somente quando necessário. Se a fonte muda por evento do servidor, uma estratégia pode receber FCM, persistir o novo estado e solicitar atualização da superfície — sem manter processo ou socket vivo o tempo todo.

Complicações: presença no mostrador

Complicações são pequenos espaços no mostrador escolhidos pelo usuário. Elas têm altíssimo valor de descoberta, mas pouco espaço. Uma complicação pode mostrar:

• número de tarefas pendentes;
• próximo evento;
• progresso de uma meta;
• estado de conexão;
• atalho para iniciar treino.

O conteúdo precisa fazer sentido isoladamente. “3” sem ícone ou contexto não ajuda. Ao tocar, abra exatamente o fluxo relacionado. Trate privacidade com cuidado: o mostrador fica visível para outras pessoas. Não exponha nome de paciente, saldo detalhado, mensagem privada ou dado sensível por padrão.

Comunicação entre relógio e celular com Data Layer

A Wearable Data Layer API permite trocar dados entre nós conectados. As principais abstrações atendem necessidades diferentes:

• MessageClient: comando ou evento pontual, sem garantia de persistência;
• DataClient / DataItem: estado que deve sincronizar e permanecer disponível;
• CapabilityClient: descobrir se outro nó oferece determinada capacidade;
• ChannelClient: transferência maior ou fluxo de dados, quando realmente necessário.

Escolha pela semântica, não pela facilidade do primeiro exemplo. Para uma preferência como “unidade = km”, um DataItem é mais adequado. Para “abrir rota agora” quando o telefone está alcançável, uma mensagem pode bastar. Para fonte de verdade de negócio, prefira API própria + banco local em cada dispositivo; a Data Layer não deve virar um backend improvisado.

suspend fun enviarAcaoAoCelular(
    nodeId: String,
    messageClient: MessageClient,
    tarefaId: String,
) {
    messageClient.sendMessage(
        nodeId,
        "/tarefas/concluir",
        tarefaId.encodeToByteArray(),
    ).await()
}

Projete para indisponibilidade: a mensagem pode falhar porque o telefone está longe. Mostre feedback honesto, persista uma ação pendente quando fizer sentido e ofereça retry. Não deixe o botão girando indefinidamente.

Sensores, exercícios e Health Services

Para experiências de saúde e exercício, use Health Services on Wear OS como camada recomendada sobre capacidades do dispositivo. Ela ajuda a trabalhar com métricas como frequência cardíaca, distância, ritmo e calorias sem acoplar o app a detalhes de cada sensor.

Cuidados essenciais:

• peça somente permissões ligadas ao recurso que o usuário ativou;
• explique por que o dado é necessário antes do dialog do sistema;
• não inicie monitoramento contínuo “por garantia”;
• diferencie dado estimado, amostra e medida disponível;
• trate ausência de sensor ou permissão negada;
• encerre sessões quando o treino terminar;
• valide requisitos e políticas do Google Play para dados de saúde.

O fluxo de permissão deve seguir o mesmo padrão contextual do guia de permissões Android. Dados de saúde exigem ainda mais minimização, segurança e clareza; este artigo trata de implementação técnica, não de diagnóstico ou orientação médica.

Trabalho em background e bateria

Um relógio tem bateria pequena, sensores ativos e conectividade variável. Arquitetura desperdiçadora aparece rápido.

Priorize:

1. cache local e UI útil offline;
2. sincronização acionada por eventos reais;
3. WorkManager para trabalho adiável;
4. constraints de rede e bateria quando aplicáveis;
5. payloads pequenos;
6. atualização de Tile/complicação somente quando o conteúdo mudar;
7. cancelamento correto de coroutines, listeners e sensores.

Não use foreground service apenas para manter o app vivo. Ele só se justifica em trabalho contínuo e visível, como sessão de exercício ou mídia, seguindo tipos e permissões corretos. Veja o guia de foreground service com Kotlin e WorkManager antes de escolher.

Navegação curta e entrada pelo contexto

No Wear OS, o usuário pode entrar por ícone, notificação, Tile, complicação ou ação de outro dispositivo. Cada entrada deve levar ao destino certo.

Mantenha rotas pequenas:

home
habito/{id}
treino/preparar
treino/ativo
configuracoes

Evite reproduzir um grafo mobile com dezenas de destinos. Se o usuário toca em “próxima tarefa” na Tile, abra a tarefa — não a home. Se uma complicação inicia treino, abra a confirmação ou contagem regressiva. A lógica é parecida com deep links e App Links: a entrada carrega intenção, e o app restaura o contexto.

Testes em emulador e relógio real

O emulador cobre tamanhos de tela, versões do sistema, rotação e caminhos básicos. Ele não substitui aparelho real para bateria, coroa, movimento, Bluetooth, sensores e uso sob luz externa.

Checklist de release:

• app abre e mostra conteúdo útil sem telefone alcançável;
• telas funcionam em formatos e tamanhos suportados;
• texto ampliado não corta a ação principal;
• rolagem por toque e coroa funciona;
• modo ambiente não deixa conteúdo incorreto;
• Tile e complicação têm loading, vazio, erro e dado antigo;
• sincronização tolera desconexão e não duplica ação;
• permissões negadas não causam crash;
• sessão com sensor termina e libera recursos;
• consumo de bateria foi observado em uso prolongado;
• deep links internos abrem o destino esperado;
• telemetria não registra dado sensível.

Use testes unitários para reducers, repositories e regras de sincronização. Testes instrumentados cobrem Activity e navegação, mas mantenha a maior parte da lógica fora dos componentes de framework. Monitore crashes e ANRs com a mesma disciplina do app mobile, conforme o guia de Crashlytics e ANR.

Publicação na Play Store

O app Wear pode ser distribuído como experiência complementar ou independente, de acordo com a configuração do produto. Antes de enviar:

• revise manifestos e recursos específicos do relógio;
• declare corretamente recursos obrigatórios e opcionais;
• forneça screenshots reais e descrição focada no wearable;
• valide login, onboarding e consentimento sem depender de tela impossível no relógio;
• revise políticas de saúde, localização, notificações e background;
• teste instalação, atualização e remoção em conjunto com o app mobile;
• confirme que a versão release usa endpoints e credenciais do ambiente correto.

Evite prometer no texto da loja uma autonomia que não existe. Se determinada função requer o celular por perto, diga isso claramente.

Erros comuns

• Copiar a UI do telefone: a tela fica densa e lenta de usar.
• Depender de conexão imediata com o celular: o fluxo quebra fora do alcance Bluetooth.
• Usar MessageClient como banco: mensagens pontuais não substituem estado persistente.
• Atualizar Tile em loop: consome bateria sem benefício proporcional.
• Coletar sensor sem sessão clara: desperdício de energia e risco de privacidade.
• Esconder ação atrás de muitas telas: o usuário desiste antes de concluir.
• Ignorar relógio real: emulador não reproduz ergonomia, movimento e autonomia.
• Importar componentes Compose mobile por engano: layout e comportamento não ficam adequados ao wearable.
• Mostrar dado sensível no mostrador: complicações são visíveis sem abrir o app.
• Inicializar todos os SDKs no boot: memória e tempo de abertura pioram em hardware limitado.

Wear OS no portfólio e na carreira Android

Um projeto Wear OS é um ótimo diferencial quando demonstra decisões que vão além de “renderizar Compose”: experiência glanceable, estado offline, comunicação resiliente, sensores, bateria e testes em hardware real.

Um case de portfólio pode incluir:

• app mobile + módulo Wear;
• Tile com resumo diário;
• complicação com progresso;
• ação offline sincronizada depois;
• sessão curta com Health Services;
• benchmark de bateria ou tempo de abertura;
• README explicando por que cada API foi escolhida.

Relacione o projeto ao roadmap de desenvolvedor Android e acompanhe vagas Kotlin e Android. Mesmo quando a vaga não cita Wear OS, saber projetar para restrições de dispositivo demonstra maturidade em arquitetura Android.

Perguntas frequentes

Preciso ter um app Android de celular para publicar no Wear OS?

Não necessariamente. Um app pode ser standalone quando o caso de uso e a configuração permitem funcionar diretamente no relógio. Entretanto, muitos produtos adotam uma experiência híbrida para facilitar onboarding, configuração e histórico detalhado.

Compose normal e Compose for Wear OS são a mesma coisa?

Eles compartilham conceitos e runtime, mas os componentes de interface são diferentes. Use as bibliotecas Wear Compose para listas, scaffold, botões e navegação adaptados ao relógio; não trate a UI mobile como reutilizável sem revisão.

Tile é a mesma coisa que widget Glance?

Não. Tiles são superfícies próprias do Wear OS, acessadas no carrossel do relógio. Widgets com Jetpack Glance vivem na tela inicial de celulares e tablets. As duas experiências valorizam informação rápida, mas usam APIs e ambientes diferentes.

Devo sincronizar tudo pela Data Layer API?

Não. Use Data Layer quando existe uma relação útil entre os dispositivos. Se relógio e celular podem acessar a mesma API com autenticação adequada, sincronização via backend e cache local costuma oferecer uma fonte da verdade mais robusta.

Wear OS funciona bem offline?

Pode funcionar, desde que o app tenha sido projetado para isso. Persista o último estado útil, aceite ações locais quando seguro, sinalize dados antigos e sincronize depois. Não assuma rede contínua nem telefone sempre por perto.

Posso coletar frequência cardíaca continuamente?

A possibilidade técnica depende do dispositivo, da API, das permissões e do caso de uso. Monitoramento contínuo tem custo de bateria e implicações de privacidade. Use Health Services, limite a coleta à experiência explícita e siga as políticas atuais da plataforma.

Conclusão e próximos passos

Desenvolver para Wear OS com Kotlin é exercitar foco. O melhor app de relógio não é o que leva mais telas ao pulso; é o que elimina etapas no momento certo. Comece por uma tarefa de alto valor, modele estado local resiliente, construa a UI com Compose for Wear OS e só depois adicione Tile, complicação, sensores ou comunicação com o telefone.

Uma sequência prática para o primeiro projeto:

1. crie o módulo Wear e uma tela com uma ação principal;
2. persista estado local e faça o fluxo funcionar offline;
3. adicione uma Tile para acesso rápido;
4. sincronize somente os dados necessários com backend ou Data Layer;
5. teste desconexão, fonte ampliada, coroa e bateria em relógio real;
6. monitore estabilidade e publique uma experiência descrita com honestidade.

Para continuar no cluster Android, revise layouts adaptativos com Compose, segurança de dados locais, WorkManager e performance no Android Studio Profiler. No pulso, cada toque, byte e despertar de CPU precisa justificar o valor entregue.