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, genellikle reklam SDK'ları veya analiz SDK'ları gibi SDK'lar şeklinde üçüncü taraf kodu içermesi yaygın bir uygulamadır. 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'de de SDK'lar, ana makine uygulamasının korumalı alanında yürütülür ve ana makine uygulamasının ayrıcalıklarını ve izinlerini devralır. Ayrıca ana makine uygulamasının belleğine ve depolama alanına erişebilir. Bu mimari, SDK'ların ve uygulamaların esnek bir şekilde entegre olmasını sağlarken açıklanmayan kullanıcı verilerinin toplanması ve paylaşılmasına da yol açabilir. Ayrıca, uygulama geliştiriciler üçüncü taraf SDK'ların işlevselliğinin kapsamı ve eriştiği veriler hakkında tam olarak bilgi sahibi olmayabilir. Bu durum, 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 alacaktır.

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ın kullanıcının uygulama verilerine erişimini ve bu verileri paylaşmasını 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 gizli bir ş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ı tespit edip önlemesine yardımcı olur.
• Uygulama ve SDK geliştiriciler üzerindeki gereksiz etkiyi olabildiğince en aza indirme

SDK'lar izole edilmiş bir süreçte yürütülür

Önerilen SDK Çalışma Zamanı, uyumlu SDK'ların (bu belgenin geri kalanında çalışma zamanı etkin (RE) SDK'lar olarak anılacaktır) 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ılı bilgi 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, uygulamaların SDK Çalışma Zamanı'na doğru SDK'ların 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ı yükünü ö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, derleme yapar 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 belirttiği 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 tekliftir. 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 uygun ş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 kümesine 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şir.
• 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 uygulama genelinde 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 sağlamak 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ı, özellikle yerel kod olmak üzere alternatiflerle karşılaştırıldığında sunduğu doğrulukla 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ı öneririz.

Ö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ı olduğunu biliyoruz.

SELinux

Android'de her işlem (root 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. (aktif tasarım aşamasında)
• SDK'lar yalnızca APK'larındaki kodu yükleyip yürütebilir.
• Sınırlı sayıda sistem özelliğine erişilebilir. (aktif tasarım aşamasında)

API'ler

SDK çalışma zamanında yansıtma ve API'leri çağırma işlemlerine 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'lerle ilgili tam bir teklifi gelecekteki bir güncellemede paylaşacağız.

Ayrıca, son Android platformu 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 makine 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 bellek baskısı nedeniyle işletim sistemi tarafından 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'daki 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 Runtime'ı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'nın kendisiyle iletişim kurmak için döndürdüğü Binder nesneleri (ör. SandboxedSdk) uygulama tarafından kullanıldığında DeadObjectException 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. Paylaşılan UID'ler için destek gelecekte 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 içeren kullanıcı etkileşimlerinin önlenmesine ve tespit edilmesine 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 konu aktif olarak araştırılmaktadır.

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ı veya görünüm yerine uygulamadaki bir oynatıcıda oynatıldığından oluşturma modeli diğer reklam biçimlerinden farklıdır. Hem sunucu taraflı reklam eklemeyi hem de SDK tabanlı reklam eklemeyi destekleyecek mekanizmalar üzerinde aktif olarak ç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ı 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 standartlaştırma işini ortadan kaldırırken 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ğırma işlevleriyle SDK'daki etkinliklere abone olabilir ve bu etkinlikler gerçekleştiğinde geri çağırma işlevleri 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 uygulama ile SDK arasındaki iletişimi daha düşük bir seviyede gösterir.

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

1. Bir uygulamanın SDK ile etkileşime geçebilmesi için platformdan SDK'yı yüklemesini istemesi gerekir. 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ün uygulama süreci tarafından kullanılması amaçlanmış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 bir görünümde medya oluşturmak için bir SDK alması amacıyla uygulama, requestSurfacePackage() çağrısı yapabilir ve uygun SurfaceControlViewHost.SurfacePackage öğesini getirebilir.

   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ı gerektiğini öneriyoruz. Bunun yerine, uygulama geliştiricilerin yükünü azaltmak için bu API'ler yukarıda bahsedilen oluşturulmuş API referansı tarafından bir "ara katmanda" ç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, bugün bir uygulama içinde yaptıkları gibi iletişim kuramaz. Bu nedenle, yüklenen tüm RE-SDK'ler için SandboxedSdk nesnelerinin getirilmesini sağlamak üzere SdkSandboxController içinde bir API eklendi. Bu, RE-SDK'nın SDK çalışma zamanına 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ı etkin 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ıklar olarak dahil edildiğ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 bağdaştırıcı görevi gören çalışma zamanı özellikli aracı arasında iletişim kurar.

SDK-SDK iletişimi 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 çalıştırmak ü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. Kayıt ve keşif temel öğelerinin bu kullanım alanını etkinleştirmesi 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 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. Yazma aşamasında, önerimizin geliştiricilerin yapmasını gerektirdiği bazı adımlar vardır.

Uygulama geliştiriciler

Uygulamaların, uygulama manifestlerinde RE SDK ve SDK sertifikası bağımlılıklarını belirtmeleri gerekir. Bu teklifte, bu durumu teklif boyunca uygulama geliştiricinin doğruluk 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ı üzerinden alıp 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, SDK Çalışma Zamanı'nı destekleyen veya desteklemeyen cihazlarda çalışan tek bir yapıya sahip olması önemlidir.

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ıysa bunları statik olarak bağlar. Bu durum, RE olmayan SDK'lar SDK çalışma zamanının desteklemediği işlevler gerektiriyorsa veya uygulamanın sürecinde çalışması gerekiyorsa 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 özellikli olmayan 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 desteklemek isteyebilirler. 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şleminin yapılabilmesi için HATA AYIKLAMA derlemesinin, HATA AYIKLAMA derlemesinde bulunması gereken tüm kodları ve sembolleri içermesi gerektiğini düşünsek de YAYIN derlemelerinde, uygulama mağazası tarafından dağıtılan tüm SDK'lar (RE olsun veya olmasın) isteğe bağlı olarak nihai yapıdan kaldırılabilir.

Bu konuda tasarım aşamasının başlarındayız ve ilerleyen süreçte daha fazla bilgi 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 yapılır. Hem RE hem de RE olmayan uygulamalar için tek bir derleme yapısı kullanılır. SDK geliştiriciler, 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. Android SDK sürümlerinde, özellikle de ilk birkaç sürümde kısıtlamaların sık sık değişmesini bekleyebilirsiniz.

Ayrıca, harici ve dahili test kullanıcılarının Android'in sonraki sürümü için önerilen kısıtlama grubuna katılması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 bir 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. Bu kapsamda, kullanıcı gruplarının sonraki hedefleme için oluşturulabileceği analiz SDK'ları, reklam yayınlama SDK'ları, reklamlar için kötüye kullanımı ve sahtekarlığı önleme SDK'ları, etkileşim SDK'ları ve ilişkilendirme SDK'ları yer alır 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ı hakkında 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 yalıtım yerine işlem yalıtımı seçmelisiniz?

   Ş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 yıllarca sürecek bir çaba gerektirir. 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şıma, indirme boyutunda veya alanda tasarruf sağlar mı?

   Birden fazla uygulama, aynı sürümdeki çalışma zamanı etkin 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?

   Müşteri 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 SDK çalışma zamanını 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