SDK Çalışma Zamanı

Geri bildirim gönderin

Android platformu, işlem sınırları ile birlikte uygulama kodu için sağlam yürütme ve güvenlik sınırları sağlamak amacıyla uygulamayı korumalı alana alma kavramını kullanır. Uygulamaların, üçüncü taraf kodunu genellikle reklam SDK'ları veya analiz SDK'ları gibi SDK'lar biçiminde içermesi yaygın bir uygulamadır. Bu yeniden kullanım, uygulama geliştiricilerinin uygulamalarının farklılaşmasına odaklanmalarına olanak tanırken, aynı zamanda alanlarında uzman kişilerin çalışmalarından yararlanıp uygulamalarını kendi başlarına kolayca yapabileceklerinin ötesine taşımalarını sağlar.

Çoğu işletim sisteminde olduğu gibi Android SDK'ları da ana makine uygulamasının korumalı alanı içinde yürütülür ve ana makine uygulamasının bellek ve depolama alanının yanı sıra ana makine uygulamasının aynı ayrıcalıklarını ve izinlerini devralır. Bu mimari, SDK'ların ve uygulamaların esnek bir şekilde entegre edilmesine olanak tanırken, açıklanmayan kullanıcı verilerinin toplanması ve paylaşılması potansiyeli de oluşturur. Dahası, uygulama geliştiriciler bir üçüncü taraf SDK'sının işlevlerinin ve eriştiği verilerin kapsamını tam olarak bilemeyebilirler. Bu da uygulamalarının veri toplama ve paylaşma yöntemlerinin dikkate alınmasını zorlaştırabilir.

Android 13'e, üçüncü taraf SDK'ların SDK Çalışma Zamanı adı verilen özel bir çalışma zamanı ortamında çalışmasını sağlayan 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ı

Goller

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

  • İşlem izolasyonu, iyi tanımlanmış API ve veri erişimi kontrolü sayesinde kullanıcının uygulama verilerine üçüncü taraf SDK'lar tarafından açıkça erişilmesini ve verilerin üçüncü taraf SDK'lar tarafından paylaşılmasını azaltın. İşlem izolasyonu hakkında daha fazla bilgiyi bu belgenin ayrı bir bölümünde bulabilirsiniz.
  • Benzersiz, kalıcı tanımlayıcılara SDK'ların erişimini sınırlandırarak bir kullanıcının üçüncü taraf SDK'lar tarafından uygulama kullanımının açıklanmayan takibini 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 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 katmasına yardımcı olun.
  • SDK geliştiricilerinin, JNI kodu gibi güvenli olmayan belirli dil yapılarını sınırlandırarak diğer SDK'lar tarafından izinsiz değişiklik yapılmasını önlemelerine yardımcı olun.
  • Reklam SDK'larının, medyanın gösterildiği uzaktan görünümler üzerinde tam kontrol sağlayarak geçersiz trafiği ve reklam sahtekarlığını tespit edip önlemesine yardımcı olun.
  • Uygulama ve SDK geliştiricileri üzerindeki aşırı etkiyi mümkün olduğunca azaltın.

SDK'lar izole 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 anılan uyumlu SDK'ların uygulama için ayrı bir süreçte çalışabilmesini sağlar. Platform, uygulamanın süreci ile SDK Çalışma Zamanı arasında çift yönlü iletişimi kolaylaştırır. Ayrıntılı bilgi için bu belgenin iletişim bölümünü inceleyin. RE olmayan SDK'lar bugün olduğu gibi uygulama sürecinde kalır. Şekil 1'de bu değişiklikler gösterilmiştir:

Önce:


Yapılandırmadan sonra:

Şekil 1. Çalışma zamanının etkin olduğu SDK'ların, SDK Çalışma Zamanına eklenmeden önceki ve eklendikten sonraki göreli konumları. "Önce" şeması (ilk olarak), SDK çağırma kodunun ve bu koddan gelen çağrıları alan SDK'ların tamamının uygulama işleminde bulunduğunu göstermektedir. "Sonrası" şeması (saniye), uygulamanın ön plan işleminde SDK çağrısının SDK arayüzleriyle iletişim kurduğunu göstermektedir. Bu arayüzler, daha sonra SDK'ların kendilerini çağırmak için işlem sınırını geçerek SDK Çalışma Zamanı işlemine geçer.

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

SDK'nın uygulamadan ayrılması önerilen bu yaklaşım, SDK ve uygulama dağıtımı için olmak üzere başka bir ayırma kavramını teşvik etmektedir. Teklifimiz, uygulamaların SDK Çalışma Zamanı'na doğru SDK'ların yüklendiğinden emin olmak için güvenilir bir dağıtım ve yükleme mekanizması gerektirir. Bu, kullanıcıların ve uygulama geliştiricilerin geçersiz SDK'ların yüklenmesine karşı korunmasına yardımcı olurken uygulama mağazalarının da uygulama geliştiricilerin SDK dağıtım yükünü önemli ölçüde azaltmasını sağlar.

