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

Android platformu, uygulama kodu için işlem sınırlarına paralel olarak güçlü 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 biçiminde üçüncü taraf kodu içermesi yaygın bir uygulamadır. Bu yeniden kullanım, uygulama geliştiricilerin uygulamalarının farklılığına odaklanmasına olanak tanır. Ayrıca, uygulama geliştiriciler, konu uzmanlarının çalışmalarından yararlanarak uygulamalarını kendi başlarına kolayca yapabileceklerin ötesine taşıyabilir.

Çoğu işletim sisteminde olduğu gibi Android'de de SDK'lar ana uygulamanın korumalı alanında yürütülür ve ana uygulamanın ayrıcalıklarını ve izinlerini, ayrıca ana uygulamanın belleğine ve depolama alanına erişimi devralır. Bu mimari, SDK'ların ve uygulamaların esnek bir şekilde entegre edilmesini sağlarken, açıklanmayan kullanıcı verilerinin toplanmasına ve paylaşılmasına da olanak tanır. Ayrıca uygulama geliştiriciler, üçüncü taraf SDK'ları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ı adlı ö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ı

Mobil uygulama reklamcılığı topluluğundan bu tasarımla ilgili geri bildirim almak için aktif olarak çalışıyoruz. Ayrıca, daha geniş geliştirici topluluğundan gelecekteki SDK Runtime sürümlerini şekillendirmeye yardımcı olacak geri bildirimler de bekliyoruz. Bu geri bildirimler, ek kullanım alanları için destek de dahil olmak üzere gelecekteki sürümlerde dikkate alınacaktır.

Hedefler

Bu teklifin amacı aşağıdaki hedeflere ulaşmaktır:

• İşlem izolasyonu ve iyi tanımlanmış API ve veri erişimi denetimi aracılığıyla, kullanıcının uygulama verilerine üçüncü taraf SDK'lar tarafından gizli olarak erişilmesini ve paylaşılmasını azaltın. Bu dokümanın ayrı bir bölümünde iş izolasyonu hakkında daha fazla bilgi edinebilirsiniz.
• Benzersiz ve kalıcı tanımlayıcıların SDK'lar tarafından erişilmesini sınırlayarak kullanıcının uygulama kullanımını üçüncü taraf SDK'lar tarafından gizli olarak izlenmesini azaltın.
• Uygulama geliştiricilerin ve son kullanıcıların ü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 dokümanın başka bir bölümünde bulabilirsiniz.
• Uygulama geliştiricilerin, uygulamalarının veri erişimi ve paylaşım yöntemlerini daha iyi açıklamalarına yardımcı olun.
• JNI kodu gibi belirli güvenli olmayan dil yapılarını sınırlayarak SDK geliştiricilerin diğer SDK'lar tarafından yapılan müdahaleleri önlemesine yardımcı olun.
• Medya görüntüleyen uzak görüntüler ü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ştiricileri üzerindeki olumsuz etkiyi mümkün olduğunca en aza indirin.

SDK'lar izole bir işlemde çalışır.

Önerilen SDK Çalışma Zamanı, uyumlu SDK'ların (bu dokümanın geri kalanında çalışma zamanında etkin (RE) SDK'lar olarak anılacaktır) uygulama için ayrı bir işlemde çalışmasını sağlar. Platform, uygulamanın işlemi ile SDK Çalışma Zamanı arasında iki yönlü iletişimi kolaylaştırır. Ayrıntılar için bu dokümanın iletişimler bölümüne bakın. RE dışı SDK'lar, uygulamanın sürecinde bugün olduğu gibi kalır. 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ı için önerilen bu yöntem, SDK ve uygulama dağıtımı için başka bir ayrım konseptini de teşvik etmektedir. Teklifimizde, uygulamanın SDK çalışma zamanında doğru SDK'ların yüklendiğinden emin olmak için güvenilir bir dağıtım ve yükleme mekanizması gereklidir. Bu sayede kullanıcılar ve uygulama geliştiriciler geçersiz SDK'ların yüklenmesine karşı korunurken uygulama mağazaları, uygulama geliştiricilerin SDK dağıtımıyla ilgili yükünü önemli ölçüde azaltabilir.

Artık SDK'ların dağıtılmak üzere bir uygulama mağazasına yüklenmeden önce uygulamalarıyla birlikte statik olarak bağlanıp paketlenmesi gerekmeyecek. Bunun yerine aşağıdaki işlem gerçekleşir:

1. SDK geliştiricileri, sürümlü SDK'larını uygulamalardan ayrı olarak uygulama mağazalarına yükleyebiliyordu.
2. Uygulama geliştiriciler, SDK bağımlılıklarını sürüme göre belirtebilir, derleyebilir ve asıl SDK bağımlılıklarını içermeyen bir uygulama sürümü yükleyebilir.
3. Bir kullanıcı bu uygulamayı indirdiğinde yükleme işlemi, uygulamanın belirtilen SDK bağımlılıkları için uygulama mağazasından indirme işlemini başlatabilir.

