SDK Çalışma Zamanına genel bakış

Android platformu, süreç sınırlarının yanı sıra uygulama kodu için sağlam yürütme ve güvenlik sınırlarını korumak amacıyla uygulama korumalı alanı kavramını kullanır. Uygulamaların üçüncü taraf kodu içermesi yaygın bir uygulamadır. Bu kodlar genellikle reklam SDK'ları veya analiz SDK'ları gibi SDK'lar biçimindedir. Bu yeniden kullanım, uygulama geliştiricilerin uygulamalarının farklılaşmasına odaklanmasını sağlarken konu uzmanlarının çalışmalarından yararlanarak kendi başlarına kolayca yapabileceklerinin ötesinde bir ölçekte uygulama geliştirmelerine olanak tanır.

Çoğu işletim sisteminde olduğu gibi Android SDK'ları da ana makine uygulamasının korumalı alanında yürütülür ve ana makine uygulamasının ayrıcalıklarını, izinlerini, belleğine ve depolama alanına erişimini devralır. Bu mimari, SDK'ların ve uygulamaların esnek bir şekilde entegre olmasına olanak tanırken açıklanmayan kullanıcı verilerinin toplanması ve paylaşılmasına da yol açabilir. Ayrıca, uygulama geliştiriciler üçüncü taraf SDK'sının işlevselliğinin kapsamı ve eriştiği veriler hakkında tam olarak bilgi sahibi olmayabilir. Bu da uygulamalarının veri toplama ve paylaşma uygulamalarını hesaba katmayı zorlaştırır.

Android 14'te, üçüncü taraf SDK'ların SDK Çalışma Zamanı adı verilen özel bir çalışma zamanı ortamında çalışmasına olanak tanıyan yeni bir platform özelliği ekledik. SDK Çalışma Zamanı, kullanıcı verilerinin toplanması ve paylaşılmasıyla ilgili olarak aşağıdaki daha güçlü önlem ve garantileri sağlar:

• Değiştirilmiş bir yürütme ortamı
• SDK'lar için iyi tanımlanmış izinler ve veri erişim hakları

Bu tasarım hakkında mobil uygulama reklamcılığı topluluğundan geri bildirim almak için çalışıyoruz. Ayrıca, SDK Çalışma Zamanı'nın gelecekteki sürümlerini şekillendirmeye yardımcı olmak için daha geniş geliştirici topluluğundan da geri bildirim almaktan memnuniyet duyarız. Bu sürümlerde ek kullanım alanları için destek de yer alabilir.

Hedefler

Bu teklif, aşağıdaki hedeflere ulaşmayı amaçlamaktadır:

• İşlem izolasyonu ve iyi tanımlanmış API ve veri erişimi denetimi aracılığıyla, üçüncü taraf SDK'lar tarafından kullanıcıların uygulama verilerine erişim ve bu verilerin paylaşımıyla ilgili açıklanmayan durumları azaltın. İşlem izolasyonu hakkında daha fazla bilgiyi bu belgenin ayrı bir bölümünde bulabilirsiniz.
• SDK'ların benzersiz ve kalıcı tanımlayıcılara erişimini sınırlayarak kullanıcıların uygulama kullanımının üçüncü taraf SDK'lar tarafından açıklanmayan şekilde izlenmesini azaltın.
• Uygulama geliştiriciler ve son kullanıcılar üzerindeki yükü azaltarak SDK güncellemelerinin uygulamalara dağıtımını güvenli bir şekilde hızlandırın. Önerilen güvenilir SDK dağıtımı modeli hakkında daha fazla bilgiyi bu belgenin başka bir bölümünde bulabilirsiniz.
• Uygulama geliştiricilerin, uygulamalarının veri erişimi ve paylaşımı yöntemlerini daha iyi hesaba katmalarına yardımcı olur.
• SDK geliştiricilerin, JNI kodu gibi belirli güvenli olmayan dil yapılarını sınırlayarak diğer SDK'ların kurcalamasını önlemesine yardımcı olun.
• Medya gösteren uzak görünümler üzerinde tam kontrol sağlayarak reklam SDK'larının geçersiz trafiği ve reklam sahtekarlığını algılayıp önlemesine yardımcı olur.
• Uygulama ve SDK geliştiriciler üzerindeki gereksiz etkiyi olabildiğince en aza indirin.

SDK'lar izole edilmiş bir işlemde yürütülür

Önerilen SDK Çalışma Zamanı, bu belgenin geri kalanında çalışma zamanı etkin (RE) SDK'lar olarak adlandırılan uyumlu SDK'ların uygulama için ayrı bir süreçte çalışmasını sağlar. Platform, uygulamanın süreci ile SDK Çalışma Zamanı arasında iki yönlü iletişimi kolaylaştırır. Ayrıntılar için bu belgenin iletişim bölümüne bakın. RE olmayan SDK'lar, şu anda olduğu gibi uygulamanın sürecinde kalmaya devam eder. Aşağıdaki diyagramlarda bu değişiklikler gösterilmektedir:

---

SDK'lar için yeni güvenilir dağıtım modeli

SDK'nın uygulamadan ayrılması önerisi, SDK ve uygulama dağıtımı için başka bir ayrım kavramını ortaya çıkarıyor. Bu, doğru SDK'ların bir uygulamanın SDK çalışma zamanına yüklenmesini sağlamak için güvenilir bir dağıtım ve yükleme mekanizması gerektirir.

Bu mekanizma, kullanıcıları ve uygulama geliştiricileri geçersiz SDK'ların yüklenmesine karşı korurken uygulama mağazalarının, uygulama geliştiricilerden SDK dağıtımıyla ilgili yükü önemli ölçüde azaltmasını sağlar.

SDK'ların, dağıtım için bir uygulama mağazasına yüklenmeden önce artık statik olarak bağlanması ve uygulamalarıyla birlikte paketlenmesi gerekmiyor.

Bu süreç aşağıdaki adımları içerir:

1. SDK geliştiriciler, sürüm oluşturulmuş SDK'larını uygulama mağazalarına uygulamalardan ayrı olarak yükler.
2. Uygulama geliştiriciler, SDK bağımlılıklarını sürüme göre belirtir, derler ve gerçek SDK bağımlılıklarını içermeyen bir uygulama sürümü yükler.
3. Kullanıcı bu uygulamayı indirdiğinde yükleme işlemi, uygulama mağazasından indirmek için uygulamanın belirtilen SDK bağımlılıklarını kullanır.

