--- title: "Wear OS com Kotlin e Jetpack Compose em 2026: guia prático para apps de relógio" url: "https://kotlin.dev.br/blog/wear-os-kotlin-compose-guia-2026/" markdown_url: "https://kotlin.dev.br/blog/wear-os-kotlin-compose-guia-2026.MD" description: "Crie apps Wear OS com Kotlin e Compose: projeto, navegação, listas, Tiles, complicações, sensores, comunicação com celular, bateria, testes e publicação." date: "2026-09-02" author: "Karina Melo" --- # Wear OS com Kotlin e Jetpack Compose em 2026: guia prático para apps de relógio Crie apps Wear OS com Kotlin e Compose: projeto, navegação, listas, Tiles, complicações, sensores, comunicação com celular, bateria, testes e publicação. **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](https://developer.android.com/training/wearables) e as [notas de versão do Compose for Wear OS](https://developer.android.com/jetpack/androidx/releases/wear-compose). 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: | Produto | Experiência adequada no relógio | |---|---| | Fitness | iniciar, pausar e encerrar treino; acompanhar métricas | | Tarefas | ver próxima tarefa e marcar como concluída | | Mobilidade | acompanhar direção, chegada ou status da corrida | | Finanças | consultar resumo não sensível e aprovar ação com confirmação | | Mídia | play, pause, volume e faixa atual | | Hábitos | registrar água, medicação já prescrita ou check-in diário | | Comunicação | ler resumo e responder com opções rápidas | 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](/guias/guia-kotlin-android-desenvolvimento/) 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: ```text :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](/blog/modularizacao-android-kotlin-compose-2026/). ## 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: ```kotlin 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](/blog/androidx-startup-kotlin-inicializacao-app-2026/) 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: ```kotlin @Composable fun HabitosScreen( habitos: List, 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](/blog/acessibilidade-android-compose-kotlin-2026/) 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. ```kotlin data class HabitosUiState( val carregando: Boolean = true, val itens: List = emptyList(), val erro: String? = null, ) class HabitosViewModel( private val repository: HabitosRepository, ) : ViewModel() { val uiState: StateFlow = 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](/blog/coroutines-kotlin/), [Flow](/blog/kotlin-flow/) e [offline-first no Android](/blog/android-offline-first-kotlin-2026/). ## 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](/blog/fcm-notificacoes-push-android-kotlin-compose-2026/), 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. ```kotlin 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](/blog/permissoes-android-kotlin-2026/). 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](/blog/foreground-service-android-kotlin-2026/) e [WorkManager](/blog/workmanager-kotlin-android-2026/) 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: ```text 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](/blog/app-links-deep-links-android-kotlin-2026/): 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](/blog/firebase-crashlytics-anr-android-kotlin-2026/). ## 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](/carreira/roadmap-dev-android/) e acompanhe [vagas Kotlin e Android](/vagas/). 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](/blog/glance-widgets-android-kotlin-2026/) 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](/blog/layouts-adaptativos-android-compose-window-size-class-2026/), [segurança de dados locais](/blog/seguranca-dados-locais-android-kotlin-2026/), [WorkManager](/blog/workmanager-kotlin-android-2026/) e [performance no Android Studio Profiler](/blog/android-studio-profiler-cpu-memory-network-kotlin-2026/). No pulso, cada toque, byte e despertar de CPU precisa justificar o valor entregue.