← Bloga dön
Sorun Giderme

Android App Links Doğrulanmıyor: adb ile Beş Dakikalık Teşhis

Android 12’den beri, alan adı doğrulaması başarısız olan bir App Link uygulamanız yerine tarayıcıda açılıyor — sessizce ve her cihazda aynı şekilde değil. İşte nedeni hızla bulan adb kontrol listesi ve bu vakaların çoğunun arkasındaki Play imzalama anahtarı uyuşmazlığı.

14 Ağustos 202610 dk okuma

Uygulama yüklü. Link yine de Chrome’da açılıyor.

Genellikle bir hata olarak değil, bir destek talebi olarak ortaya çıkar. Biri alan adınıza giden bir linke dokunur, uygulamanız telefonda duruyordur ama onun yerine Chrome açılır. Android 12’den beri, Android dokümantasyonuna göre, bir https linkinin uygulamanızı açması için sistemin alan adınızı yükleme anında doğrulamış olması gerekiyor — ve bu doğrulama başarısız olduğunda sessizce başarısız oluyor. Çökme yok, bildirim yok, panellerinizde hiçbir iz yok.

İki özellik bu sorunun ayıklanmasını özellikle zorlaştırıyor. Doğrulama alan adı başına yapılır; example.com doğrulanmışken promo.example.com sessizce doğrulanmamış kalabilir. Üstelik cihaz başınadır: aynı derleme Pixel’de geçip bir Samsung telefonda kalabilir — Samsung geliştirici forumlarındaki başlıklarda tekrar tekrar bildirilen bir kombinasyon. Bunu bir vaka ortasında okuyorsanız doğrudan aşağıdaki teşhise atlayın; arka plan bilgisi sonra da burada olacak.

İki alan adı, iki karar

adb · Android 16
$ adb shell pm get-app-links com.example.app
com.example.app:
Domain verification state:
example.com: verified
promo.example.com: none
Uygulamayı açarTarayıcıyı açar
Bir şey bozulana kadar kimsenin okumadığı çıktı: example.com yükleme anında doğrulamayı geçti, promo.example.com hiç geçmedi. Her karar cihaz başına ve sessizce verildi.

Yükleme anında gerçekte ne oluyor?

Uygulamanız yüklendiğinde veya güncellendiğinde Android, autoVerify ile bildirdiğiniz her alan adını okur ve her biri için https://alanadi/.well-known/assetlinks.json dosyasını indirir. Android dokümantasyonuna göre dosyanın HTTPS üzerinden, yönlendirmesiz, doğrudan 200 ve application/json içerik tipiyle dönmesi gerekir — doğrulayıcı yönlendirmeleri takip etmez. Sonuç alan adı başına önbelleğe alınır; bir alt alan adı doğrulanmışken kardeşinin doğrulanmamış kalabilmesinin nedeni budur.

Dosyanın içindeki sha256_cert_fingerprints, cihazdaki APK’yı imzalayan sertifikayla eşleşmek zorundadır. İşte bir numaralı tuzak: Play App Signing kullanıyorsanız o sertifika Google’ın uygulama imzalama anahtarıdır — sizin yükleme (upload) anahtarınız değil. Yerel keystore’unuzdan aldığınız parmak izi, elden yüklediğiniz derlemeleri kusursuz doğrular ama Play Store’dan gelen her yüklemede başarısız olur. “Benim cihazımda çalışıyor” raporlarının yarısı tam olarak buraya çıkar.

Başlamadan önce bilinmesi gereken bir özellik daha: karar önbelleğe alınır. Sunucudaki JSON’u düzeltmek, doğrulama yeniden çalışana kadar zaten başarısız olmuş telefonlarda hiçbir şey değiştirmez — neyse ki bunu zorlayabilirsiniz.

Beş dakikalık teşhis

Uygulamanın yüklü olduğu herhangi bir Android 12+ cihazı bağlayın ve bunları sırayla çalıştırın. Vakaların çoğu üçüncü adımda çözülür.

01

Doğrulama durumunu okuyun

adb shell pm get-app-links com.example.app

Bu komut, uygulamanızın bildirdiği her alan adını durumuyla birlikte yazdırır. verified el sıkışmanın geçtiği anlamına gelir; none ise doğrulayıcının o alan adını hiç onaylamadığını gösterir — kullanıcıları Chrome’a gönderen alan adı odur. Çok kullanıcılı cihazlarda çıktının altındaki kullanıcı başına bölümü de kontrol edin.

02

assetlinks.json’u doğrulayıcının indirdiği gibi indirin

curl -sI https://example.com/.well-known/assetlinks.json