Bu yeni dağıtım mekanizması, aşağıdaki koşullarda bağımsız SDK güncellemelerine olanak tanır:

• Yeni işlevler, yeni API'ler, mevcut API'lerde değişiklikler eklemeyen veya çalışma biçiminde değişiklikler getirmeyen, geriye dönük uyumlu hata düzeltmeleri.
• Geriye dönük uyumlu sahtekarlık algılama veya değerlendirme özelliklerinde iyileştirmeler.

Bu özelliklerin uygulanması mağazaya bağlıdır.

Aşağıdaki şemalarda, SDK dağıtımında önerilen değişiklikler gösterilmektedir:

---

SDK'ların ve uygulamaların oluşturulma, çalıştırılma ve dağıtılma şeklindeki değişiklikler

Bu, esnek bir SDK Çalışma Zamanı ve dağıtım teknolojisi için ilk öneridir. Aşağıdaki bölümlerde, şu geniş kategorilerde bir dizi değişiklik önerilmektedir:

• Erişim: İzinler, bellek, depolama
• Yürütme: Diller, çalışma zamanı değişiklikleri, yaşam döngüsü, medya oluşturma
• İletişimler: Uygulamadan SDK'ya ve SDK'dan SDK'ya
• Geliştirme: Bu modelde nasıl oluşturulur, hata ayıklanır ve test edilir?
• Dağıtım: Android, uygulamalar ve SDK'ların farklı sürümlerinde nasıl dağıtım, güncelleme ve geri alma yapılır?

Bu belgede, sık sorulan soruları yanıtlamanıza yardımcı olacak bir SSS bölümü de yer almaktadır.

Bu, ilk tasarım önerisidir ve ekosistemin bazı üyeleri için önemli bir değişiklik olabileceğinin farkındayız. Bu nedenle, geri bildirimlerinizi aktif olarak talep ediyor ve sorun izleyici üzerinden göndermenizi rica ediyoruz.

Erişim

Bir sistemin gizliliğini yönetmek, farklı tarafların farklı kaynaklara nasıl erişebileceğini yönetmek anlamına gelir. Gizlilikle ilgili değer önerimizi karşılamak için uygulamalara, SDK'lara ve kullanıcı verilerine erişim modelinin, olası hassas verilere açıklanmayan erişimi önlemek amacıyla en az ayrıcalık ilkesine uyacak şekilde güncellenmesini öneriyoruz.

SDK izinleri

Ayrı bir işlem olarak SDK Çalışma Zamanı, kullanıcının uygulamaya verdiği izinleri devralmak yerine kendi iyi tanımlanmış izin grubuna sahip olur. Reklamlarla ilgili SDK'lar tarafından kullanılan izinlerle ilgili ön araştırmalara dayanarak, SDK Çalışma Zamanı'ndaki SDK'ların varsayılan olarak aşağıdaki izinlere erişebilmesini öneriyoruz:

• INTERNET: Bir web hizmetiyle iletişim kurabilmek için internete erişim.
• ACCESS_NETWORK_STATE: Ağlarla ilgili bilgilere erişin.
• READ_BASIC_PHONE_STATE: Telefonun durumuyla ilgili bilgilere (ör. mobil ağ türü) erişim.
• Uygulamalar arası tanımlayıcılara erişim gerektirmeden temel reklamcılık özellikleri sağlayan gizliliği korumaya yönelik API'lere erişim izinleri.
• AD_ID: Reklam kimliği isteğinde bulunma özelliği. Bu durum, uygulamanın bu izne erişimiyle de sınırlanır.

Şu anda, hem gizlilik hem de kullanılabilirlik açısından son kullanıcılar üzerindeki etkiyi sınırlayarak ek izinlerin yetkilendirilip yetkilendirilmeyeceğini ve nasıl yetkilendirileceğini araştırıyoruz. Bu izin grubu tarafından karşılanamayan kullanım alanları hakkında geri bildirimde bulunmanızı rica ederiz.

Bellek

SDK Çalışma Zamanı, kendi sürecine sahip olması nedeniyle kendi yalıtılmış bellek alanına sahip olur. Bu yapı, varsayılan olarak SDK'nın uygulamanın bellek alanına erişimini engeller ve uygulama da benzer şekilde SDK'nın bellek alanına erişemez. En az ayrıcalık ilkesine uygun kalmak için bu varsayılan davranışı korumanızı öneririz.

Depolama

Bu teklif, SDK'ların normal çalışması için depolama alanına erişme ihtiyacını dengelemeyi ve kalıcı depolama alanı kullanarak uygulamalar arası ve süreçler arası izlemeyi en aza indirmeyi amaçlamaktadır. Depolama alanına erişim şekliyle ilgili aşağıdaki güncellemeyi öneriyoruz:

• Bir uygulama, SDK'larının depolama alanına doğrudan erişemez ve bunun tersi de geçerlidir.
• Cihazın harici depolama alanına SDK'lar tarafından erişilemez.
• Her SDK çalışma zamanında, tüm SDK'ların erişebileceği depolama alanı ve belirli bir SDK'ya özel depolama alanı bulunur.

Mevcut depolama modeli gibi, depolama alanının kendisi de boyutta rastgele sınırlara sahip olmayacak. SDK'lar, öğeleri önbelleğe almak için depolama alanını kullanabilir. Bu depolama alanı, SDK etkin olarak çalışmadığında düzenli aralıklarla temizlenir.

Yürütme

Uygulamalar, SDK'lar ve kullanıcılar arasında gizli bir sistem sağlamak için yürütme bağlamının (kod biçimleri, dil yapıları, erişilebilir API'ler ve sistem verileri) bu gizlilik sınırlarını güçlendirmesi veya en azından bunları atlatma fırsatları sunmaması gerekir. Aynı zamanda, zengin platforma ve SDK'ların şu anda sahip olduğu çalışma zamanı özelliklerinin çoğuna erişimi korumak istiyoruz. Bu dengeyi kurmak için çalışma zamanı ortamında bir dizi güncelleme yapmayı öneriyoruz.