Artık SDK'ların, dağıtım için bir uygulama mağazasına yüklenmeden önce statik olarak bağlı olması ve uygulamalarıyla birlikte paketlenmesine gerek yoktur. Bunun yerine aşağıdaki işlem gerçekleşir:

  1. SDK geliştiricileri, kendi sürümü olan SDK'larını uygulamaların kendilerinden ayrı olarak uygulama mağazalarına yükleyebilirler.
  2. Uygulama geliştiriciler, SDK bağımlılıklarını sürüme, derlemeye ve gerçek SDK bağımlılıklarını içermeyen bir uygulama sürümü yükleyerek belirtebilir.
  3. Bir kullanıcı bu uygulamayı indirdiğinde, yükleme işlemi uygulamanın belirtilen SDK bağımlılıklarını kullanıp bunları uygulama mağazasından indirebilir.

Bu yeni dağıtım mekanizması, SDK geliştiricilerinin SDK'larında ayrılmaz değişiklikler yapmasını (API'lerde veya anlamlarında hiçbir değişiklik yapmadan) ve uygulama geliştiricilerin müdahalesi olmadan cihazlara dağıtmasına olanak tanır. Bu kesintiye uğramayan SDK değişiklikleri, uygulama geliştiricilerin uygulamalarını yeni SDK'larla yeniden oluşturmalarını ya da son kullanıcıların uygulamalarını güncellemelerini beklemek zorunda kalmadan dağıtılabilir veya geri alınabilir. Çarpıcı değişikliklerin uygulama geliştiriciler tarafından yine de güncellenmesi gerekir ancak SDK geliştiricileri en son zarar vermeyen değişikliklerini ve düzeltmeleri daha hızlı ve tutarlı bir şekilde daha fazla kişiye ulaştırabilir, böylece sürüm desteğini en aza indirebilir.

Şekil 2'de SDK dağıtımında önerilen değişiklikler gösterilmektedir:

Önce:

Diyagramdan önce

Yapılandırmadan sonra:

Diyagramdan sonra
Şekil 2. SDK Çalışma Zamanının kullanıma sunulmasından önceki ve sonraki SDK dağıtım tasarımı. SDK geliştiricileri artık SDK'larını doğrudan uygulamalara göndermeyecek. Bunun yerine SDK geliştiricileri, SDK'larını bir uygulama mağazasında yayınlamak için SDK yükleme kullanıcı arayüzü kullanacaktır. Ardından uygulama mağazası, son kullanıcı cihazlarına uygulamaların dağıtımını tüm SDK bağımlılıklarıyla birlikte yönetir.

SDK'ların ve uygulamaların derlenme, çalıştırılma ve dağıtılma biçiminde yapılan 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, aşağıdaki geniş kategorilerde yapılan bir dizi değişiklik belirtilmiştir:

  • 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şim: Uygulamadan SDK'ya ve SDK'dan SDK'ya
  • Geliştirme: Bu modelde derleme, hata ayıklama ve test yapma
  • Dağıtım: Android, uygulama ve SDK sürümlerinde dağıtma, güncelleme ve geri çekme

Bu dokümanda, sık sorulan soruların yanıtlanmasına yardımcı olacak bir SSS bölümü de bulunmaktadır.

Bu, başlangıçtaki bir tasarım teklifidir ve bunun ekosistemin bazı üyeleri için anlamlı bir değişiklik olabileceğinin farkındayız. Bu nedenle aktif olarak geri bildirim istiyoruz ve sorun izleyici üzerinden sizden geri bildirim göndermenizi rica ediyoruz.

Erişim

Bir sistemin gizliliğini yönetmek, farklı tarafların farklı kaynaklara nasıl erişebileceğini yönetmeyi gerektirir. Gizlilik değeri teklifimizi karşılamak adına uygulamalara, SDK'lara ve kullanıcı verilerine erişim modelimizi, potansiyel olarak hassas olabilecek verilere açıklanmayan erişimi önlemek amacıyla en az ayrıcalık ilkesine uyarak güncellemenizi öneriyoruz.

SDK izinleri

Ayrı bir süreç olarak SDK Çalışma Zamanı, kullanıcının uygulamaya verdiği izinleri devralmak yerine kendi iyi tanımlanmış izin gruplarına sahiptir. Reklamlarla ilgili SDK'lar tarafından kullanılan izinler üzerine yapılan ön araştırmalara dayanarak, aşağıdaki izinlerin SDK Çalışma Zamanındaki SDK'ların varsayılan olarak erişebilmesini öneririz:

  • INTERNET: Bir web hizmetiyle iletişim kurabilmek için internete erişim.
  • ACCESS_NETWORK_STATE: Ağlarla ilgili bilgilere erişim.
  • Uygulamalar arası tanımlayıcılara erişilmesine gerek kalmadan temel reklamcılık özellikleri sunan gizliliği koruyan API'lere erişim izinleri.
  • AD_ID: Reklam kimliği isteme olanağı. Bu izin, uygulamanın bu izne erişimiyle de kontrol edilir.
  • BIND_GET_INSTALL_REFERRER_SERVICE: Bir uygulamanın yükleme kaynağını ilişkilendirmek için Google Play Yükleme Referrer API'sini kullanabilme.

Şu anda ek izinlere onay verilip verilmeyeceğini ve nasıl yetkilendirileceğini, son kullanıcılar üzerindeki etkiyi hem gizlilik hem de kullanılabilirlik açısından sınırlandıracak şekilde araştırıyoruz. Bu izin grubunun karşılayamadığı kullanım alanları hakkında geri bildirim isteriz.

Bellek