Doğrudan bir 200 görmelisiniz. Herhangi bir 301 veya 302 doğrulamayı düşürür; çünkü Android dokümantasyonuna göre doğrulayıcı yönlendirmeleri takip etmez. content-type başlığının application/json olduğunu doğrulayın, sonra gövdeyi indirip paket adını ve parmak izlerini kendi gözlerinizle okuyun. /.well-known/ önündeki bot koruması veya kimlik doğrulama duvarı da başarısızlık sayılır.

03

Parmak izini Play imzalama anahtarıyla karşılaştırın

Play Console → App integrity → App signing key certificate

Play Console’daki o sayfayı açın ve oradaki SHA-256 değerini JSON’unuzun yanına koyun. Bayt bayt eşleşmek zorundalar. Dosyanızda onun yerine upload anahtarının parmak izi varsa hatayı buldunuz — Play imzalama anahtarının parmak izini ekleyin; Play Store dışında da derleme dağıtıyorsanız ikisini birden tutun.

04

Yeniden doğrulamayı zorlayın

adb shell pm verify-app-links --re-verify com.example.app

Sunucu tarafını düzelttikten sonra cihaza tekrar denemesini söyleyin. Doğrulayıcı eşzamansız çalışır; birkaç saniye bekleyin, sonra birinci adımı tekrarlayıp none değerinin verified’a dönmesini izleyin. Bazı Samsung cihazlarda durum, yeniden başlatmadan önce yerinden kımıldamıyor — Samsung geliştirici forumlarında bildirilen bir örüntü.

05

Intent’i gerçek bir dokunuş gibi ateşleyin

adb shell am start -a android.intent.action.VIEW -d "https://example.com/promo"

Uçtan uca test budur. Doğrulanmış bir alan adında uygulama seçici çıkmadan doğrudan açılır. Tarayıcı veya bir seçim ekranı görünüyorsa durum henüz dönmemiştir — düzeltmenizin başarısız olduğuna karar vermeden önce birinci adımı yeniden kontrol edin.

Vaka ortasında JSON’a gözle bakmak istemiyorsanız, link doğrulama aracımız assetlinks.json dosyanızı indirip durum kodunu, içerik tipini ve parmak izi biçimini tek seferde kontrol eder.

Her zamanki şüpheliler

Gördüğümüz raporların neredeyse tamamını beş neden kapsıyor. Solda neden, sağda çözüm.

Neden

JSON’da Play imzalama anahtarı yerine upload anahtarının parmak izi var

SHA-256 değerini Play Console → App integrity → App signing key certificate sayfasından kopyalayın. Upload anahtarıyla imzalı derlemeler de dağıtıyorsanız iki parmak izini birden tutun.

assetlinks.json yönlendirme veya 404 döndürüyor

Dosyayı bildirilen her sunucuda doğrudan /.well-known/assetlinks.json yolunda sunun. Doğrulayıcı için www ve çıplak alan adı iki ayrı alan adıdır.

Yanlış içerik tipi, örneğin text/html veya text/plain

Sunucuyu veya CDN’i bu yol için application/json gönderecek şekilde yapılandırın. Başlığı yanlış olan kusursuz bir JSON gövdesi yine de başarısız olur.

Birden fazla flavor veya paket adı var, biri dosyada eksik

Dosya bir dizidir: her paket adı için kendi parmak izleriyle ayrı bir bildirim ekleyin. Eksik flavor yalnızca o flavor’da başarısız olur; QA’de çıldırtıcı derecede rastgele görünmesinin nedeni budur.

JSON düzeltildiği halde bir Samsung cihaz none durumunda kalıyor

Bazı Samsung modellerinde gecikmeli doğrulama, Samsung geliştirici forumlarında tekrarlanan bir tema. Yeniden doğrulamayı zorlayın, ardından başka bir sonuca varmadan önce cihazı yeniden başlatın.

Android 15 ve 16 neyi değiştirdi?

İki yeni sürüm de çıtayı aynı yöne taşıdı: desteklenen yol doğrulanmış https App Links; geri kalan her şey daralmaya devam ediyor.

Android 15

Platform sürüm notlarına göre Dynamic App Links geldi: alan adı eşleştirmeleri yeni bir APK göndermeden güncellenebiliyor; bu da JSON’u düzeltmeniz ile cihazların düzeltmeyi alması arasındaki döngüyü kısaltıyor.

Android 16

Platform sürüm notlarına göre özel URI şemalarının doğrulanma ve kullanıcıya gösterilme biçimi sıkılaştırıldı. Akışınızın bir kısmı hâlâ myapp:// şemalarına dayanıyorsa bunları miras kabul edin ve giriş noktalarını doğrulanmış https linklerine taşıyın.

Akıllı linkin dürüstçe oturduğu yer

Akıllı link, bu mekanizmaların hiçbiri çalışmadan önce, sunucuda yönlendirir: biri bir Appy linkini açtığında yönlendirme cihazı okur ve Android, iOS ve masaüstü ziyaretçileri farklı hedeflere gönderir. Bu yönlendirme her planda çalışır ve cihaz üstü doğrulamaya bağlı değildir; çünkü işletim sistemi alan adınızı görmeden önce gerçekleşir.

