2026'da Android App Links: https:// linkleriniz hâlâ neden tarayıcıda açılıyor

myapp://item/42 gibi özel bir URI şeması kurması kolaydır ama başka bir şekilde yanlış gitmesi de kolaydır: aynı şemayı herhangi bir uygulama kaydedebilir, bu yüzden işletim sistemi linki açan uygulamanın gerçekten sizinki olduğunu garanti edemez. Bir Android App Link — tarayıcı sekmesi yerine doğrudan uygulamayı açan gerçek bir https://sizinalanadiniz.com/... URL’i — bunu çözer, ama yalnızca işletim sistemi uygulamanızın alan adına gerçekten sahip olduğunu doğrulayabilirse. Çoğu zaman böyle bir link sessizce Chrome’a düşer ve manifest tamamen doğru görünür. Eksik parça neredeyse her zaman intent filter değil, Digital Asset Links doğrulamasıdır.

Uyuşması gereken iki şey

Bir App Link, ancak birbirinden bağımsız iki parça örtüştüğünde otomatik doğrulanır: uygulamanın intent filter’ı ve alan adının kendisinin sunduğu bir JSON dosyası. Her iki tarafın da diğerini bilmemesi tam olarak amaçlanan şey — rastgele bir uygulamanın alan adınızı sahiplenmesini engelleyen şey bu.

Intent filter manifest’e gider:

<activity android:name=".MainActivity" android:exported="true">
    <intent-filter android:autoVerify="true">
        <action android:name="android.intent.action.VIEW" />
        <category android:name="android.intent.category.DEFAULT" />
        <category android:name="android.intent.category.BROWSABLE" />
        <data android:scheme="https"
              android:host="mfkapps.com"
              android:pathPrefix="/apps" />
    </intent-filter>
</activity>

android:autoVerify="true", Android’in kurulum sırasında sahipliği gerçekten kontrol etmesini tetikleyen kısımdır — sadece URL desenini eşleştirmekle kalmaz. Bunu atlarsanız filter yine linkleri eşleştirir ama yalnızca kullanıcı ayrıştırma sayfasından uygulamanızı bir kez açıkça seçtikten sonra — asla “her zaman otomatik aç” seviyesine terfi etmez.

Alan adı tarafı ise sabit, üzerinde pazarlık edilemeyen bir yolda duran statik bir dosyadır:

https://mfkapps.com/.well-known/assetlinks.json

[{
  "relation": ["delegate_permission/common.handle_all_urls"],
  "target": {
    "namespace": "android_app",
    "package_name": "com.mfk.granyn",
    "sha256_cert_fingerprints": [
      "14:6D:E9:83:C5:73:06:50:D8:EE:B9:95:2F:34:FC:64:16:A3:88:1E:22:0B:99:19:33:4B:C0:5B:0B:64:0C:1D"
    ]
  }
}]

package_name ve sha256_cert_fingerprints’in ikisi de kurulu olan tam olarak o build ile eşleşmek zorunda. Neredeyse her bozuk kurulumun asıl kırıldığı yer bu fingerprint detayı.

Her şeyi sessizce bozan fingerprint uyuşmazlığı

sha256_cert_fingerprints, kullanıcının kurduğu APK’nın imzalama sertifikasının SHA-256’sına ihtiyaç duyar — ve uygulama Play App Signing üzerinden dağıtılıyorsa bu, sizin yerel olarak imzaladığınız upload key değil, Google’ın imzalama anahtarıdır. assetlinks.json’a yanlış fingerprint’i koyun, doğrulama kullanıcının hiç görmediği bir hatayla başarısız olur; link sonsuza kadar tarayıcıda açılır ve Logcat’te bu dosyaya işaret eden hiçbir şey olmaz.

Doğru fingerprint’i yerel keystore’unuzdan değil Play Console’dan alın:

Play Console → Setup → App integrity → App signing key certificate → SHA-256

Geliştirme sırasındaki bir debug build için debug keystore’un fingerprint’ini kullanın; debug ve release’in aynı assetlinks.json’a karşı doğrulanmasını istiyorsanız ikisini de diziye ekleyin:

keytool -list -v -keystore ~/.android/debug.keystore \
  -alias androiddebugkey -storepass android -keypass android

