A General Motors acabou de admitir publicamente algo que qualquer engenheiro de software com experiência em produto já sabia: forçar o usuário a abandonar o ecossistema dele é receita para perder relevância. Segundo o Eurisko.com.br, a fabricante voltou atrás e reintegrou Android Auto e Apple CarPlay à sua próxima geração de sistema operacional, estreando nos Chevrolet Silverado e GMC Sierra 2027 nos EUA. Na minha experiência, isso não é só notícia automotiva — é um caso clássico de falha de estratégia de plataforma que se repete na indústria de software há décadas.
O que aconteceu de verdade (e o que isso ensina sobre plataformas)
A GM anunciou em 2023 que removeria Android Auto e Apple CarPlay progressivamente até 2028, apostando num sistema proprietário com integração mais profunda ao veículo — especialmente útil para EVs, com navegação inteligente para recarga, telemetria nativa e controle fino de funções de segurança.
O problema? Eles subestimaram o mesmo fator que o Windows Mobile ignorou contra o iPhone: o ecossistema do usuário não é negociável. O motorista já tem playlists, contatos, mapas favoritos, Waze, Spotify logado, mensagens sincronizadas. Trocar isso por um sistema “superior tecnicamente” não compensa — o custo de troca é alto demais.
Quando eu trabalhei com integrações de sistemas legados, vi o mesmo padrão dezenas de vezes. Equipes de produto apaixonadas por uma arquitetura “limpa” decidem quebrar compatibilidade. Seis meses depois, os usuários migram para o concorrente. Não importa se o seu código é mais elegante — importa se ele resolve o problema real.
A arquitetura por trás do infotainment moderno
Para entender por que a GM errou, vale entender o que existe debaixo do capô de um sistema multimídia automotivo hoje. Estamos falando de um sistema embarcado rodando geralmente em Linux (Yocto, AGL ou Android Automotive) ou QNX, com uma MCU secundária para funções em tempo real (CAN bus, cluster de instrumentos, ADAS).
O fluxo básico do Android Auto (que vou simplificar para o nível conceitual que interessa a um dev) é:
- O celular conecta via USB ou Wi-Fi (handoff).
- Estabelece um canal de transporte — geralmente USB-NCM (Network Control Model) ou Wi-Fi peer-to-peer.
- O carro renderiza um surface que é, na prática, um streaming de vídeo + eventos de input (toque, voz) que voltam pro celular.
<3>Sobre esse canal, roda um tunelamento de tráfego de display via Android Auto Protocol, que é fechado e proprietário, baseado em protobuf sobre TCP/UDP.
Já o CarPlay usa algo parecido, mas com iAP2 (iPod Accessory Protocol 2) sobre USB ou Wi-Fi. A Apple certifica cada head unit com um rig de testes chamado CarPlay Compliance Test — e esse processo é rigoroso. Fabricante que não passa, não roda CarPlay.
Quando a GM decidiu cortar isso, ela estava essencialmente dizendo: “vamos construir do zero toda essa camada de transporte, certificar, manter compatibilidade com dois protocolos proprietários e ainda concorrer com Google e Apple em UX”. O custo de engenharia disso é absurdo.
Por que a GM errou (e o que devs podem aprender)
Três erros clássicos de produto/platform engineering que aparecem nessa decisão:
1. Confundir controle técnico com valor de produto
Ter acesso ao CAN bus para mostrar dados de recarga em tempo real é tecnicamente interessante. Mas o motorista quer seu Waze funcionando, com seus endereços salvos. Quem resolve o problema do usuário ganha, não quem tem a arquitetura mais sofisticada.
2. Subestimar a taxa de atrito de migração
Na minha experiência, toda vez que um produto força o usuário a reaprender uma interface, a retenção cai entre 20% e 40% nos primeiros 30 dias. Em sistemas embarcados automotivos, esse número é ainda maior porque o carro é um ambiente de alto risco cognitivo — o motorista não tolera fricção.
3. Querer competir com ecossistemas estabelecidos no curto prazo
A Tesla conseguiu fazer algo parecido porque começou do zero, com base de usuários que aceitaram a troca como parte da experiência premium de comprar um Tesla. A GM tentou fazer isso com consumidores de Silverado que queriam um caminhão — não um experimento de UX.
Na Prática: simulando o handshake do Android Auto
Embora o protocolo seja proprietário e criptografado, dá pra ter uma ideia da complexidade olhando como o lado do head unit se comporta no USB. Aqui um exemplo simplificado em Python de como um sistema embarcado identifica e negocia o transporte com um dispositivo Android — usando pyusb e o descritor de função do Android Auto (RNDIS/ECM/NCM):
import usb.core
import usb.util
# Identifica dispositivo Android conectado
def find_android_device():
devs = usb.core.find(find_all=True, idVendor=0x18d1) # Google's vendor ID
for dev in devs:
if dev.idProduct in (0x2d00, 0x2d01, 0x4ee7, 0x4ee8):
return dev
return None
# Habilita o transporte NCM usado pelo Android Auto
def enable_ncm_transport(dev):
dev.set_configuration()
cfg = dev.get_active_configuration()
intf = cfg[(0, 0)]
# Claima a interface que será usada para o tunelamento
usb.util.claim_interface(dev, intf.bInterfaceNumber)
# Em produção: aqui entraria o handshake do protocolo AA
# (protobuf, SSL via OpenSSL, negociação de papéis)
print(f"[OK] Transporte NCM ativo em {dev.product}")
return True
if __name__ == "__main__":
device = find_android_device()
if device:
enable_ncm_transport(device)
else:
print("Nenhum dispositivo Android Auto detectado.")
Claro, isso é apenas a ponta do iceberg. O protocolo real usa protobuf sobre TLS, com autenticação mútua via certificados emitidos pelo Google para cada head unit aprovada. Mas a ideia geral é: o carro é apenas um terminal burro exibindo pixels calculados no celular. A “inteligência” mora no smartphone. E é exatamente por isso que tirar isso é tirar o cérebro do sistema.
Comparativo: como cada montadora está jogando
| Montadora | Abordagem | Suporte a CarPlay/AA | Risco |
|---|---|---|---|
| GM (Chevrolet, GMC) | Sistema próprio + agora híbrido | Voltou atrás, manterá | Perdeu tempo de mercado |
| Tesla | Totalmente proprietário | Não suporta | Funciona porque é nicho premium |
| Rivian | Proprietário, mas com Alexa e Spotify integrados | Não suporta | Reclamações constantes de usuários |
| Ford / Stellantis | Android Automotive nativo (Polestar, Volvo, Honda) | Sim, ambos | Menor — já entrega o que o usuário quer |
| BMW / Mercedes | Híbrido: próprio + CarPlay/AA wireless | Sim | Modelo mais equilibrado |
Percebe o padrão? Quem entrega CarPlay/AA junto com recursos nativos vence. A GM está voltando exatamente para esse modelo — a nova arquitetura vai “convidar” apps da Apple e do Google a coexistirem com funções nativas do veículo. É o movimento mais inteligente e mais tarde do que devia.
Erros Comuns que devs cometem em sistemas embarcados automotivos
- Ignorar a latência de inicialização. Carro não é celular. Se o sistema demora 8s pra ligar, o usuário vai reclamar. Cuidado com isso.
- Tratar CAN bus como se fosse uma API REST. Não é. Latência determinística, arbitration de mensagens, prioridades de 11 bits. Se você manda frame errada na hora errada, trava o cluster.
- Esquecer do ciclo automotivo. Software de carro tem ciclo de 7–10 anos, não de 18 meses. Tudo que você codar hoje vai rodar em hardware de 2015 daqui a uma década.
- Não testar em condições reais. Temperatura extrema, vibração, queda de bateria durante startup. Seu CI local nunca vai pegar isso.
- Quebrar compatibilidade sem plano de migração. Foi exatamente o que a GM fez. Aprendam: se você precisa deprecar uma API, dê 2 anos de aviso + fallback.
O que isso significa pra você, dev
Se você trabalha com mobile, web ou IA, o caso da GM é um lembrete útil: ecossistema vence arquitetura. Antes de sair cortando integrações, pergunte-se quantos por cento dos usuários realmente vão se beneficiar da quebra. Se a resposta for “técnicos que apreciam software limpo”, você está construindo para si mesmo.
Se você trabalha ou quer trabalhar com sistemas embarcados automotivos, vale estudar:
- Linux embarcado (Yocto, Buildroot)
- QNX e AGL (Automotive Grade Linux)
- Protocolos automotivos: CAN, LIN, Automotive Ethernet (100BASE-T1)
- Android Automotive OS (diferente do Android Auto!)
- Functional Safety (ISO 26262) — porque uma falha aqui mata gente
FAQ
Android Auto e Apple CarPlay vão voltar para todos os carros GM?
Por enquanto, a confirmação é para a linha 2027 nos EUA (Silverado e GMC Sierra). A expectativa do mercado é que a reversão se estenda às demais linhas até 2028, mas a GM ainda não confirmou oficialmente.
Por que a GM tentou remover esses sistemas originalmente?
A ideia era ter uma plataforma de software proprietária que controlasse funções nativas do veículo — especialmente navegação inteligente para recarga em EVs, telemetria e segurança — sem depender do smartphone.
O CarPlay/AA funciona sem internet?
Sim, a maioria das funções principais (música baixada, mapas offline, navegação básica) continua funcionando. Mas recursos como Waze em tempo real, Spotify e assistentes de voz dependem de conectividade do celular.
Qual a diferença entre Android Auto e Android Automotive?
Android Auto é um app que roda no celular e espelha pro carro. Android Automotive é um sistema operacional completo que roda nativamente no head unit — é o que Polestar, Volvo e Honda usam.
Existe código aberto relacionado a esses protocolos?
O protocolo do Android Auto é proprietário, mas projetos como o OpenAuto tentam emular um head unit para testes. Para Android Automotive, existe o AAOS reference platform no AOSP.
Gostou? Me segue no GitHub e deixa um comentário se tiver dúvida ou quiser aprofundar algum ponto — embedded, automotive, CarPlay reverso, qualquer coisa. Bora trocar ideia.