SDK Çalışma Zamanı, kendi süreci olduğundan kendi izole bellek alanına sahip olur. Bu yapı varsayılan olarak, uygulamanın bellek alanına SDK erişimini reddeder ve uygulama da benzer şekilde SDK'nın bellek alanına erişemez. Bu varsayılan davranışı en az ayrıcalık ilkesiyle uyumlu hale getirmenizi öneriyoruz.

Depolama

Bu teklif, SDK'ların normal işlemleri için depolama alanına erişim ihtiyacını dengelemeyi ve kalıcı depolama alanı kullanarak uygulamalar arası ve işlemler arası izlemeyi en aza indirmeyi amaçlar. Şu anda depolama alanına erişimle ilgili aşağıdaki güncellemeyi öneriyoruz:

  • Bir uygulama, SDK'sının depolama alanına doğrudan erişemez ve bunun tersi de geçerlidir.
  • SDK'lar, cihazın harici depolama alanına erişemez.
  • Her SDK Çalışma Zamanında hem tüm SDK'ların erişebildiği depolama alanı hem de belirli bir SDK'ya özel depolama alanı olur.

Mevcut depolama alanı modelinde olduğu gibi, depolama alanının da rastgele boyut sınırları yoktur. 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.

Uygulama

Uygulamalar, SDK'lar ve kullanıcılar arasında özel bir sistem sağlamak için yürütme bağlamının kendisinin (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 erişimi ve SDK'ların şu anda sahip olduğu çalışma zamanı özelliklerinin büyük kısmını korumak istiyoruz. Burada, bu dengeyi sağlamak için çalışma zamanı ortamında yapılacak bir dizi güncellemeyi öneriyoruz.

Kod