sha256_cert_fingerprints bir dizi kabul eder, yani iki fingerprint yan yana durabilir — doğrulama, kurulu uygulamanın imzasıyla herhangi bir girdinin eşleşip eşleşmediğine bakar.

Gerçekten işe yarayıp yaramadığını doğrulamak

Android doğrulama kontrolünü kurulum sırasında çalıştırır ve sonucu önbelleğe alır, bu yüzden gerçek durumu görmenin en hızlı yolu davranıştan tahmin etmek yerine doğrudan işletim sistemine sormaktır:

adb shell pm get-app-links com.mfk.granyn

Çalışan bir kurulum alan adını verified olarak raporlar:

com.mfk.granyn:
  ID: d3a1f0b2-...
  Signatures: [14:6D:E9:...]
  Domain verification state:
    mfkapps.com: verified

legacy_failure ya da none yazıyorsa fingerprint veya JSON yanlıştır — assetlinks.json’ı düzeltin, sonra uygulamayı yeniden kurmadan yeniden kontrol zorlayın:

adb shell pm verify-app-links --re-verify com.mfk.granyn
adb shell pm get-app-links com.mfk.granyn

Doğrulama geçtikten sonra gerçek dokunma davranışını test etmek için, bir tarayıcının ya da başka bir uygulamanın yapacağı gibi bir intent tetikleyin:

adb shell am start -a android.intent.action.VIEW \
  -d "https://mfkapps.com/apps/granyn"

Uygulama hiçbir seçim penceresi olmadan açılıyorsa doğrulama çalışıyordur. Bir ayrıştırma diyaloğu görünüyorsa doğrulama başarısız olmuştur ve işletim sistemi bunu sıradan, doğrulanmamış bir link eşleşmesi olarak ele alıyordur.

Yayından sonra sessizce bozan üç şey

JSON’ın doğru içerik tipiyle ve yönlendirme olmadan sunulması gerekir. /.well-known/assetlinks.json’ı kanonik bir URL’e 301 ile yönlendiren ya da text/html olarak sunan bir CDN ya da reverse proxy, tarayıcıda düzgün görünse bile doğrulamayı başarısız kılar. İkisini de doğrudan curl ile kontrol edin:

curl -sI https://mfkapps.com/.well-known/assetlinks.json | grep -i content-type

Uygulamayı yeniden imzalamak fingerprint’i değiştirir. İmzalama anahtarını döndürmek, yerel bir keystore’dan Play App Signing’e geçmek ya da yeni bir build pipeline’ına geçmek, assetlinks.json yeni fingerprint ile güncellenene kadar önceden doğrulanmış her linki sessizce bozar. Bu, release checklist’inde bir satırı hak ediyor, çünkü hata modu — linklerin sessizce tarayıcı fallback’ine düşmesi — ne bir crash ne de bir hata raporu üretiyor.

Aynı alan adını paylaşan birden fazla uygulama birden fazla ifadeye ihtiyaç duyar. Aynı ekipteki birden fazla uygulama aynı host altındaki yolları sahipleniyorsa, assetlinks.json bir JSON dizisidir — her uygulama için kendi package_name’i ve fingerprint listesiyle bir obje. Yalnızca tek bir uygulamanın ifadesini içeren bir dosya, o alan adındaki diğer her uygulama için doğrulamayı sessizce başarısız kılar.

Bunun daha iyi bir dokunuştan fazlasında sağladığı şey

Bir alan adı doğrulandığında, aynı intent filter işletim sisteminin bir URL’i devrettiği her yerde — bir bildirim aksiyonu, bir QR kod, başka bir uygulamadan paylaşılan bir link, bir Smart Lock kimlik bilgisi akışı — uygulamanın o alan adı için varsayılan işleyici olarak davranmasını da sağlar. Hiçbiri ayrı bir kablolama gerektirmez; aynı autoVerify filtresi ve aynı assetlinks.json, işletim sistemi arkasındaki iddiaya gerçekten güvendiğinde daha fazlasını yapıyor.

Bütün bunlardan sonra uygulamaya giden bir link hâlâ tarayıcıda açılıyorsa, manifest’e tekrar dokunmadan önce pm get-app-links’i kontrol edin — pratikte kırılan taraf neredeyse hiçbir zaman intent filter değildir.