Bu yeni dağıtım mekanizması, SDK geliştiricilerin SDK'larında çalışmayı durdurmayan değişiklikler (yani API'lerde veya anlamlarında değişiklik yapmadan) yapmalarına ve uygulama geliştiricilerin müdahalesi olmadan cihazlara dağıtmalarına olanak tanır. Uygulama geliştiricilerin uygulamalarını yeni SDK'larla yeniden oluşturmasını veya son kullanıcıların uygulamalarını güncellemesini beklemek zorunda kalmadan, uygulamayı bozmayan bu SDK değişiklikleri dağıtılabilir veya geri alınabilir. Uygulama geliştiricilerin, uyumsuzluk yaratan değişiklikleri güncellemesi yine de gerekir. Ancak SDK geliştiricileri, uyumsuzluk yaratmayan en son değişiklikleri ve düzeltmeleri daha hızlı ve daha tutarlı bir şekilde daha fazla kullanıcıya sunabilir. Bu sayede, sürüm desteği en aza indirilebilir.

Aşağıdaki şemalar, SDK dağıtımında önerilen değişiklikleri göstermektedir:

---

SDK'ların ve uygulamaların derlenmesi, çalıştırılması ve dağıtılmasıyla ilgili 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, aşağıdaki geniş kategorilerde bir dizi değişiklik önerilmektedir:

• Erişim: İzinler, bellek, depolama alanı
• 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 derleme, hata ayıklama ve test etme
• Dağıtım: Android sürümleri, uygulamalar ve SDK'lar arasında dağıtım, güncelleme ve geri alma işlemleri

Bu dokümanda, sık sorulan soruları yanıtlamaya yardımcı olacak bir SSS bölümü de yer almaktadır.

Bu, ilk tasarım önerisidir ve bu değişikliğin ekosistemin bazı üyeleri için önemli olabileceğinin farkındayız. Bu nedenle, geri bildiriminizi aktif olarak istiyoruz ve bunu sorun takipçisi üzerinden yapmanızı rica ediyoruz.

Erişim

Bir sistemin gizliliğini yönetmek, farklı tarafların farklı kaynaklara nasıl erişebileceğini yönetmeyi ifade eder. Gizlilik değer teklifimizi karşılamak için uygulamalara, SDK'lara ve kullanıcı verilerine erişim modelini, potansiyel olarak hassas verilerin açıklanmadan erişilmesini önlemek için en az ayrıcalık ilkesine uygun olacak şekilde güncellemenizi öneririz.

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ın kullandığı izinlerle ilgili ön araştırmaya dayanarak, SDK Çalışma Zamanı'ndaki SDK'ların varsayılan olarak aşağıdaki izinlere erişebileceğini öneriyoruz:

• INTERNET: Web hizmetiyle iletişim kurabilmek için internete erişim.
• ACCESS_NETWORK_STATE: Ağlarla ilgili bilgilere erişme.
• READ_BASIC_PHONE_STATE: Telefon durumuyla ilgili bilgilere (ör. mobil ağ türü) erişme
• Uygulamalar arası tanımlayıcılara erişmeye gerek kalmadan temel reklamcılık özelliklerini sağlayan gizliliği korumaya yönelik API'lere erişim izinleri.
• AD_ID: Reklam kimliğini isteyebilir. Bu durum, uygulamanın bu izne erişimine de bağlıdır.

Şu anda ek izinlerin yetkilendirilip yetkilendirilmeyeceğini ve nasıl yetkilendirileceğini araştırıyoruz. Bu sayede, son kullanıcılar üzerindeki etkiyi hem gizlilik hem de kullanılabilirlik açısından sınırlandıracağız. Bu izin grubuyla karşılanamayan kullanım alanları hakkında geri bildirim istiyoruz.

Bellek

SDK Runtime, kendi işlemine sahip olduğu için kendi izole bellek alanına sahiptir. Bu yapı, varsayılan olarak SDK'nın uygulamanın bellek alanına erişimini reddeder ve uygulama da benzer şekilde SDK'nın bellek alanına erişemez. En az ayrıcalık ilkesine uymak için bu varsayılan davranışı korumanızı öneririz.

Depolama

Bu öneri, SDK'ların normal çalışması için depolamaya erişme ihtiyacını dengelemek ve kalıcı depolama alanını kullanarak uygulama ve işlemler arası izlemeyi en aza indirmek amacıyla hazırlanmıştır. Depolama alanına erişme şekliyle ilgili olarak aşağıdaki güncellemeyi öneriyoruz:

• Uygulamalar, SDK'larının depolama alanına doğrudan erişemez ve SDK'lar da uygulama depolama alanlarına erişemez.
• SDK'lar cihazın harici depolama alanına erişemez.
• Her SDK çalışma zamanında hem tüm SDK'ların erişebileceği depolama alanı hem de belirli bir SDK'ya özel depolama alanı bulunur.

Mevcut depolama modeli gibi, depolama alanının boyutu da rastgele sınırlara sahip olmayacak. SDK'lar, öğeleri önbelleğe almak için depolama alanını kullanabilir. SDK etkin olarak çalışmadığında bu depolama alanı düzenli olarak 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ı atlatmaya yönelik 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 öneriyoruz.

Kod

Android kodu (uygulamalar ve SDK'lar), Kotlin veya Java ile yazılmış olsun çoğunlukla Android Runtime (ART) tarafından yorumlanır. ART'ın zenginliği ve sunduğu dil yapıları, özellikle yerel koda kıyasla sunduğu doğrulanabilirlikle birlikte işlevsellik ve gizliliği uygun şekilde dengeliyor. Çalışma zamanında etkinleştirilen SDK kodunun, JNI erişimini desteklemek yerine yalnızca Dex bayt kodundan oluşmasını öneririz.

Özel paketlenmiş SQLite kullanımı gibi kullanım alanlarının olduğunun farkındayız. Bu kullanım alanlarında, yerel kod kullanımı nedeniyle Android SDK'sının yerleşik SQLite sürümü gibi bir alternatifle değiştirilmesi gerekir.

SELinux

Android'de her işlem (root olarak çalışanlar dahil) belirli bir SELinux bağlamında çalışır. Bu sayede çekirdek, sistem hizmetlerine, dosyalara, cihazlara ve diğer işlemlere erişim denetimini yönetebilir. Gizlilik korumalarının atlatılmasını en aza indirirken SDK kullanım alanlarının çoğunu korumaya çalışmaktayız. Bu nedenle, sistem dışı bir uygulamanın SELinux bağlamında SDK Runtime için aşağıdaki güncellemeleri öneriyoruz:

• 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ıma ve API çağırma işlemlerine izin verilir. Ancak bir SDK'nın, çalışma zamanında etkinleştirilmiş başka bir SDK'da yansıma kullanmasına veya API'leri çağırmasına izin verilmez. Yasaklanmış API'lerin tam önerisini gelecekteki bir güncellemede paylaşacağız.

Ayrıca, son Android platform sürümlerinde gizliliği iyileştirmek için kalıcı tanımlayıcılara erişimi giderek daha fazla kısıtlanmıştır. SDK çalışma zamanı için uygulamalar arası izleme için kullanılabilecek tanımlayıcılara erişimi daha da sınırlamayı öneriyoruz.

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

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

Yaşam döngüsü

Uygulama SDK'ları şu anda ana uygulamalarının yaşam döngüsünü takip eder. Yani uygulama ön plana girdiğinde veya ön plandan çıktığında, kapandığında ya da bellek baskısı nedeniyle işletim sistemi tarafından zorla durdurulduğunda uygulamanın SDK'ları da aynı şekilde davranır. Bir uygulamanın SDK'larını farklı bir sürece 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ı, bellek baskısı veya örneğin bir SDK'da işlenmemiş bir istisna nedeniyle işletim sistemi tarafından 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 gittiğinde SDK Runtime işleminin önceliği düşer ve işlem sonlandırılmaya uygun hale gelir. Uygulama ön plana geri dönse bile SDK Runtime işleminin önceliği düşük kalır. Sonuç olarak, uygulamaya kıyasla bellek baskısı altında sonlandırılma olasılığı çok yüksektir.

  Android 14 ve sonraki sürümlerde, uygulamanın ve SDK çalışma zamanının işlem öncelikleri uyumludur. Uygulamanın ActivityManager.RunningAppProcessInfo.importance işleminin ve SDK çalışma zamanının önceliği 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üntüler dahil olmak üzere SDK Çalışma Zamanı durumu kaybedilir. Uygulama geliştirici, SDK Çalışma Zamanı'nın feshedilmesiyle ilgili olarak aşağıdaki yöntemlerden herhangi birini kullanabilir:

  • Teklif, SDK Çalışma Zamanı'nın ne zaman sonlandırıldığını algılamak 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üntüler ekranda donabilir ve artık etkileşimli olmayabilir. Uygulama, kullanıcı deneyimini etkilemiyorsa reklam görüntülemesini kaldırabilir.
  • Uygulama, SDK'ları yüklemek ve reklam istemek için başka bir deneme yapabilir.
  • Android 14'te, SDK Çalışma Zamanı SDK'lar yüklüyken sonlandırılırsa ve uygulama geliştiricisi yukarıda belirtilen yaşam döngüsü geri çağırma yöntemlerini kaydetmediyse uygulama varsayılan olarak sonlandırılır. Yalnızca SDK yüklemiş olan uygulama işlemleri sonlandırılır ve normal şekilde çıkar.
  • SDK tarafından kendisiyle iletişim kurmak için döndürülen bağlayıcı nesneler (ör. SandboxedSdk), uygulama tarafından kullanılırsa bir DeadObjectException oluşturur.

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

  Sürekli hata olması durumunda uygulama geliştirici, SDK olmadan sorunsuz bir şekilde işlevlerin devre dışı bırakılmasını planlamalı veya SDK'nın uygulamanın temel işlevi için önemli olması durumunda kullanıcıyı bilgilendirmelidir. Bu uygulama-SDK etkileşimi hakkında daha fazla bilgi için bu dokümanın iletişim bölümüne bakın.

RE dışı SDK'lar, yerleşik uygulamalarında kullanılabilen standart OS temel öğelerini (hizmetler, etkinlikler ve yayınlar dahil) kullanmaya devam edebilir. RE SDK'ları ise bunu yapamaz.

Özel durumlar

Aşağıdaki durumlar desteklenmez ve beklenmedik davranışlara neden olabilir:

• 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 uygulama tarafından belirtilen bir görünümde oluşturan SDK'lar vardır. Bunu başarmak için SDK'nın medyayı SDK Çalışma Zamanı'ndan oluşturacağı ancak medyanın uygulama tarafından belirtilen bir görünümde oluşturulmasına izin vermek için SurfaceControlViewHost API'sini kullanacağı uzaktan oluşturma yaklaşımını öneriyoruz. Bu, SDK'ya bu medyayı kullanıcı için gizli bir şekilde oluşturma olanağı sunarken, oluşturulan medyayla geçersiz veya sahtekarlık amaçlı kullanıcı etkileşimlerinin önlenmesine ve tespit edilmesine yardımcı olur.

SDK tarafından değil, uygulama tarafından oluşturulan yerel reklamlar, SDK Çalışma Zamanı'ndaki SDK'lar tarafından desteklenir. Sinyal toplama ve reklam öğesi getirme işlemi, yerel olmayan reklamlarda tutarlı bir şekilde gerçekleşir. Bu konu, aktif olarak incelenmektedir.

Yayın içi video reklamlar, bir uygulamadaki oynatıcıda gösterilen videoyla birlikte yayın içi olarak yayınlanan reklamlardır. Videonun SDK'daki bir oynatıcıda veya görünümde değil, uygulamadaki bir oynatıcıda oynatılması nedeniyle oluşturma modeli diğer reklam biçimlerinden farklıdır. Hem sunucu tarafı reklam eklemeyi hem de SDK tabanlı reklam eklemeyi destekleyen mekanizmaları etkin bir şekilde araştırıyoruz.

Sistem durumu

SDK Çalışma Ortamı'nın son kullanıcı cihazları üzerindeki sistem sağlığı üzerindeki etkisini en aza indirmeye çalışıyoruz ve bunu yapmanın yollarını tasarlıyoruz. Ancak Android (Go sürümü) gibi çok sınırlı sistem kaynaklarına sahip bazı giriş seviyesi Android 14 cihazlar, sistem sağlığı üzerindeki etkisi nedeniyle SDK Çalışma Ortamı'nı desteklemeyecektir. SDK Runtime'ı başarıyla kullanmak için gereken minimum koşulları yakında 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şlar ve SDK'larla sona erse bile uygulama içi iletişime izin verir. Bu serbest iletişim modeli, çeşitli kullanım alanları sağlarken aynı zamanda uygulamalar ve uygulamalardaki ve uygulamalar arasındaki SDK'lar arasında açıklanmayan veri paylaşımı olasılığını da sunar. Bu iletişim modelinde, söz konusu iletişimin değeri ile belirtilen hedeflerimizin gerçekleşmesi arasında bir denge kurmak amacıyla 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. Kullanıcılara yönelik farklılaşma ve yeniliklerin çoğu, SDK'nın API'sinde bulunur. SDK'ların yenilik ve farklılaşma özelliklerini korumaya çalışıyoruz. Sonuç olarak, önerimiz SDK'ların API'leri uygulamalara göstermesini sağlar ve uygulamaların bu yeniliklerden yararlanmasını sağlar.

SDK Runtime'ın işlem sınırı yapısı göz önüne alındığında, API çağrılarını ve yanıtlarını ya da geri çağırma işlevlerini uygulama ile SDK arasındaki bu sınırda taşımak için uygulama içinden erişilebilen bir düzenleme katmanı oluşturmayı öneriyoruz. Bu düzenleme katmanının arayüzünün SDK geliştiricileri tarafından tanımlanmasını ve geliştireceğimiz resmi açık kaynak derleme araçları tarafından oluşturulmasını öneriyoruz.

Bu teklifle, uygulama ve SDK geliştiricilerinin standart olarak gerçekleştirdiği marshaling çalışmasını ortadan kaldırmayı, SDK geliştiricilerine esneklik sağlamayı ve gizlilik hedeflerimizi gerçekleştirmek için SDK kodunun SDK çalışma zamanında çalışmasını sağlamayı amaçlıyoruz. Bu yolu izlersek API tanımı dili ve araçlarının sizin katkılarınızla tasarlanması gerekir.

Genel etkileşim modeli aşağıdaki gibidir:

• Uygulama, geri çağırma işlevlerini ileterek SDK'yı arayüz üzerinden çağırır.
• SDK, istekleri eşzamansız olarak karşılar ve geri çağırma işlevlerini kullanarak yanıt verir.
• Bu, herhangi bir yayıncı-abone modeli için genelleştirilebilir. 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 önerinin yeni işlemler arası yapısının bir sonucu olarak, yönetilmesi gereken iki işlem yaşam döngüsü vardır: biri uygulamanın kendisi, diğeri ise SDK çalışma zamanı içindir. Teklifimiz, uygulama ve SDK geliştiricileri üzerindeki etkiyi en aza indirerek bu sürecin mümkün olduğunca fazlasını otomatikleştirmeyi amaçlamaktadır. Aşağıdaki şemada, üzerinde düşündüğümüz 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şim kurması için yeni API'ler sunacaktı.

Önceki şekildeki grafik, uygulama ile SDK arasındaki iletişimi, marshaling katmanı olmadan daha düşük bir düzeyde göstermektedir.

Uygulama, SDK Runtime 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 ister. Sistem bütünlüğünü sağlamak için uygulamalar, yüklemeyi planladıkları SDK'ları manifest dosyalarında belirtir ve yüklenmesine izin verilen tek SDK'lar bunlar olur.

   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, yüklendiğine dair bilgilendirilir ve arayüzünü döndürür. Bu arayüz, uygulama işlemi tarafından kullanılacak şekilde tasarlanmıştır. Arayüzün işlem sınırının dışında paylaşılması için IBinder nesnesi olarak döndürülmesi gerekir.

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

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

4. Uygulama, IBinder öğesini alır ve SDK arayüzüne yayınlar, 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 medya da oluşturabilir:

1. Bu dokümanın medya oluşturma bölümünde açıklandığı gibi, bir uygulamanın bir görünümde medya oluşturmak için SDK alması amacıyla requestSurfacePackage()'yi çağırıp uygun SurfaceControlViewHost.SurfacePackage'ı 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 SurfaceView API'si aracılığıyla döndürülen SurfacePackage öğesini SurfaceView içine yerleştirebilir.setChildSurfacePackage

   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 doğrudan uygulamalar tarafından çağrılmaması önerimizdir. Bunun yerine, uygulama geliştiricilerin üzerindeki yükü azaltmak için bu API'ler, yukarıda bahsedilen oluşturulan API referansı tarafından "ara katman"da ç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'lardan oluşacak şekilde tasarlanması durumunda ve farklı taraflara ait iki SDK'nın, çağıran uygulamadan gelen bir isteği karşılamak için birlikte çalışması gerektiğinde ortaya çıkabilir.

Dikkate alınması gereken iki önemli durum vardır:

• Her iki SDK da çalışma zamanında etkinleştirildiğinde. Bu durumda, her iki SDK da SDK Çalışma Zamanı'nda tüm korumalarıyla birlikte çalışır. SDK'lar, günümüzde bir uygulama içinde olduğu gibi iletişim kuramıyor. Sonuç olarak, yüklenen tüm RE-SDK'lar için SandboxedSdk nesnelerinin getirilmesini sağlamak amacıyla SdkSandboxController API'si eklendi. Bu sayede, RE-SDK, SDK çalışma zamanında yüklenen diğer SDK'larla iletişim kurabilir.
• Yalnızca bir SDK çalışma zamanında etkinleştirildiğinde.
  • Çağıran SDK uygulamada çalışıyorsa bu işlem, uygulamanın SDK Çalışma Zamanı'nda ikinci SDK'yı çağırmasından farklı değildir.
  • Çağıran SDK SDK Çalışma Zamanı'nda çalışıyorsa bu öneride, uygulamadaki kodun dinlediği, işlediği ve sağlanan geri çağırmalarla yanıt verdiği, uygulamadan SDK'ya bölümde açıklanan IBinder yöntemini kullanarak bir yöntem göstermeniz önerilir.
  • Çalışma zamanında etkinleştirilmemiş reklam SDK'ları kendilerini kaydedemeyebilir. Tüm iş ortağı veya uygulama SDK'larını uygulamanın doğrudan bağımlılıkları olarak içeren ve kaydı yöneten bir arabulucu SDK'sı oluşturmanızı öneririz. Bu arabulucu SDK'sı, çalışma zamanı özellikli olmayan SDK'lar veya diğer uygulama bağımlılıkları ile bağdaştırıcılık işlevi gören çalışma zamanı özellikli arabulucu 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 son Geliştirici Önizlemesi'nde kullanılabilir)