Android kodu (uygulamalar ve SDK'lar), kodun 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'ın zenginliği ve sunduğu dil yapılarının yanı sıra, alternatiflerle (özellikle de yerel kodla) karşılaştırıldığında sunduğu doğrulanabilirlik kapasitesi, işlev ve gizliliğin uygun şekilde dengelendiğini gösteriyor. Çalışma zamanı özellikli 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, yerel kod kullanıldığında Android SDK'nın yerleşik SQLite sürümü gibi bir alternatifle değiştirilmesi gerektiğinin farkındayız.

SELinux

Android'de her işlem (kök olarak çalıştırılanlar dahil) belirli bir SELinux bağlamıyla çalışır ve çekirdeğin sistem hizmetleri, dosyalar, cihazlar ve diğer işlemlere erişim kontrolünü yönetmesine olanak tanır. Hem SDK kullanım alanlarının çoğunu korumak hem de devam etmeye çalıştığımız gizlilik korumalarının atlatılmasını en aza indirmek amacıyla, SDK Çalışma Zamanı için sistem dışı bir uygulamanın SELinux bağlamından aşağıdaki güncellemeleri öneriyoruz:

  • Sınırlı bir sistem hizmeti grubuna erişilebilir. (etkin tasarım altında)
  • SDK'lar yalnızca kendi APK'larındaki kodu yükleyip çalıştırabilir.
  • Sınırlı bir sistem özelliği grubuna erişilebilir. (etkin tasarım altında)

API'ler

SDK çalışma zamanında yansıma ve çağırma API'lerinin kullanımına izin verilir. Ancak SDK'ların, çalışma zamanının etkin olduğu başka bir SDK'da yansıma kullanmasına veya API'leri çağırmasına izin verilmez. Yasaklanmış API'lerle ilgili tüm teklifi gelecekteki bir güncellemede paylaşacağız.

Ayrıca son Android platformu sürümleri, gizliliği iyileştirmek için kalıcı tanımlayıcılara erişimi giderek daha kısıtlı hale getirmektedir. SDK Çalışma Zamanı için uygulamalar arası izlemede kullanılabilecek tanımlayıcılara erişimin daha fazla 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 planda uygulamalardan erişmeye çalışmak SecurityException mesajı gönderilmesine neden olur.

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

Yaşam döngüsü

Uygulama SDK'ları şu anda ana makine uygulamalarının yaşam döngüsünü izler. Diğer bir deyişle, uygulama ön plana girdiğinde veya ön plana çıktığında, kapandığında ya da bellek baskısı nedeniyle işletim sistemi tarafından zorla durdurulduğunda uygulamanın SDK'ları da bunu yapar. Bir uygulamanın SDK'larını farklı bir sürece ayırma teklifimiz, aşağıdaki yaşam döngüsü değişikliklerini gerektirir:

  • Uygulama kullanıcı veya işletim sistemi tarafından sonlandırılabilir. SDK Çalışma Zamanı, işlemden hemen sonra otomatik olarak sonlandırılır.
  • SDK Çalışma Zamanı, bellek baskısı veya örneğin bir SDK'daki işlenmemiş bir istisna nedeniyle işletim sistemi tarafından sonlandırılabilir.

    Android 13'te, ön plandaki bir uygulama yüksek öncelikli olarak çalışır ve sonlandırılması olası değildir. Uygulama arka plana gittiğinde SDK Çalışma Zamanı sürecinin önceliği düşer ve uygulama kapatılmaya uygun hale gelir. Uygulama geri dönse bile SDK Çalışma Zamanı sürecinin önceliği düşük kalır. Sonuç olarak, uygulamaya kıyasla bellek baskısı altında sonlanması çok olasıdır.

    Android 14 ve sonraki sürümler için uygulamanın işlem öncelikleri ve SDK çalışma zamanı birbiriyle uyumludur. Uygulama için ActivityManager.RunningAppProcessInfo.importance işlem öncelikleri ile SDK Çalışma Zamanı aşağı yukarı aynı olmalıdır.

    SDK Çalışma Zamanı, uygulama etkinken sona ererse (örneğin, SDK'da işlenmemiş bir istisna varsa) önceden 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, aşağıdaki yöntemlerden herhangi birini kullanarak SDK Çalışma Zamanının sonlandırılması işlemini gerçekleştirebilir:

    • Teklif, SDK Çalışma Zamanı'nın ne zaman feshedildiğ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 sona ererse reklamlar beklendiği gibi çalışmayabilir. Örneğin, görüntülemeler ekranda dondurulmuş olabilir ve artık etkileşimli olmayabilir. Uygulama, kullanıcı deneyimini etkilemiyorsa reklam görüntülemeyi 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üklenirken sonlandırılır ve uygulama geliştiricisi daha önce belirtilen yaşam döngüsü geri çağırma yöntemlerini kaydetmediyse uygulama varsayılan olarak sonlandırılır. Yalnızca SDK'ları yükleyen uygulama işlemleri sonlandırılır ve normal şekilde çıkar.
    • SDK tarafından iletişim kurmak için döndürülen bağlayıcı nesneleri (SandboxedSdk gibi), uygulama tarafından kullanılırsa bir DeadObjectException bildirir.

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

    Sürekli hata oluşursa uygulama geliştirici, SDK olmadan sorunsuz bir şekilde bozulmayı planlamalı veya SDK, uygulamanın temel işlevi açısından çok önemliyse kullanıcıyı bilgilendirmelidir. Bu uygulamadan SDK'ya etkileşim hakkında daha fazla bilgi için bu belgenin iletişim bölümünü inceleyin.

RE SDK'ları; hizmetler, etkinlikler ve yayınlar dahil olmak üzere yerleşik uygulamalarında bulunan standart OS temel öğelerini kullanmaya devam edebilir. Ancak RE SDK'ları kullanamaz.

Özel durumlar

Aşağıdaki durumlar desteklenmez ve beklenmeyen davranışlara yol açabilir:

  • Birden çok uygulama aynı UID'yi paylaşırsa 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 tamamlanmalıdır.

Medya oluşturma

Uygulama tarafından belirtilen bir görünümde metin, resim ve video gibi içerikler oluşturan SDK'lar vardır. Bunu başarmak için SDK'nın, medyayı SDK Çalışma Zamanı içinde oluşturacağı ancak medyanın uygulamaya belirtilen bir görünümde oluşturulmasına izin vermek için SurfaceControlViewHost API'nin kullanılacağı bir uzaktan oluşturma yaklaşımı öneriyoruz. Bu SDK, bu medyayı kullanıcı için gizli olacak şekilde oluşturma imkanı tanırken oluşturulan medyayla geçersiz veya sahte kullanıcı etkileşimlerinin önlenmesine ve tespit edilmesine yardımcı olur.

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

Yayın içi video reklamlar, video ile yayın içi olarak yayınlanan ve uygulama içindeki bir oynatıcıda gösterilen reklamlardır. Videonun SDK'daki bir oynatıcı veya görüntüleme yerine uygulama içindeki bir oynatıcıda oynatılması düşünüldüğünde, oluşturma modeli diğer reklam biçimlerinden farklıdır. Hem sunucu tarafı reklam eklemeyi hem de SDK tabanlı reklam eklemeyi destekleyecek mekanizmaları aktif olarak inceliyoruz.

Sistem sağlığı

SDK Çalışma Zamanı'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 büyük olasılıkla, Android (Go sürümü) gibi çok sınırlı sistem kaynaklarına sahip bazı giriş düzeyindeki Android 13 cihazlar, sistem sağlığına etkisi nedeniyle SDK Çalışma Zamanı'nı desteklemez. SDK Çalışma Zamanı'nın başarıyla kullanılması 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 bu uygulamalar arasındaki iletişim kesintisiz ve aracısızdır. Ayrıca, iletişim SDK'larla başlayıp bitse bile Android, uygulamalar arası iletişime olanak tanır. Bu serbest akışlı iletişim modeli, çeşitli kullanım alanlarına olanak tanırken aynı zamanda uygulamalar arasında ve uygulamaların içindeki ve arasındaki SDK'lar arasında açıklanmayan veri paylaşımına imkan tanır. Bu iletişimin değeri ile belirttiğimiz hedeflerin gerçekleştirilmesi arasında bir denge kurmak amacıyla bu iletişim modelinde yapılacak aşağıdaki güncellemeleri teklif ediyoruz.

Uygulamadan SDK'ya

Uygulama ile SDK arasındaki arayüz, SDK'lara giden en yaygın iletişim yoludur. SDK'ların API'leri ise kullanıcı odaklı farklılaşma ve inovasyonun büyük bir kısmını oluşturur. Burada SDK'ların yenilik yapma ve fark yaratma kapasitesini korumayı amaçlıyoruz. Sonuç olarak, teklifimiz SDK'ları API'leri uygulamalara sunma ve uygulamaların tüm bu yeniliklerden yararlanmasını sağlama konusunda destekler.

SDK Çalışma Zamanı'nın işlem sınırı yapısı göz önünde bulundurulduğunda, API çağrıları ile yanıtlarını veya geri çağırmalarını uygulama ile SDK arasında bu sınır boyunca taşımak için uygulamanın içinden 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ımlanacağını ve geliştireceğimiz resmi açık kaynaklı derleme araçları tarafından üretileceğini düşünüyoruz.

Bu teklifle, uygulama ve SDK geliştiricilerinin ortak metin düzenleme çalışmalarını kaldırmayı amaçlıyoruz. Aynı zamanda, SDK geliştiricilerine esneklik sağlamayı ve gizlilik hedeflerimizi gerçekleştirmek için SDK Çalışma Zamanı'nda SDK kodunun çalıştırılmasını sağlamayı amaçlıyoruz. Bu yolu izlememiz gerekirse API tanımlama dilinin ve araçlarının, girdiğiniz bilgilerle tasarlanması gerekir.

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

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

Bu teklifin süreçler arası yeni yapısının bir sonucu olarak, biri uygulamanın kendisi, diğeri SDK Çalışma Zamanı için olmak üzere yönetilmesi gereken iki süreç yaşam döngüsü vardır. Önerimiz, uygulama ve SDK geliştiricileri üzerindeki etkiyi en aza indirerek bunu mümkün olduğunca otomatikleştirmeyi amaçlar. Şekil 3'te, düşündüğümüz bir yaklaşım gösterilmektedir:

Diyagram
Şekil 3. Uygulama ve SDK başlatma sırasında uygulamadan SDK'ya etkileşimleri gösteren sıra şeması.

Platform, uygulamaların SDK'ları SDK Çalışma Zamanı sürecine dinamik olarak yüklemek, sürecin durumundaki değişiklikler hakkında bildirim almak ve SDK Çalışma Zamanı'na yüklenen SDK'larla etkileşime geçmek için yeni API'ler sunacaktır.

Şekil 3'teki grafik, sıralama katmanı olmadan, daha düşük bir düzeyde uygulamadan SDK'ya iletişimi göstermektedir.

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

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

    Aşağıdaki kod snippet'i açıklayıcı bir API örneği sağlar:

    SdkSandboxManager.loadSdk(String sdkName, Bundle data, Executor executor,
        OutcomeReceiver<SandboxedSdk, LoadSdkException> receiver)
    
  2. SDK yüklendiği konusunda bildirim alır ve arayüzünü döndürür. Bu arayüz, uygulama işlemi tarafından kullanılmak üzere tasarlanmıştır. Arayüzü işlem sınırının dışında paylaşmak için IBinder nesnesi olarak döndürülmesi gerekir.

    Bağlayıcı hizmetler kılavuzunda IBinder sağlamak için farklı yöntemler sunulmaktadır. Hangi yöntemi seçerseniz seçin, SDK ile arayan uygulama arasında tutarlı olmalıdır. Şekil 3'teki grafikte örnek olarak AIDL kullanılmıştır.

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

  4. Uygulama, IBinder öğesini alıp SDK arayüzüne yayınlayarak fonksiyonlarını ç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 belgenin medya oluşturma bölümünde açıklandığı gibi, bir uygulamanın bir görünümde medya oluşturmak üzere bir SDK alabilmesi için uygulama requestSurfacePackage() kodunu çağırabilir ve uygun SurfaceControlViewHost.SurfacePackage kodunu getirebilir.

    Aşağıdaki kod snippet'i açıklayıcı bir API örneği sağlar:

    SdkSandboxManager.requestSurfacePackage(String sdkName, Bundle extraParams,
            Executor executor,
            OutcomeReceiver<Bundle, RequestSurfacePackageException> receiver)
    
  2. Daha sonra uygulama, 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'i açıklayıcı bir API örneği sağlar:

    SurfaceView.setChildSurfacePackage(SurfacePackage surfacePackage)
    

Önerimiz, IBinder ve requestSurfacePackage() API'lerinin genel olması ve doğrudan uygulamalar tarafından çağrılabilecek şekilde tasarlanmamasıdır. Bunun yerine bu API'ler, uygulama geliştiricilerin üzerindeki yükü azaltmak amacıyla yukarıda açıklanan oluşturulan API referansı tarafından bir "şömlek" katmanında çağrılır.

SDK'dan SDK'ya

Aynı uygulamadaki iki SDK'nın genellikle iletişim kurması gerekir. Bu durum, belirli bir SDK, bileşen SDK'lardan oluşacak şekilde tasarlandığında ve çağrı yapan uygulamadan gelen bir isteği karşılamak için farklı taraflardan iki SDK'nın birlikte çalışması gerektiğinde ortaya çıkabilir.

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

  • Her iki SDK da çalışma zamanı özellikli olduğunda. Bu durumda her iki SDK da tüm korumalarıyla SDK Çalışma Zamanında çalışır. SDK'lar şu anda bir uygulamanın içindeki gibi iletişim kuramamaktadır. Sonuç olarak, yüklenen tüm RE-SDK'lar için SandboxedSdk nesnelerinin getirilmesini sağlamak amacıyla SdkSandboxController bölgesinde bir API eklendi. Bu, RE-SDK'nın SDK Çalışma Zamanında yüklenen diğer SDK'larla iletişim kurmasını sağlar.
  • Yalnızca tek bir SDK çalışma zamanı özellikli olduğunda.
    • Çağlayan SDK uygulama içinde çalışıyorsa bu, SDK Çalışma Zamanı içinde ikinci SDK'yı çağıran uygulamanın kendisinden farklı değildir.
    • Çağlayan SDK SDK Çalışma Zamanı içinde çalışıyorsa bu teklif, uygulama-SDK bölümünde açıklanan IBinder kullanan ve uygulamadaki kodun dinlediği, işlediği ve sağlanan geri çağırmalarla yanıt verdiği bir yöntemin sunulmasını önerir.
    • Çalışma zamanı özellikli olmayan reklam SDK'ları kendilerini kaydedemeyebilir. Uygulamanın doğrudan bağımlılığı olarak iş ortağı veya uygulama SDK'larını içeren ve kaydı gerçekleştiren bir aracı SDK'sının oluşturulmasını öneririz. Bu aracı SDK'sı, çalışma zamanı özellikli olmayan SDK'lar veya diğer uygulama bağımlılıkları ile bağdaştırıcı olarak görev yapan ç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ı içinde SDK-SDK iletişimi (en son Geliştirici Önizlemesi'nde mevcuttur)
  • Uygulama ile SDK Çalışma Zamanı arasında SDK-SDK iletişimi (en son Geliştirici Önizlemesi'nde mevcuttur)
  • Uyumlulaştırma için görüntülemeler ve uzaktan oluşturma nasıl çalışmalıdır? (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 Teklif Verme. Birçok reklam SDK'sı uyumlulaştırma veya teklifli sistem özelliği sunar. Bu özellik sayesinde SDK, diğer SDK'ları reklam gösterimi (uyumlulaştırma) veya açık artırma yapmak için sinyal toplama (teklifli sistem) çağrısında bulunur. Genellikle koordine SDK, diğer SDK'ları düzenleyen SDK tarafından sağlanan bir bağdaştırıcı aracılığıyla çağırır. Yukarıdaki temel öğeler göz önünde bulundurulduğunda, koordinasyon SDK'sı (RE) ve RE olmayan tüm SDK'lar normal çalışma için tüm RE ve RE olmayan SDK'lara erişebilmelidir. Bu bağlamda oluşturma, etkin bir araştırma alanıdır.
  2. Özellik keşfi. Bazı SDK ürünleri daha küçük SDK'lardan oluşur. Bu SDK'lar, SDK arası keşif süreciyle uygulama geliştiricisine sunulan nihai özellik grubunu belirler. 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ğırmalarla bildirim almak için abone olabileceği etkinliklerin merkezi bir yayıncısı olacak şekilde tasarlanmıştır. Yukarıdaki temel öğeler bu kullanım alanını desteklemelidir.

Uygulamadan uygulamaya

Uygulamadan uygulamaya iletişimde, iletişim kuran iki süreçten en az biri çalışma zamanı özellikli bir SDK'dır ve açıklanmamış veri paylaşımı için potansiyel bir vektördür. Sonuç olarak, SDK Çalışma Zamanı, istemci uygulaması dışında bir uygulamayla veya başka bir uygulama için oluşturulmuş başka bir SDK çalışma zamanındaki SDK'larla doğrudan iletişim kanalı kuramaz. Bu, aşağıdaki şekillerde gerçekleştirilir:

  • SDK, manifest dosyasında <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 etkinlik başlatabilir ancak Intent'te nelerin gönderilebileceğine dair sınırlar vardır. Örneğin, bu Intent'e hiçbir ekstra veya özel işlem eklenemez.
  • SDK yalnızca bir hizmet listesi başlatabilir veya izin verilenler listesine bağlanabilir.
  • SDK, sistemin yalnızca bir alt kümesine (ContentProvider (ör. com.android.providers.settings.SettingsProvider) erişebilir. Bu durumda, elde edilen veriler tanımlayıcı içermez ve kullanıcının parmak izini oluşturmak için kullanılamaz. Bu kontroller, ContentResolver kullanarak ContentProvider erişimi için de geçerlidir.
  • SDK, korunan yayın alıcılarının yalnızca 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 yasaklı manifest etiketleri varsa SDK'yı yükleyemez. Örneğin SDK, <service>, <activity>, <provider> veya <receiver> gibi bileşenleri tanımlayamaz ve manifest dosyasında <permission> tanımlayamaz. Yükleme işlemi başarısız olan etiketler, SDK Çalışma Zamanı'nda desteklenmez. Yükleme işlemi başarısız olmayan ancak sessizce yoksayılan etiketler, gelecekteki Android sürümlerinde desteklenebilir.

Bu kontroller, SDK paketini oluşturmak için ve uygulama mağazasına yükleme sırasında SDK'nın kullandığı tüm derleme zamanı araçları tarafından 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ünde. Platform etkinliği, uygulamanın aktivitelerinin birinden başlar ve uygulama görevinin bir parçasıdır. FLAG_ACTIVITY_NEW_TASK desteklenmiyor.

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

Etkinlik isteme akışı aşağıdaki grafikte gösterilmektedir.

Diyagram
Şekil 4. Bir etkinlik başlatma akışını gösteren adım sırası şeması.

Geliştirme

Bu teklifteki temel prensiplerden biri, geliştirici ekosistemi üzerindeki etkiyi mümkün olduğunca en aza indirmektir. Bu teklif, geliştiricilere yeniden uygulama ve SDK yazmak, derlemek ve hata ayıklamak için kapsamlı bir geliştirme aracı seti sunar. Bu teklifin bütünlüğünü sağlamak için RE uygulamaları ve SDK'larının yapılandırma, yazma ve oluşturma biçiminde bazı değişiklikler yapılmıştır.

Yazma

Android Studio ve ilgili araçlar, SDK Çalışma Zamanına duyarlı olacak şekilde güncellenecek. Böylece geliştiricilerin RE uygulamalarını ve SDK'larını doğru şekilde yapılandırmalarına ve eski veya desteklenmeyen çağrıların, uygun olduğunda yeni alternatiflere güncellenmesine yardımcı olacak. Oluşturma aşamasında, teklifimiz geliştiricilerin uygulaması gereken bazı adımlar vardır.

Uygulama geliştiriciler

Uygulamaların, uygulama manifestlerinde RE SDK ve SDK sertifikası bağımlılıklarını belirtmesi gerekir. Önerimizde bunu uygulama geliştiricisinin doğru 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ştiricisinin bu değeri ilgili uygulama mağazası üzerinden edinmesini ve kaydetmesini öneririz.

Bu, RE olsun veya olmasın, yalnızca uygulama mağazası tarafından dağıtılan SDK'lar için geçerlidir. SDK'lara statik olarak bağlantı veren uygulamalar mevcut bağımlılık mekanizmalarını kullanır.

Geliştiricilere yönelik minimum etki hedefimiz doğrultusunda, SDK Çalışma Zamanı'nı destekleyen bir hedef API düzeyi belirtildiğinde, uygulama geliştiricilerinin, derlemenin SDK Çalışma Zamanı'nı destekleyen veya desteklemeyen cihazlarda çalışması fark etmeksizin yalnızca tek bir derlemeye sahip olması önemlidir.

SDK geliştiricileri

Önerdiğimiz tasarımında, RE SDK geliştiricilerinin manifest dosyasındaki SDK veya kitaplık varlığını temsil eden yeni bir öğeyi açıkça beyan etmeleri gerekir. Ayrıca, bağımlılığa benzer bir değer grubunun yanı sıra bir alt sürümün sağlanması gerekir:

  • 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ığı olarak başka RE SDK'ları varsa bunları da uygulama geliştiricilerin aynı bağımlılığı bildirme şekline benzer şekilde tanımlamaları gerekecektir. RE SDK'ları olmayan RE SDK'ları, bunları statik olarak bağlar. Bu durum, SDK Çalışma Zamanı'nın desteklemediği işlevler veya uygulama sürecinde çalışması gerektiğinde derleme zamanında veya test geçerken tespit edilebilecek sorunlara yol açabilir.

RE SDK geliştiricileri büyük olasılıkla Android 12 veya önceki sürümler gibi ve belgenin Sistem Sağlığı bölümünde belirtildiği üzere, oldukça sınırlı sistem kaynaklarına sahip giriş düzeyindeki Android 13 cihazları YENİDEN etkinleştirilmemiş cihazları desteklemeye devam etmek isteyeceklerdir. SDK geliştiricilerinin RE ve RE olmayan ortamları desteklemek için tek bir kod tabanı edinebilmelerini sağlayacak yaklaşımlar üzerinde çalışıyoruz.

Binalar

Uygulama geliştiriciler

Uygulama geliştiricilerin, oluşturma adımında küçük bir değişiklik yaşayacağını tahmin ediyoruz. İster yerel olarak dağıtılmış, ister uygulama mağazasından dağıtılmış (RE veya değil) için SDK bağımlılıklarının hata analizi, derleme ve derlemeler için makinede bulunması gerekir. Android Studio'nun bu ayrıntıları normal kullanım esnasında uygulama geliştiriciden soyutlanmasını ve mümkün olduğunca şeffaf yapmasını öneriyoruz.

Bir DEBUG derlemesinin, hata ayıklama için DEBUG derlemesinde bulunan tüm kod ve sembolleri içermesi gerektiğini beklesek de RELEASE derlemeleri, isteğe bağlı olarak uygulama mağazasında dağıtılan tüm SDK'ların (RE veya değil) nihai yapıdan kaldırılmasını sağlayabilir.

Tasarım aşamasının daha başlarındayız ve yeni gelişmeler gerçekleştikçe sizinle daha fazla bilgi paylaşacağız.

SDK geliştiricileri

Bir SDK'nın RE ve RE olmayan sürümlerinin dağıtım için tek bir yapıda birleştirilmesini sağlayacak bir yol üzerinde çalışıyoruz. Bu durum, uygulama geliştiricilerin bir SDK'nın RE ve RE olmayan sürümleri için ayrı derlemeleri destekleme ihtiyacını ortadan kaldırır.

Uygulamalarda olduğu gibi, uygulama mağazasında dağıtılan tüm bağımlılık SDK'larının hata ayıklama, derleme ve derlemeler için makinede bulunması gerekir ve Android Studio'nun bunu sorunsuz bir şekilde kolaylaştırmasını bekleriz.

Test etme

Uygulama geliştiriciler

Teklifimizde açıklandığı gibi, uygulama geliştiriciler Android 13 çalıştıran cihazlarda uygulamalarını normalde olduğu gibi test edebilecektir. Uygulama, derlendikten sonra RE cihazına veya emülatöre yüklenebilir. Bu yükleme işlemi, SDK'lar ister uzaktan SDK deposundan ister derleme sistemindeki önbellekten alınmış olsun, cihaz veya emülatör için doğru SDK'ların SDK Çalışma Zamanı'na yüklenmesini sağlar.

SDK geliştiricileri

SDK geliştiricileri 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 ve uygulama içi doğrulama, hem RE hem de RE olmayan uygulamalar için tek bir derleme yapısıyla yukarıda uygulama geliştiriciler için belirtilen adımları uygular. SDK geliştiricileri, SDK Çalışma Zamanı'nda olsun ya da olmasın kodlarını kontrol edebilir ancak gelişmiş hata ayıklama ve profil çıkarma araçlarıyla ilgili bazı sınırlamalar olabilir. Bu, etkin bir araştırma alanıdır.

Dağıtım

Bir uygulamanın SDK'larından ayrılmasına yönelik tasarım teklifimiz, SDK'ların uygulama mağazasında dağıtılmasına olanak sağladı. Bu, genel bir olasılıktır, belirli bir uygulama mağazasına özel değildir. Avantajları açıktır:

  • SDK'ların kalitesini ve tutarlılığını sağlama.
  • SDK geliştiricileri için yayınlamayı kolaylaştırın.
  • SDK küçük sürüm güncellemelerinin yüklü uygulamalara sunulmasını hızlandırma.

Bir uygulama mağazasının SDK dağıtımını desteklemek için aşağıdaki özelliklerin çoğunu sağlaması gerekir:

  • SDK geliştiricilerinin, uygulama mağazasından dağıtılabilen SDK'larını mağazaya yüklemesine, güncellemesine, geri almasına ve muhtemelen kaldırmasına olanak tanıyan bir mekanizma.
  • Bir SDK'nın bütünlüğünü ve kaynağını, ayrıca bir uygulamayı ve kökenini güvence altına almak ve bağımlılıklarını çözmek için kullanılan bir mekanizma.
  • Bunları tutarlı bir şekilde güvenilir ve yüksek performanslı bir şekilde cihazlara dağıtmak için kullanılan bir mekanizma.

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

SDK çalışma zamanında kodların karşılaştığı kısıtlamaların, Android'in sonraki sürümleriyle birlikte gelişmesini bekliyoruz. Uygulama uyumluluğu sağlamak amacıyla bu kısıtlamaları belirli bir SDK düzeyinde ana hat modül güncellemeleriyle değiştirmeyeceğiz. Belirli bir targetSdkVersion ile ilişkilendirilen davranış, bu targetSdkVersion için sunulan destek, uygulama mağazası politikası aracılığıyla kullanımdan kaldırılana kadar korunur ve targetSdkVersion desteğinin sonlandırılması, uygulamalara kıyasla daha hızlı gerçekleşebilir. Kısıtlamaların, özellikle ilk birkaç sürümde, Android SDK sürümlerinde sık sık değişeceğini unutmayın.

Buna ek olarak, harici ve dahili test kullanıcılarının Android'in sonraki sürümü için önerilen kısıtlama kümesini alan bir gruba katılmalarını sağlayacak bir canary mekanizması oluşturuyoruz. Bu, kısıtlama grubunda önerilen değişikliklerle ilgili geri bildirim ve güven almamıza yardımcı olur.

SSS

  1. Reklamcılıkla ilgili SDK nedir?

    Reklamla ilgili SDK, reklamverene ait olmayan uygulamalarda ticari amaçlı mesajlarla kullanıcıları hedeflemenin herhangi bir kısmını kolaylaştıran SDK'dır. Bunlarla sınırlı olmamakla birlikte, sonradan 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ıkla mücadele SDK'ları, etkileşim SDK'ları ve ilişkilendirme SDK'ları buna dahildir.

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

    İlk odak noktası reklamlarla ilgili SDK'lar olsa da gizlilik yaklaşımını benimseyen ve yukarıda belirtilen koşullar altında çalışabileceğine inanan reklamlarla alakalı olmayan SDK'ların geliştiricileri, SDK Çalışma Zamanında çalışan SDK'ları hakkında geri bildirim paylaşabilirler. 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 işleme hızında iletişim gerektiren SDK'lar için muhtemelen uygun değildir.

  3. Bir işlemin Java tabanlı çalışma zamanı içinde izolasyon yerine neden işlem izolasyonunu tercih etmelisiniz?

    Şu anda Java tabanlı çalışma zamanı, Android kullanıcılarının istediği gizlilik garantileri için gerekli olan güvenlik sınırlarını kolayca sağlayamamaktadır. Böyle bir şeyi uygulamaya çalışmak muhtemelen başarı garantisi olmadan yıllarca süren bir çalışma gerektirecektir. Bu nedenle, Özel Korumalı Alan, zaman içinde test edilmiş ve iyi anlaşılmış bir teknoloji olan kullanım süreci sınırlarını kullanır.

  4. SDK'ları SDK Çalışma Zamanı sürecine taşımak, indirme boyutundan veya alandan tasarruf sağlar mı?

    Aynı sürümde çalışma zamanı özellikli SDK'larla birden fazla uygulama entegre edilirse bu durum, indirme boyutunu ve disk alanını azaltabilir.

  5. SDK'ların, SDK Çalışma Zamanında ne tür uygulama yaşam döngüsü olaylarına erişimi olur (uygulamanın arka plana geçmesi gibi)?

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