Neyi yapmadığı konusunda net olalım: akıllı link App Links doğrulamasını atlayamaz. Yönlendirme sizin https alan adınızda biter ve uygulamanın mı tarayıcının mı açılacağına yine aynı verified-veya-none durumu karar verir. Vaka ortasında size kazandırdığı şey kontrol edilebilir bir ön kapıdır — assetlinks.json’u onarırken Android trafiğini Play Store sayfasına veya web’e yönlendirin, sonra hedefi geri çevirin; basılmış hiçbir şeye dokunmanız gerekmez, çünkü dinamik QR kodlar baskıdan sonra da düzenlenebilir kalır. Analitik de bu sırada bozuk yola ne kadar Android trafiği geldiğini gösterir.

Her durumda doğrulamayı düzeltin. Pro’daki deeplink hedefleri ve Enterprise’daki, yükleme sonrası açılışı taşıyan ertelenmiş deeplink özelliği elde olması iyi şeyler — ama çalışan bir assetlinks.json’un üstünde otururlar, onun yerine geçmezler.

Sık sorulan sorular

Aynı link neden bir cihazda çalışıp diğerinde çalışmıyor?

Doğrulama her cihazda yükleme anında çalışır; dolayısıyla her telefon kendi önbelleğe alınmış kararını taşır. Yükleme sırasındaki bir ağ aksaklığı, farklı davranan bir OEM doğrulayıcısı — Samsung geliştirici forumlarında en çok bildirilen örnek Samsung — veya JSON düzeltmenizden önce yapılmış bir yükleme, aynı derleme için farklı durumlar üretir.

Düzeltmek için uygulama güncellemesi göndermem gerekiyor mu?

Genellikle hayır. Manifest zaten alan adını autoVerify ile bildiriyorsa hata JSON dosyasında veya parmak izindedir; ikisi de sunucu tarafındadır. Dosyayı düzeltin, yeniden doğrulamayı zorlayın; yüklü derleme linkleri açmaya başlar. Güncelleme yalnızca alan adı manifeste hiç yazılmamışsa gerekir.

Akıllı link doğrulamayı atlar mı?

Hayır — aksini iddia eden her şeye şüpheyle yaklaşın. Yönlendirme hedefi sunucu tarafında seçer ama ziyaretçi https alan adınıza indiğinde işletim sistemi her zamanki doğrulama durumunu uygular. Akıllı linkin değiştirdiği şey, doğrulama bozukken ne yapabildiğinizdir — mağazaya veya web’e yönlendirmek — bozuk olup olmadığı değil.

Doğrulama kendi kendine ne zaman tekrar dener?

Android dokümantasyonuna göre doğrulayıcı başarısız alan adlarını yeniden dener ve uygulama güncellendiğinde tekrar çalışır; ancak takvim garanti değildir ve OEM’ler farklılık gösterir. Pratikte bu saatlerden günlere uzanır. adb ile yeniden doğrulamayı zorlamak veya uygulamayı yeniden yüklemek, sistemin dönmesini beklemekten hızlıdır.

Diğer yazılar

Karşılaştırma
Aug 13, 2026
9 dk okuma

AppsFlyer’ın ücretsiz planı küçüldü: Neler ücretliye taşındı, seçenekleriniz neler?

Deferred deep linking, markalı domain, Smart Banner, toplu link ve API erişimi ücretsiz Zero planından çıktı. Tam olarak ne değişti, yerine koymak ne kadara mal olur ve bir öğleden sonraya sığan geçiş yolu.

appsflyer alternative
onelink
smart links
pricing
Yazıyı oku
Rehber
Jul 16, 2026
8 dk okuma

Deeplink, Universal Link, uygulama mağazası ve web için parametre yönlendirme

Kampanya ve bağlam parametrelerini uygulama, mağaza, Universal Link ve web fallback akışlarında hedefteki sabit değerleri ezmeden koruyun.

parameter forwarding
deep linking
universal links
app stores
Yazıyı oku
Rehber
May 14, 2026
9 dk okuma

Deferred deep linking: nasıl çalışır ve ne zaman kullanılır

Orijinal link niyetini kurulumun öbür tarafına taşıyın; yeni kullanıcılar genel ana ekran yerine doğru uygulama içi ekrana düşsün.

deferred deep linking
install referrer
deep linking
mobile attribution
Yazıyı oku

Başka konular için blogda gezin.

Android trafiğine inecek bir yer verin

Cihazı sunucu tarafında algılayan ve Android ziyaretçileri uygulamaya, mağazaya veya web’e yönlendiren bir akıllı link oluşturun — hedefi sonra değiştirin, tek bir QR kodu bile yeniden basmayın.

Ücretsiz akıllı link oluştur