• Uygulama ile SDK Çalışma Zamanı arasında SDK-SDK iletişimi (en son Geliştirici Önizlemesi'nde kullanılabilir)
• Görünümler ve uzaktan oluşturma, uyumlulaştırma için nasıl çalışmalıdır? (Geliştirme aşamasındaki teklif)

İlkeler tasarlanırken aşağıdaki kullanım alanları dikkate alınır:

1. Uyumlulaştırma ve Teklif Verme. Birçok reklamcılık SDK'sı, SDK'nın reklam gösterimi (uyumlulaştırma) veya açık artırma çalıştırmak için sinyal toplama (teklif verme) amacıyla diğer çeşitli SDK'ları çağırdığı bir uyumlulaştırma veya teklif verme özelliği sunar. Koordine eden SDK genellikle, koordine eden SDK tarafından sağlanan bir bağdaştırıcısı aracılığıyla diğer SDK'ları çağırır. Yukarıdaki temel özellikler göz önüne alındığında, koordine eden SDK (RE veya RE olmayan) 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 alandır.
2. Özellik keşfi. Bazı SDK ürünleri, SDK'lar arası keşif süreciyle uygulama geliştiriciye sunulan nihai özellik grubunu belirleyen daha küçük SDK'lardan oluşur. Kayıt ve keşif temel öğelerinin bu kullanım alanını etkinleştirmesi beklenir.
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ına sahip olacak şekilde tasarlanmıştır. Yukarıdaki primitifler bu kullanım alanını desteklemelidir.

Uygulamadan uygulamaya

Uygulamalar arası iletişim, iletişim kuran iki işlemden en az birinin çalışma zamanında etkinleştirilmiş bir SDK olduğu ve açıklanmayan veri paylaşımı için potansiyel bir vektör olduğu durumdur. Sonuç olarak, SDK Çalışma Zamanı, istemci uygulama dışındaki herhangi bir uygulamayla veya başka bir uygulama için oluşturulan başka bir SDK çalışma zamanındaki SDK'larla doğrudan iletişim kanalı kuramaz. Bu, aşağıdaki yöntemlerle gerçekleştirilir:

• SDK, manifest dosyasında <service>, <contentprovider> veya <activity> gibi bileşenleri tanımlayamıyor.
• SDK, ContentProvider yayınlayamıyor veya yayın gönderemiyor.
• SDK, başka bir uygulamaya ait bir etkinliği başlatabilir ancak Intent'te gönderilebilecek öğelerle ilgili sınırlamalar vardır. Örneğin, bu Intent'e ekstra veya özel işlem eklenemez.
• SDK yalnızca bir izin verilenler listesindeki hizmetleri başlatabilir veya bu hizmetlere bağlanabilir.
• SDK yalnızca ContentProvider sisteminin bir alt kümesine (com.android.providers.settings.SettingsProvider gibi) erişebilir. Bu alt kümede elde edilen verilerde tanımlayıcı bulunmaz ve kullanıcının parmak izi oluşturmak için kullanılamaz. Bu kontroller, ContentResolver kullanarak ContentProvider'e erişmek 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 manifest dosyasını 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> tanımlamayabilir. Yükleme işlemi başarısız olan etiketler SDK çalışma zamanında desteklenmez. Yüklemede başarısız olmayan ancak sessizce yok sayılan etiketler gelecekteki Android sürümlerinde desteklenebilir.

Bu kontroller, SDK'nın SDK paketini oluşturmak için kullandığı tüm 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 etkinlikleri oluşturur ve SDK'larla paylaşır.

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

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

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

Geliştirme

Bu önerinin temel ilkelerinden biri, geliştirici ekosistemi üzerindeki etkiyi mümkün olduğunca en aza indirmektir. Bu teklif, geliştiricilere RE uygulamaları ve SDK'ları yazmak, derlemek, hata ayıklamak için kapsamlı bir geliştirme araçları grubu sunar. Bu teklifin bütünlüğünü sağlamak için RE uygulamalarının ve SDK'larının yapılandırılmasında, oluşturulmasında ve derlenmesinde bazı değişiklikler yapıldı.

Yazma

Android Studio ve ilgili araçlar, SDK Çalışma Zamanı'na duyarlı olacak şekilde güncellenecek. Bu güncelleme, geliştiricilerin RE uygulamalarını ve SDK'larını doğru şekilde yapılandırmasına ve eski veya desteklenmeyen çağrıların, uygun olduğu durumlarda daha yeni alternatifleriyle güncellenmesine yardımcı olacaktır. Yazma aşamasında, önerimizin geliştiricilerin uygulaması gereken bazı adımları vardır.

Uygulama geliştiriciler

Uygulamaların, RE SDK'larını ve SDK sertifika bağımlılıklarını uygulama manifestlerinde belirtmesi gerekir. Teklifimizde, bu teklif boyunca uygulama geliştiriciden gelen doğruluk kaynağı olarak kabul ederiz. Ö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ştiricisinin bu değeri ilgili uygulama mağazasından almasını ve kaydettirmesini öneririz.

Bu durum, RE olup olmadığına bakılmaksızın yalnızca uygulama mağazasında 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ştiricileri en az düzeyde etkileme hedefimiz doğrultusunda, SDK çalışma zamanını destekleyen bir hedef API düzeyi belirtildiğinde uygulama geliştiricilerin yalnızca tek bir yapıya sahip olması gerekir. Bu yapı, SDK çalışma zamanını destekleyen veya desteklemeyen cihazlarda çalışabilir.

SDK geliştiricileri

Önerdiğimiz tasarımda, RE SDK geliştiricilerinin manifest'te SDK'yı veya kitaplık öğesini temsil eden yeni bir öğeyi açıkça belirtmesi 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ı muhtemelen bir uygulama geliştiricisinin aynı bağımlılığı beyan ettiği şekilde beyan etmeleri gerekir. RE SDK'ları, RE dışı SDK'lara bağlıysa bunları statik olarak bağlar. RE dışı SDK'lar, SDK çalışma zamanının desteklemediği işlevler gerektiriyorsa veya uygulamanın sürecinde çalışması gerekiyorsa bu, derleme sırasında veya test geçişlerinde algılanacak sorunlara neden olabilir.

RE SDK'sı geliştiricileri, RE etkin olmayan cihazları (ör. Android 12 veya önceki sürümler ve 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) desteklemeye devam etmek isteyebilir. SDK geliştiricilerinin, RE ve RE dışı ortamları desteklemek için tek bir kod tabanı kullanabilmesini sağlayacak 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ında dağıtılan (RE olup olmadığına bakılmaksızın) SDK bağımlılıklarının, linting, derleme ve derlemeler için makinede bulunması gerekir. Android Studio'nun bu ayrıntıları normal kullanımda uygulama geliştiriciden soyutlamasını ve bu işlemi mümkün olduğunca şeffaf bir şekilde yapmasını öneriyoruz.

Hata ayıklama yapılabilmesi için HATA ARAMA derlemesinde bulunması gereken tüm kod ve sembollerin HATA ARAMA derlemesinde yer alması gerekir. Ancak KULLANIMA SUNMA derlemelerinde, uygulama mağazasında dağıtılan tüm SDK'lar (RE olsun veya olmasın) isteğe bağlı olarak nihai yapıdan kaldırılır.

Tasarım aşamamızın henüz başlarındayız. Gelişmeler olduğunda daha fazla bilgi paylaşacağız.

SDK geliştiricileri

Bir SDK'nın RE olmayan ve RE sürümlerinin dağıtım için tek bir yapıya derlenebilmesini sağlayacak bir yol üzerinde ç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ında dağıtılan tüm bağımlılık SDK'larının linting, derleme ve derlemeler için makinede bulunması gerekir. Android Studio'nun bunu 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. Geliştirici, uygulamasını oluşturduktan sonra uygulamayı bir RE cihazına veya emülatöre yükleyebilir. Bu yükleme işlemi, SDK'ların uzak bir SDK deposundan veya derleme sisteminden önbelleğe çekilip çekilmediğine bakılmaksızın, cihaz veya emülatör için SDK çalışma zamanına doğru SDK'ların yüklenmesini sağlar.

SDK geliştiricileri

SDK geliştiricileri, geliştirmelerini test etmek için genellikle cihazlarda ve emülatörlerde şirket içi test uygulamalarını kullanır. Teklifimiz bu durumu değiştirmez. Uygulama içi doğrulama, hem RE hem de RE dışı uygulamalar için tek bir derleme yapısını kullanarak, yukarıda uygulama geliştiriciler için belirtilen adımlarla aynı şekilde gerçekleştirilir. SDK geliştiricileri, SDK çalışma zamanında olsun veya olmasın kodlarında adım adım ilerleyebilir. Ancak gelişmiş hata ayıklama ve profil oluşturma araçlarında bazı sınırlamalar olabilir. Bu konu üzerinde aktif olarak araştırma yapılmaktadır.

Dağıtım

Uygulamaların SDK'larından ayrılmasına yönelik tasarım önerimiz, SDK'ların uygulama mağazasında dağıtımının mümkün olmasını sağladı. Bu, belirli bir uygulama mağazasına özgü olmayan genel bir olasılıktır. Bu yöntemin avantajları açıktır:

• SDK'ların kalitesinden ve tutarlılığından emin olun.
• SDK geliştiricileri için yayın sürecini kolaylaştırır.
• Yüklü uygulamalarda SDK alt sürüm güncellemelerinin kullanıma sunulmasını hızlandırın.

SDK dağıtımını desteklemek için bir uygulama mağazasının büyük olasılıkla aşağıdaki özelliklerin çoğunu sağlaması gerekir:

• SDK geliştiricilerin uygulama mağazasında dağıtılabilir SDK'larını mağazaya yüklemeleri, güncellemeleri, geri almaları ve gerekirse kaldırmaları için bir mekanizma.
• Bir SDK'nın ve kaynağının, bir uygulamanın ve kaynağının bütünlüğünü sağlayan ve bağımlılıklarını çözen bir mekanizma.
• Bunları cihazlara tutarlı bir şekilde güvenilir ve performanslı bir şekilde dağıtan bir mekanizma.

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

SDK çalışma zamanında 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 belirli bir SDK düzeyindeki ana modül güncellemeleriyle bu kısıtlamaları değiştirmeyiz. Belirli bir targetSdkVersion ile ilişkili davranış, uygulama mağazası politikası aracılığıyla bu targetSdkVersion için destek sonlandırılana kadar korunur ve targetSdkVersion desteğinin sonlandırılması, uygulamalara kıyasla daha hızlı bir ritimde gerçekleşebilir. Android SDK sürümleri arasında, özellikle de ilk birkaç sürümde kısıtlamaların sık sık değişmesini bekleyin.

Ayrıca, harici ve şirket içi test kullanıcılarının Android'in bir sonraki sürümü için önerilen kısıtlama grubuna katılan bir gruba katılmasına olanak tanıyan bir kanarya 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'lar, reklamverene ait olmayan uygulamalarda ticari amaçlı mesajlarla kullanıcı hedeflemenin herhangi bir bölümünü kolaylaştıran SDK'lardır. Buna, sonraki hedefleme için kullanıcı gruplarının oluşturulabileceği analiz SDK'ları, reklam sunma SDK'ları, reklamlar için kötüye kullanım ve sahtekarlık önleme SDK'ları, etkileşim SDK'ları ve ilişkilendirme SDK'ları dahildir ancak bunlarla sınırlı değildir.

2. Herhangi bir SDK, SDK Çalışma Zamanı'nda çalışabilir mi?

   İlk odak reklamlarla ilgili SDK'lar olsa da gizlilik odaklı bir yaklaşım benimseyen ve yukarıda belirtilen koşullar altında çalışabileceğini düşünen, reklamlarla 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ırma uygulamasıyla gerçek zamanlı veya yüksek aktarım hızında iletişim kurması gereken SDK'lar için uygun olmayabilir.

3. Bir işlemin Java tabanlı çalışma zamanındaki yalıtım yerine neden işlem yalıtımı seçmelisiniz?

   Java tabanlı çalışma zamanı, şu anda Android kullanıcıları için istenen gizlilik güvenceleri için gerekli güvenlik sınırlarını kolayca sağlamamaktadır. Bunun gibi bir şeyi uygulamaya çalışmak, büyük olasılıkla yıllarca sürecek bir çaba gerektirir ve başarı garantisi yoktur. Bu nedenle Özel Korumalı Alan, kullanım süreci sınırlarını kullanır. Bu, zaman içinde test edilmiş ve iyi anlaşılmış bir teknolojidir.

4. SDK'ları SDK Runtime sürecine taşımak indirme boyutunda veya alanda tasarruf sağlar mı?

   Birden fazla uygulama, aynı sürümün çalışma zamanında etkinleştirilen SDK'larıyla entegre edilmişse indirme boyutu ve disk alanı azaltılabilir.

5. SDK'ların SDK Çalışma Zamanı'nda erişebileceği uygulama yaşam döngüsü etkinlikleri nelerdir (ör. uygulama arka plana geçtiğinde)?

   İstemci uygulamasının uygulama düzeyindeki yaşam döngüsü etkinlikleri (ör. uygulamanın arka plana geçmesi, uygulamanın öne plana geçmesi) 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 yapılacak bir geliştirici önizlemesinde paylaşılacak.

Sizin için önerilenler

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