Kod

Android kodu (uygulamalar ve SDK'lar), Kotlin veya Java ile yazılmış olmasına bakılmaksızın ağırlıklı olarak Android çalışma zamanı (ART) tarafından yorumlanır. ART'nin zenginliği ve sunduğu dil yapıları, alternatiflerle (özellikle yerel kod) karşılaştırıldığında sunduğu doğrulama özelliğiyle birlikte işlevsellik ve gizlilik arasında uygun bir denge kuruyor gibi görünüyor. Çalışma zamanı özelliğinin etkin olduğu SDK kodunun, JNI erişimini desteklemek yerine yalnızca Dex bayt kodundan oluşmasını öneriyoruz.

Özel olarak paketlenmiş SQLite kullanımı gibi, yerel kod kullanımı nedeniyle Android SDK'nın yerleşik SQLite sürümü gibi bir alternatifle değiştirilmesi gereken kullanım alanlarının olduğunu biliyoruz.

SELinux

Android'de her işlem (kök olarak çalışanlar dahil) belirli bir SELinux bağlamıyla çalışır. Bu sayede çekirdek, sistem hizmetlerine, dosyalara, cihazlara ve diğer işlemlere erişim kontrolünü yönetebilir. Çoğu SDK kullanım alanını korumaya çalışırken gizlilik korumalarının atlatılmasını en aza indirmek için SDK Çalışma Zamanı'nda sistem dışı bir uygulamanın SELinux bağlamından aşağıdaki güncellemeleri önermekteyiz:

• Sınırlı sayıda sistem hizmetine erişilebilir. (etkin tasarım altında)
• SDK'lar yalnızca APK'larındaki kodu yükleyip yürütebilir.
• Sınırlı sayıda sistem özelliğine erişilebilir. (etkin tasarım altında)

API'ler

SDK çalışma zamanında yansıtma ve API'leri çağırma işlemlerinin kullanılmasına izin verilir. Ancak bir SDK'nın yansıtma kullanmasına veya başka bir çalışma zamanı etkin SDK'da API'leri çağırmasına izin verilmez. Yasaklanan API'lerin tam listesini gelecekteki bir güncellemede paylaşacağız.

Ayrıca, son Android platform sürümleri, gizliliği artırmak için kalıcı tanımlayıcılara erişimi giderek daha fazla kısıtlamaktadır. SDK Çalışma Zamanı için, uygulamalar arası izleme amacıyla kullanılabilecek tanımlayıcılara erişimin daha da sınırlandırılmasını öneriyoruz.

SDK Çalışma Zamanı API'lerine yalnızca ön planda çalışan uygulamalardan erişilebilir. SdkSandboxManager API'lerine arka plandaki uygulamalardan erişmeye çalışmak SecurityException hatasının oluşmasına neden olur.

Son olarak, RE-SDK'lar, kullanıcı bildirimlerini herhangi bir zamanda göndermek için bildirim API'lerini kullanamaz.

Yaşam döngüsü

Uygulama SDK'ları şu anda ana uygulamasının yaşam döngüsünü takip ediyor. Bu nedenle, uygulama ön plana girdiğinde veya ön plandan çıktığında, kapatıldığında ya da işletim sistemi tarafından bellek baskısı nedeniyle zorla durdurulduğunda uygulamanın SDK'ları da aynı şekilde davranıyor. Uygulama SDK'larını farklı bir işleme ayırma önerimiz aşağıdaki yaşam döngüsü değişikliklerini içerir:

• Uygulama, kullanıcı veya işletim sistemi tarafından sonlandırılabilir. SDK çalışma zamanı hemen ardından otomatik olarak sonlandırılır.

• SDK çalışma zamanı, işletim sistemi tarafından bellek baskısı veya bir SDK'da işlenmemiş bir istisna nedeniyle sonlandırılabilir.

  Android 14'te bir uygulama ön plandayken SDK Çalışma Zamanı yüksek öncelikli olarak çalışır ve sonlandırılma olasılığı düşüktür. Uygulama arka plana geçtiğinde SDK çalışma zamanı sürecinin önceliği düşer ve sonlandırmaya uygun hale gelir. Uygulama ön plana geri dönse bile SDK Çalışma Zamanı işleminin önceliği düşük kalır. Bu nedenle, uygulamanın aksine bellek baskısı altında sonlandırılması çok olasıdır.

  Android 14 ve sonraki sürümlerde, uygulama ve SDK çalışma zamanının işlem öncelikleri aynıdır. Uygulama ve SDK Çalışma Zamanı için ActivityManager.RunningAppProcessInfo.importance işlem öncelikleri yaklaşık olarak aynı olmalıdır.

  SDK Çalışma Zamanı, uygulama çalışırken sonlandırılırsa (ör. SDK'da işlenmemiş bir istisna varsa) daha önce yüklenen tüm SDK'lar ve uzak görünümler de dahil olmak üzere SDK Çalışma Zamanı durumu kaybolur. Uygulama geliştirici, SDK Çalışma Zamanı'nın sonlandırılmasıyla ilgili sorunları aşağıdaki yöntemlerden herhangi birini kullanarak çözebilir:

  • Teklif, SDK Çalışma Zamanı'nın sonlandırılmasının ne zaman gerçekleştiğini tespit etmek için uygulama geliştiricilere ilgili yaşam döngüsü geri çağırma yöntemleri sunar.
  • SDK Çalışma Zamanı, reklamlar gösterilirken sonlandırılırsa reklamlar beklendiği gibi çalışmayabilir. Örneğin, görünümler ekranda donabilir ve artık etkileşimli olmayabilir. Uygulama, kullanıcı deneyimini etkilemiyorsa reklam görünümünü kaldırabilir.
  • Uygulama, SDK'ları yüklemek ve reklam istemek için başka bir girişimde bulunabilir.
  • Android 14'te, SDK Çalışma Zamanı SDK'lar yüklüyken sonlandırılırsa ve uygulama geliştirici yukarıda belirtilen yaşam döngüsü geri çağırma yöntemlerini kaydetmemişse uygulama varsayılan olarak sonlandırılır. Yalnızca SDK'ları yüklemiş olan uygulama işlemleri sonlandırılır ve normal şekilde çıkılır.
  • SDK ile iletişim kurmak için SDK tarafından döndürülen Binder nesneleri (ör. SandboxedSdk) uygulama tarafından kullanıldığında DeadObjectException istisnası oluşturur.

  Bu yaşam döngüsü modeli, gelecekteki güncellemelerde değişebilir.

  Sürekli hatalar olması durumunda uygulama geliştirici, SDK olmadan sorunsuz bir şekilde işlevleri azaltmayı planlamalı veya SDK uygulamanın temel işlevi için kritik öneme sahipse kullanıcıyı bilgilendirmelidir. Bu uygulama-SDK etkileşimi hakkında daha fazla bilgi için bu belgenin iletişim bölümüne bakın.

RE olmayan SDK'lar, yerleştirilmiş uygulamalarında kullanılabilen standart işletim sistemi temel öğelerini (hizmetler, etkinlikler ve yayınlar dahil) kullanmaya devam edebilirken RE SDK'ları kullanamaz.

Özel durumlar

Aşağıdaki durumlarda destek sunulmaz ve beklenmedik davranışlar görülebilir:

• Birden fazla uygulama aynı UID'yi paylaşıyorsa SDK Çalışma Zamanı düzgün çalışmayabilir. Gelecekte paylaşılan UID'ler için destek eklenebilir.
• Birden fazla işlemi olan uygulamalarda SDK'nın yüklenmesi ana işlemde yapılmalıdır.

Medya oluşturma

Metin, resim ve video gibi içerikleri uygulamaya özel bir görünümde oluşturmak için SDK'lar vardır. Bunu gerçekleştirmek için, SDK'nın medyayı SDK çalışma zamanı içinden oluşturacağı ancak medyanın uygulamaya özel bir görünümde oluşturulmasına izin vermek için SurfaceControlViewHost API'sini kullanacağı bir uzaktan oluşturma yaklaşımı öneriyoruz. Bu, SDK'ya bu medyayı kullanıcı için gizli bir şekilde oluşturma olanağı sunarken oluşturulan medyayla ilgili geçersiz veya sahtekarlık amaçlı kullanıcı etkileşimlerini önlemeye ve tespit etmeye yardımcı olur.

SDK tarafından değil, uygulama tarafından oluşturulan doğal reklamlar, SDK Çalışma Zamanı'ndaki SDK'lar tarafından desteklenir. Sinyal toplama ve reklam öğesi getirme süreci, yerel olmayan reklamlarla tutarlı bir şekilde gerçekleşir. Bu, aktif olarak araştırılan bir konudur.

Yayın içi video reklamlar, bir video ile yayın içinde yayınlanan ve bir uygulamadaki oynatıcıda gösterilen reklamlardır. Video, SDK'daki bir oynatıcıda veya görünümde değil, uygulamadaki bir oynatıcıda oynatıldığından oluşturma modeli diğer reklam biçimlerinden farklıdır. Hem sunucu taraflı reklam ekleme hem de SDK tabanlı reklam eklemeyi destekleyecek mekanizmalar üzerinde çalışıyoruz.

Sistem durumu

SDK Çalışma Zamanı'nın son kullanıcı cihazları üzerindeki sistem sağlığı etkisini en aza indirmek için çalışıyoruz ve bunu yapmanın yollarını tasarlıyoruz. Ancak, sistem sağlığı üzerindeki etkisi nedeniyle Android (Go sürümü) gibi çok sınırlı sistem kaynaklarına sahip bazı giriş seviyesi Android 14 cihazlar SDK Çalışma Zamanı'nı desteklemeyecektir. Yakında SDK Çalışma Zamanı'nı başarılı bir şekilde kullanmak için gereken minimum koşulları paylaşacağız.

İletişim

Uygulamalar ve SDK'lar şu anda aynı süreçte çalıştığından aralarındaki iletişim engellenmez ve aracısızdır. Ayrıca Android, iletişim SDK'larla başlayıp sonlansa bile uygulamalar arası iletişime izin verir. Bu serbest iletişim modeli, çeşitli kullanım alanlarını mümkün kılarken aynı zamanda uygulamalar arasında ve uygulamalar içindeki ve arasındaki SDK'lar arasında açıklanmayan veri paylaşımı olasılığını da ortaya çıkarır. Bu iletişim modelinde, söz konusu iletişimin değeri ile belirtilen hedeflerimizin gerçekleştirilmesi arasında bir denge kurmak için aşağıdaki güncellemeleri öneriyoruz.

Uygulamadan SDK'ya

Uygulama ile SDK arasındaki arayüz, SDK'ya yönelik en yaygın iletişim yoludur. SDK'nın API'si ise kullanıcıya yönelik farklılaşma ve yeniliğin büyük bir kısmının bulunduğu yerdir. Burada SDK'ların yenilik yapma ve farklılaşma yeteneğini korumayı amaçlıyoruz. Bu nedenle, önerimiz SDK'ların uygulamalara API'ler sunmasını ve uygulamaların tüm bu yeniliklerden yararlanabilmesini sağlar.

SDK Çalışma Zamanı'nın süreç sınırı yapısı göz önüne alındığında, API çağrılarını ve yanıtlarını veya geri çağırmalarını uygulama ile SDK arasındaki bu sınır boyunca taşımak için uygulama içinde erişilebilen bir sıralama katmanı oluşturmayı öneriyoruz. Bu sıralama katmanının arayüzünün SDK geliştiricileri tarafından tanımlanmasını ve geliştireceğimiz resmi açık kaynaklı derleme araçlarıyla oluşturulmasını öneriyoruz.

Bu öneriyle, uygulama ve SDK geliştiricilerin standart hale getirilmiş sıralama çalışmalarını ortadan kaldırmayı, SDK geliştiricilere esneklik sağlamayı ve gizlilik hedeflerimize ulaşmak için SDK kodunun SDK çalışma zamanında çalışmasını sağlamayı amaçlıyoruz. Bu yolu izlememiz durumunda, API tanım dilinin ve araçlarının sizin katkılarınızla tasarlanması gerekecektir.

Genel etkileşim modeli aşağıdaki gibi olur:

• Uygulama, arayüz üzerinden SDK'yı çağırarak geri çağırmaları iletir.
• SDK, istekleri eşzamansız olarak karşılar ve geri çağırmaları kullanarak yanıt verir.
• Bu, herhangi bir yayıncı-abone modeline genellenebilir. Yani bir uygulama, geri çağırmalarla SDK'daki etkinliklere abone olabilir ve bu etkinlikler gerçekleştiğinde geri çağırmalar tetiklenir.

Bu teklifin yeni süreçler arası yapısının bir sonucu olarak, yönetilmesi gereken iki süreç yaşam döngüsü vardır: biri uygulamanın kendisi, diğeri ise SDK çalışma zamanı için. Önerimiz, bu sürecin mümkün olduğunca otomatikleştirilmesini ve uygulama ile SDK geliştiriciler üzerindeki etkisinin en aza indirilmesini amaçlamaktadır. Aşağıdaki şemada, değerlendirdiğimiz bir yaklaşım gösterilmektedir:

Platform, uygulamaların SDK'ları SDK çalışma zamanı sürecine dinamik olarak yüklemesi, sürecin durumundaki değişiklikler hakkında bildirim alması ve SDK çalışma zamanına yüklenen SDK'larla etkileşimde bulunması için yeni API'ler sunar.

Önceki şekildeki grafik, marshaling katmanı olmadan daha düşük bir seviyede uygulama-SDK iletişimini gösterir.

Uygulama, SDK Çalışma Zamanı sürecinde çalışan SDK ile aşağıdaki adımlar aracılığıyla iletişim kurar:

1. Bir uygulama, SDK ile etkileşime geçmeden önce platformdan SDK'yı yüklemesini isterdi. Sistemin bütünlüğünü sağlamak için uygulamalar, manifest dosyalarında yüklemeyi planladıkları SDK'ları belirtir ve yalnızca bu SDK'ların yüklenmesine izin verilir.

   Aşağıdaki kod snippet'inde açıklayıcı bir API örneği verilmiştir:

   SdkSandboxManager.loadSdk(String sdkName, Bundle data, Executor executor,
       OutcomeReceiver<SandboxedSdk, LoadSdkException> receiver)
   

2. SDK'ya yüklendiği bildirilir ve arayüzünü döndürür. Bu arayüz, uygulama süreci tarafından kullanılmak üzere tasarlanmıştır. Arayüzün işlem sınırı dışında paylaşılması için IBinder nesnesi olarak döndürülmesi gerekir.

   Bağlı hizmetler kılavuzunda, IBinder sağlamanın farklı yolları açıklanmaktadır. Hangi yöntemi seçerseniz seçin, SDK ile arayan uygulama arasında tutarlı olmalıdır. Diyagramlarda örnek olarak AIDL kullanılır.

3. SdkSandboxManager, IBinder arayüzünü alır ve uygulamaya geri döndürür.

4. Uygulama, IBinder değerini alır ve SDK arayüzüne yayınlayarak işlevlerini çağırır:

   IBinder binder = sandboxSdk.getInterface();
   ISdkInterface mySdkInterface = ISdkInterface.Stub.asInterface(binder);
   mySdkInterface.something();
   

Uygulama, aşağıdaki adımları uygulayarak SDK'dan alınan medyayı da oluşturabilir:

1. Bu belgenin medya oluşturma bölümünde açıklandığı gibi, bir uygulamanın görünümde medya oluşturmak için SDK alabilmesi için requestSurfacePackage() çağrısı yapıp uygun SurfaceControlViewHost.SurfacePackage öğesini getirmesi gerekir.

   Aşağıdaki kod snippet'inde açıklayıcı bir API örneği verilmiştir:

   SdkSandboxManager.requestSurfacePackage(String sdkName, Bundle extraParams,
           Executor executor,
           OutcomeReceiver<Bundle, RequestSurfacePackageException> receiver)
   

2. Uygulama daha sonra döndürülen SurfacePackage öğesini SurfaceView içindeki setChildSurfacePackage API'si aracılığıyla SurfaceView içine yerleştirebilir.

   Aşağıdaki kod snippet'inde açıklayıcı bir API örneği verilmiştir:

   SurfaceView.setChildSurfacePackage(SurfacePackage surfacePackage)
   

IBinder ve requestSurfacePackage() API'lerinin genel olması ve uygulamalar tarafından doğrudan çağrılmaması önerilir. Bunun yerine, uygulama geliştiricilerin yükünü azaltmak için bu API'ler yukarıda bahsedilen oluşturulmuş API referansı tarafından "ara katman" olarak çağrılır.

SDK'dan SDK'ya

Aynı uygulamadaki iki SDK'nın genellikle iletişim kurması gerekir. Bu durum, belirli bir SDK'nın bileşen SDK'larından oluşacak şekilde tasarlanması ve farklı taraflara ait iki SDK'nın, çağıran uygulamanın isteğini karşılamak için birlikte çalışması gerektiğinde ortaya çıkabilir.

Dikkate alınması gereken iki temel durum vardır:

• Her iki SDK'da da çalışma zamanı özelliği etkinleştirildiğinde. Bu durumda, her iki SDK da tüm korumalarıyla birlikte SDK Çalışma Zamanı'nda çalışır. SDK'lar, uygulamalarda olduğu gibi iletişim kuramaz. Bu nedenle, tüm yüklenen RE-SDK'lar için SandboxedSdk nesnelerinin getirilmesini sağlamak üzere SdkSandboxController içinde bir API eklendi. Bu, bir RE-SDK'nın SDK Çalışma Zamanı'nda yüklenen diğer SDK'larla iletişim kurmasına olanak tanır.
• Yalnızca bir SDK'nın çalışma zamanı etkinleştirildiğinde.
  • Arayan SDK uygulamada çalışıyorsa bu, uygulamanın SDK Çalışma Zamanı içindeki ikinci SDK'yı çağırmasından farklı değildir.
  • Çağıran SDK SDK Çalışma Zamanı'nda çalışıyorsa bu öneri, uygulamadan SDK'ya bölümünde açıklanan IBinder kullanılarak bir yöntemin kullanıma sunulmasını önerir. Bu yöntemde, uygulamadaki kod, sağlanan geri çağırmalarla dinler, işler ve yanıt verir.
  • Çalışma zamanı özellikli olmayan reklam SDK'ları kendilerini kaydedemeyebilir. Bu nedenle, iş ortaklarının veya uygulama SDK'larının uygulama için doğrudan bağımlılık olarak eklendiği ve kaydı işleyen bir aracı SDK oluşturulmasını öneriyoruz. Bu aracı SDK, çalışma zamanı özellikli olmayan SDK'lar veya diğer uygulama bağımlılıkları ile adaptör görevi gören çalışma zamanı özellikli aracı arasında iletişim kurar.

SDK'lar arası iletişim için özellik grubu aşağıdaki kategorilere ayrılmıştır:

• SDK çalışma zamanında SDK'lar arası iletişim (en yeni geliştirici önizlemesinde kullanılabilir)
• Uygulama ile SDK Çalışma Zamanı arasında SDK-SDK iletişimi (en yeni geliştirici önizlemesinde kullanılabilir)
• Uyumlulaştırma için görünümlerin ve uzaktan oluşturmanın işleyiş şekli (geliştirme aşamasındaki teklif)

Temel öğeler tasarlanırken aşağıdaki kullanım alanları dikkate alınmaktadır:

1. Uyumlulaştırma ve teklifli sistem. Birçok reklam SDK'sı, SDK'nın bir reklam gösterimi için çeşitli diğer SDK'ları çağırdığı (uyumlulaştırma) veya açık artırma yürütmek üzere sinyal toplama için çağırdığı (teklifli sistem) bir uyumlulaştırma ya da teklifli sistem özelliği sunar. Genellikle koordine eden SDK, koordine eden SDK tarafından sağlanan bir bağdaştırıcı aracılığıyla diğer SDK'ları çağırır. Yukarıdaki temel öğeler göz önüne alındığında, koordinasyon SDK'sı (RE veya değil) normal çalışma için tüm RE ve RE olmayan SDK'lara erişebilmelidir. Bu bağlamda oluşturma, aktif olarak araştırılan bir konudur.
2. Özellik keşfetme Bazı SDK ürünleri, SDK'lar arası keşif süreciyle uygulama geliştiriciye sunulan nihai özellik setini belirleyen daha küçük SDK'lardan oluşur. Bu kullanım alanının etkinleştirilmesi için kayıt ve keşif temel öğelerinin kullanılması beklenmektedir.
3. Yayıncı abonelik modelleri. Bazı SDK'lar, diğer SDK'ların veya uygulamaların geri çağırma yoluyla bildirim almak için abone olabileceği merkezi bir etkinlik yayıncısı olacak şekilde tasarlanmıştır. Yukarıdaki temel öğeler bu kullanım alanını desteklemelidir.

Uygulamadan uygulamaya

Uygulamalar arası iletişimde, iletişim kuran iki süreçten en az biri çalışma zamanı etkin bir SDK'dır ve açıklanmayan veri paylaşımı için olası bir vektördür. Sonuç olarak, SDK Çalışma Zamanı, istemci uygulaması dışındaki herhangi bir uygulama veya başka bir uygulama için oluşturulan başka bir SDK çalışma zamanındaki SDK'larla doğrudan iletişim kanalı oluşturamaz. Bu durum aşağıdaki şekillerde sağlanır:

• SDK, manifestinde <service>, <contentprovider> veya <activity> gibi bileşenleri tanımlayamaz.
• SDK, ContentProvider yayınlayamaz veya yayın gönderemez.
• SDK, başka bir uygulamaya ait bir etkinliği başlatabilir ancak Intent'te gönderilebilecekler sınırlıdır. Örneğin, bu amaca ekstralar veya özel işlemler eklenemez.
• SDK yalnızca izin verilen hizmetlerin bir listesiyle başlatılabilir veya bu hizmetlere bağlanabilir.
• SDK yalnızca sistemin bir alt kümesine ContentProvider (ör. com.android.providers.settings.SettingsProvider) erişebilir. Bu durumda, elde edilen verilerde tanımlayıcılar yoktur ve kullanıcının parmak izini oluşturmak için kullanılamaz. Bu kontroller, ContentProvider'a ContentResolver kullanılarak erişilmesi için de geçerlidir.
• SDK yalnızca korumalı yayın alıcılarının bir alt kümesine (ör. android.intent.action.AIRPLANE_MODE) erişebilir.

Manifest etiketleri

SDK yüklendiğinde PackageManager, SDK'nın manifestini ayrıştırır ve yasaklanmış manifest etiketleri varsa SDK'yı yükleyemez. Örneğin, SDK <service>, <activity>, <provider> veya <receiver> gibi bileşenleri tanımlamayabilir ve manifest dosyasında <permission> öğesini bildirmeyebilir. Yüklenemeyen etiketler SDK Çalışma Zamanı'nda desteklenmez. Yükleme sırasında hata vermeyen ancak sessizce yok sayılan etiketler, gelecekteki Android sürümlerinde desteklenebilir.

Bu kontroller, SDK paketini oluşturmak için SDK'nın kullandığı derleme zamanı araçları tarafından ve uygulama mağazasına yükleme sırasında da uygulanabilir.

Etkinlik desteği

SDK Çalışma Zamanı ortamındaki SDK'lar, manifest dosyalarına etkinlik etiketi ekleyemez ve Context.startActivity kullanarak kendi etkinliklerini başlatamaz. Bunun yerine platform, istendiğinde SDK'lar için etkinlikler oluşturur ve bunları SDK'larla paylaşır.

Platform etkinliği android.app.Activity türündedir. Platform etkinliği, uygulamanın etkinliklerinden biriyle başlar ve uygulama görevinin bir parçasıdır. FLAG_ACTIVITY_NEW_TASK desteklenmiyor.

Bir SDK'nın etkinliği başlatması için SdkSandboxActivityHandler türünde bir örnek kaydetmesi gerekir. Bu örnek, uygulama etkinliği başlatmak için SdkSandboxManager::startSdkSandboxActivity(Activity, IBinder) işlevini çağırdığında etkinlik oluşturma hakkında bildirim göndermek için kullanılır.

Etkinlik isteğinde bulunma akışı aşağıdaki grafikte gösterilmektedir.

Geliştirme

Bu teklifteki temel ilkelerden biri, geliştirici ekosistemi üzerindeki etkiyi mümkün olduğunca en aza indirmektir. Bu teklif, geliştiricilere RE uygulamaları ve SDK'ları yazmak, oluşturmak ve hatalarını ayıklamak için kapsamlı bir geliştirme araçları seti sunar. Bu teklifin bütünlüğünü sağlamak için RE uygulamalarının ve SDK'larının yapılandırılma, oluşturulma ve derlenme şekliyle ilgili bazı değişiklikler yapıldı.

Yazma

Android Studio ve ilgili araçlar, SDK Çalışma Zamanı'nı destekleyecek şekilde güncellenecek. Böylece, geliştiricilerin RE uygulamalarını ve SDK'larını doğru şekilde yapılandırması sağlanacak. Ayrıca, eski veya desteklenmeyen çağrılar, uygun durumlarda daha yeni alternatifleriyle güncellenecek. Önerimiz, yazma aşamasında geliştiricilerin bazı adımları uygulamalarını gerektirir.

Uygulama geliştiriciler

Uygulamaların, uygulama manifestlerinde RE SDK ve SDK sertifikası bağımlılıklarını belirtmeleri gerekir. Önerimizde, bu durumu teklif boyunca uygulama geliştiriciden alınan doğru bilgi kaynağı olarak ele alıyoruz. Örneğin:

• Ad: SDK'nın veya kitaplığın paket adı.
• Ana sürüm: SDK'nın ana sürüm kodu.
• Sertifika özeti: SDK derlemesinin sertifika özeti. Belirli bir derleme için SDK geliştiricinin bu değeri ilgili uygulama mağazası aracılığıyla edinip kaydetmesini öneririz.

Bu yalnızca RE olup olmadığına bakılmaksızın uygulama mağazası üzerinden dağıtılan SDK'lar için geçerlidir. SDK'ları statik olarak bağlayan uygulamalar, mevcut bağımlılık mekanizmalarını kullanır.

Geliştiriciler üzerindeki etkiyi en aza indirme hedefimiz doğrultusunda, SDK çalışma zamanını destekleyen bir hedef API düzeyi belirtildikten sonra uygulama geliştiricilerin, bu derlemenin SDK çalışma zamanını destekleyen veya desteklemeyen cihazlarda çalışmasına bakılmaksızın yalnızca tek bir derlemeye sahip olması gerekir.

SDK geliştiricileri

Önerdiğimiz tasarımda, RE SDK geliştiricilerinin manifestte SDK veya kitaplık öğesini temsil eden yeni bir öğeyi açıkça bildirmesi gerekir. Ayrıca, bağımlılıkla benzer bir değer grubu ve küçük bir sürüm sağlanmalıdır:

• Ad: SDK'nın veya kitaplığın paket adı.
• Ana sürüm: SDK'nın ana sürüm kodu.
• Alt sürüm: SDK'nın alt sürüm kodu.

RE SDK geliştiricilerinin derleme zamanı bağımlılıkları olarak başka RE SDK'ları varsa bunları, uygulama geliştiricinin aynı bağımlılığı bildireceği şekilde bildirmeleri gerekir. RE SDK'ları, RE olmayan SDK'lara bağlı olduğunda bunları statik olarak bağlar. RE olmayan SDK'lar, SDK çalışma zamanının desteklemediği işlevler gerektiriyorsa veya uygulamanın sürecinde çalışması gerekiyorsa bu durum, derleme sırasında ya da test geçişleri sırasında tespit edilecek sorunlara yol açabilir.

RE SDK geliştiricileri, Android 12 veya önceki sürümler gibi RE'nin etkinleştirilmediği cihazları desteklemeye devam etmek isteyebilir. Ayrıca, dokümanın Sistem Sağlığı bölümünde belirtildiği gibi, çok sınırlı sistem kaynaklarına sahip giriş seviyesi Android 14 cihazları da desteklemeye devam etmek isteyebilir. SDK geliştiricilerinin RE ve RE olmayan ortamları desteklemek için tek bir kod tabanını koruyabilmesini sağlamak üzere yaklaşımlar üzerinde çalışıyoruz.

Derlemeler

Uygulama geliştiriciler

Uygulama geliştiricilerin derleme adımında çok az değişiklik yaşayacağını tahmin ediyoruz. Yerel olarak dağıtılan veya uygulama mağazası üzerinden dağıtılan (RE veya değil) SDK bağımlılıklarının, linting, derleme ve oluşturma işlemleri için makinede bulunması gerekir. Android Studio'nun, normal kullanımda bu ayrıntıları uygulama geliştiriciden soyutlamasını ve mümkün olduğunca şeffaf hale getirmesini öneriyoruz.

Hata ayıklama için DEBUG derlemesinin, hata ayıklama için gerekli tüm kodları ve sembolleri içermesi gerektiğini düşünsek de RELEASE derlemelerinde, uygulama mağazalarında dağıtılan tüm SDK'lar (RE olsun veya olmasın) son yapıdan isteğe bağlı olarak kaldırılabilir.

Bu özellik için tasarım aşamasının başlarındayız. Gelişmeleri sizlerle paylaşacağız.

SDK geliştiricileri

SDK'nın RE olmayan ve RE sürümlerinin dağıtım için tek bir yapıda oluşturulabilmesini sağlamak üzere çalışıyoruz. Bu sayede, uygulama geliştiricilerin bir SDK'nın RE ve RE olmayan sürümleri için ayrı derlemeleri desteklemesi gerekmez.

Uygulamalarda olduğu gibi, uygulama mağazası üzerinden dağıtılan bağımlılık SDK'larının da linting, derleme ve oluşturma işlemleri için makinede bulunması gerekir. Android Studio'nun bu işlemi sorunsuz bir şekilde kolaylaştırmasını bekliyoruz.

Test

Uygulama geliştiriciler

Teklifimizde açıklandığı gibi, uygulama geliştiriciler uygulamalarını Android 14 çalıştıran cihazlarda normal şekilde test edebilecek. Uygulamalarını oluşturduktan sonra, bu uygulamalar bir RE cihazına veya emülatöre yüklenebilir. Bu yükleme işlemi, SDK'lar uzak bir SDK deposundan veya derleme sistemindeki önbellekten alınmış olsa da cihaz ya da emülatör için SDK Çalışma Zamanı'na doğru SDK'ların yüklenmesini sağlar.

SDK geliştiricileri

SDK geliştiriciler genellikle geliştirmelerini test etmek için cihazlarda ve emülatörlerde şirket içi test uygulamalarını kullanır. Önerimiz bu durumu değiştirmez. Uygulama içi doğrulama, yukarıda uygulama geliştiriciler için belirtilen adımlarla aynı şekilde gerçekleştirilir. Hem RE hem de RE olmayan uygulamalar için tek bir derleme yapısı kullanılır. SDK geliştiricileri, SDK Runtime'da olsun veya olmasın kodlarında adım adım ilerleyebilecek. Ancak gelişmiş hata ayıklama ve profil oluşturma araçlarında bazı sınırlamalar olabilir. Bu, aktif olarak araştırılan bir konudur.

Dağıtım

Uygulamaların SDK'larından ayrılması, SDK'ların uygulama mağazalarında dağıtılmasına olanak tanımıştır. Bu özellik, herhangi bir dağıtım kanalına özel olmayıp platform genelinde kullanılabilir.

Bu durum, şu avantajları sunar:

• SDK'ların kalitesini ve tutarlılığını sağlama
• SDK geliştiricileri için yayınlama sürecini kolaylaştırın.
• Yüklü uygulamalarda SDK'daki kritik yama güncellemelerinin kullanıma sunulmasını hızlandırın.

SDK dağıtımını desteklemek için bir dağıtım kanalının aşağıdaki özellikleri desteklemesi gerekir:

• SDK geliştiriciler, SDK'larını mağazada veya platformda yayınlayabilir ve bakım işlemleri gerçekleştirebilir.
• SDK'ların ve uygulamaların bütünlüğünü sağlayın ve bağımlılıklarını giderin.
• SDK'ları cihazlara tutarlı, güvenilir ve yüksek performanslı bir şekilde dağıtın.

Zaman içinde değişen kısıtlamalar

SDK çalışma zamanındaki kodun karşılaştığı kısıtlamaların, Android'in sonraki sürümleriyle birlikte değişmesini bekliyoruz. Uygulama uyumluluğunu sağlamak için bu kısıtlamaları belirli bir SDK düzeyinde ana hat modülü güncellemeleriyle değiştirmeyeceğiz. Belirli bir targetSdkVersion ile ilişkili davranış, uygulama mağazası politikası aracılığıyla söz konusu targetSdkVersion desteği sonlandırılana kadar korunur ve targetSdkVersion desteğinin sonlandırılması, uygulamalara kıyasla daha hızlı gerçekleşebilir. Kısıtlamaların, Android SDK sürümlerinde, özellikle de ilk birkaç sürümde sık sık değişmesini bekleyebilirsiniz.

Ayrıca, harici ve dahili test kullanıcılarının Android'in bir sonraki sürümü için önerilen kısıtlamaların uygulandığı bir gruba katılmalarına olanak tanıyan bir erken erişim mekanizması oluşturuyoruz. Bu sayede, kısıtlama grubunda önerilen değişikliklerle ilgili geri bildirim alabilir ve güven kazanabiliriz.

SSS

1. Reklamcılıkla ilgili SDK nedir?

   Reklamla ilgili SDK, reklamverene ait olmayan uygulamalarda kullanıcıların ticari amaçlı mesajlarla hedeflenmesinin herhangi bir bölümünü kolaylaştıran SDK'dır. Buna, kullanıcı gruplarının sonraki hedefleme için oluşturulabileceği analiz SDK'ları, reklam yayınlama SDK'ları, reklamlara yönelik kötüye kullanımı ve sahtekarlığı önleme SDK'ları, etkileşim SDK'ları ve ilişkilendirme SDK'ları dahildir ancak bunlarla sınırlı değildir.

2. SDK Çalışma Zamanı'nda herhangi bir SDK çalıştırılabilir mi?

   İlk olarak reklamla ilgili SDK'lara odaklanılsa da gizliliğe önem veren ve yukarıda belirtilen koşullar altında çalışabileceğine inanan reklamla ilgili olmayan SDK'ların geliştiricileri, SDK Çalışma Zamanı'nda çalışan SDK'larıyla ilgili geri bildirim paylaşabilir. Ancak SDK Çalışma Zamanı, tüm SDK tasarımlarıyla uyumlu olacak şekilde tasarlanmamıştır. Belgelenen sınırlamaların ötesinde, SDK Çalışma Zamanı, barındıran uygulama ile gerçek zamanlı veya yüksek işleme hızlı iletişim gerektiren SDK'lar için uygun olmayabilir.

3. Neden bir işlemin Java tabanlı çalışma zamanı içinde izolasyon yerine işlem izolasyonu tercih edilir?

   Şu anda Java tabanlı çalışma zamanı, Android kullanıcıları için istenen gizlilik güvenceleri açısından gerekli güvenlik sınırlarını kolayca sağlamamaktadır. Böyle bir şeyi uygulamaya çalışmak, başarı garantisi olmadan muhtemelen çok yıllık bir çaba gerektirecektir. Bu nedenle, Özel Korumalı Alan, iyi bilinen ve uzun süredir kullanılan bir teknoloji olan işlem sınırlarını kullanır.

4. SDK'ları SDK Çalışma Zamanı sürecine taşımak indirme boyutu veya alan tasarrufu sağlar mı?

   Birden fazla uygulama, aynı sürümdeki çalışma zamanının etkin olduğu SDK'larla entegre edilirse indirme boyutu ve disk alanı azalabilir.

5. SDK'lar, SDK çalışma zamanında uygulamanın arka plana gitmesi gibi hangi tür uygulama yaşam döngüsü etkinliklerine erişebilir?

   SDK çalışma zamanını, istemci uygulamasının uygulama düzeyindeki yaşam döngüsü etkinlikleri (ör. uygulamanın arka plana gitmesi, uygulamanın ön plana gitmesi) hakkında bilgilendirmek için tasarım desteği üzerinde aktif olarak çalışıyoruz. Tasarım ve örnek kod, yakında yayınlanacak bir geliştirici önizlemesinde paylaşılacaktır.

Sizin için önerilenler

• Not: JavaScript kapalıyken bağlantı metni gösterilir.
• SDK Runtime geliştirici kılavuzu