Deep Links no Android com Kotlin: intent-filter, MethodChannel e EventChannel — sem pacote (Parte 2)

Seguindo a série que estou fazendo sobre deep links em Flutter, no Post 2 fui direto no ponto: implementei tudo no Android usando só código nativo.

Sem uni_links.
Sem go_router.

---

A maioria dos exemplos que a gente encontra resolve com pacote.

Funciona.

Mas quando quebra em produção, você não sabe se o problema está:

• no Android (intent-filter)
• no domínio (App Links)
• no Flutter (channel)
• ou no próprio link

E aí vira tentativa e erro.

---

Nesse post implementei:

• intent-filter no AndroidManifest.xml

  • custom scheme (fitconnect://)
  • HTTPS (App Links)
  • uso de autoVerify="true"

• MainActivity.kt

  • MethodChannel → recuperar link no cold start
  • EventChannel → receber link com app aberto
  • tratamento de onCreate vs onNewIntent

• evitar duplicação de eventos

  • dependendo do device o mesmo link chega duas vezes

• testes com adb

    adb shell am start -a android.intent.action.VIEW \
      -d "fitconnect://fitconnect.app/signup?referralCode=123"

---

Coisas que quebram fácil

• esquecer BROWSABLE
• não tratar onNewIntent
• autoVerify sem configuração no domínio
• mismatch de host/path no manifest

---

Insight

Deep link não é só abrir uma tela.

Você está lidando com:

• sistema operacional
• lifecycle da Activity
• bridge nativo ↔ Flutter
• estado do app

Se você não entende isso, debug vira tentativa e erro.

---

Fonte (post completo no Medium)

https://medium.com/p/562bb353b3b2?postPublishedType=initial

---

Repo:
https://github.com/crdornelles/fit_connect

---

Se alguém já sofreu com App Links ou autoVerify, queria ouvir como resolveu — principalmente em casos que abre o seletor em vez do app.