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

Geri bildirim gönderin

Android platformu, işlem sınırlarıyla 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 kodlarını genellikle reklam SDK'ları veya analiz SDK'ları gibi SDK'lar biçiminde içermesi yaygın bir uygulamadır. Bu yeniden kullanım sayesinde uygulama geliştiricileri, uygulamalarının farklılaşmasına odaklanabilmenin yanı sıra uygulama çalışmalarını kendi başlarına yapabileceklerinin ötesine ölçeklendirmek için konu uzmanlarının çalışmalarından da yararlanabiliyor.

Ç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 aynı ayrıcalıklarını ve izinlerinin yanı sıra ana makine uygulamasının bellek ve depolama alanına erişimi de devralır. Bu mimari, SDK'ların ve uygulamaların esnek bir şekilde entegre edilmesine olanak tanırken, aynı zamanda açıklanmayan kullanıcı verilerinin toplanması ve paylaşılması potansiyeli de oluşturur. Dahası, uygulama geliştiriciler bir üçüncü taraf SDK'nın işlevselliğinin ve eriştiği verilerin kapsamıyla ilgili tam olarak haberdar olmayabilir. Bu durum, uygulamalarının veri toplama ve paylaşım yöntemlerini hesaba katmayı 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 teminatları 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ımla ilgili olarak, mobil uygulama reklamcılığı topluluğundan aktif olarak geri bildirim alıyoruz. Ek kullanım alanları için destek de dahil olmak üzere SDK Çalışma Zamanı'nın gelecekteki yinelemelerini şekillendirmeye yardımcı olmak amacıyla geniş geliştirici topluluğundan gelen geri bildirimleri de memnuniyetle karşılıyoruz.

Hedefler

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

  • İşlem izolasyonu, iyi tanımlanmış API ve veri erişim denetimi sayesinde kullanıcının uygulama verilerine üçüncü taraf SDK'lar tarafından gizli erişimi ve paylaşımı azaltın. Bu belgenin ayrı bir bölümünde işlem izolasyonu hakkında daha fazla bilgi edinebilirsiniz.
  • SDK'ların benzersiz ve kalıcı tanımlayıcılara erişimini sınırlandırarak üçüncü taraf SDK'lar tarafından bir kullanıcının uygulama kullanımının gizlice izlenmesini azaltın.
  • Uygulama geliştiricilerin ve son kullanıcıların yükünü 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 anlaması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, medyaların görüntülendiği uzaktan görüntülemeler üzerinde tam kontrol sahibi olarak 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 en aza indirin.

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

Teklif edilen SDK Çalışma Zamanı, uyumlu SDK'ların (bu belgenin geri kalanında çalışma zamanı etkin (RE) SDK'ları olarak anılan) uygulama için ayrı bir süreçte çalışabilmesini sağlar. Platform, uygulamanın işlemi 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üne bakın. RE olmayan SDK'lar bugün olduğu gibi uygulama işleminde kalırlar. Aşağıdaki diyagramlarda bu değişiklikler gösterilmektedir:

Uygulama sürecini çalıştıran her şeyi gösteren önceki diyagram
SDK Arama Zamanı'na SDK çağrı kodu ve bu koddan çağrı alan SDK'lar eklenmeden önce, bunların tümü uygulamanın işleminde yer alır

Uygulama süreci ile SDK çalışma zamanı süreci arasında bölünen süreçleri gösteren diyagramdan sonra
SDK çağrı kodu SDK Çalışma Zamanı'na eklendikten sonra, uygulamanın ön plan işleminde SDK çağrı kodu, SDK arayüzleriyle iletişim kurar. Bu arayüzler, daha sonra SDK'ların kendilerini çağırmak için işlem sınırını SDK Çalışma Zamanı sürecine aktarır.

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ı motive etmektedir. Teklifimiz, bir uygulamanı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ı olur ve uygulama mağazalarının, 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ğlanmasına ve uygulamalarıyla birlikte paketlenmesine gerek kalmayacak. 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ı kullanarak bunları uygulama mağazasından indirebilir.

Bu yeni dağıtım mekanizması, SDK geliştiricilerinin SDK'larında kesin değişiklikler yapmalarına (yani API'lerde veya anlamlarında hiçbir değişiklik yapmadıklarında) ve uygulama geliştiricilerin müdahalesi olmadan cihazlara dağıtmalarına olanak tanır. Bu çalışmayan SDK değişiklikleri, uygulama geliştiricilerin uygulamalarını yeni SDK'larla yeniden oluşturmasını ya da son kullanıcıların uygulamalarını güncellemesini beklemek zorunda kalmadan dağıtılabilir ya da geri çekilebilir. Çarpıcı değişikliklerin uygulama geliştiricileri tarafından yine de güncellenmesi gerekir ancak SDK geliştiricileri en son bölünmeyen değişikliklerini ve düzeltmeleri, ideal olarak sürüm desteğini en aza indirerek daha hızlı ve daha tutarlı bir şekilde daha fazla kişiye sunabilir.

Aşağıdaki diyagramlarda SDK dağıtımında önerilen değişiklikler gösterilmiştir:

Diyagramdan önce
SDK Çalışma Zamanı kullanıma sunulmadan önce geliştiriciler SDK'larını doğrudan uygulamalara gönderirler.

Diyagramdan sonra
SDK Çalışma Zamanı'nın kullanıma sunulmasından sonra SDK geliştiricileri, SDK'larını uygulama mağazasında yayınlamak için SDK yükleme kullanıcı arayüzünü kullanacaktı. Ardından uygulama mağazası, son kullanıcı cihazlarına uygulamaların ve SDK bağımlılıklarının dağıtımını 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 sunulan ilk tekliftir. 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ş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ümlerini 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 ilk tasarım teklifidir ve bunun ekosistemin bazı üyeleri için anlamlı bir değişiklik olabileceğinin farkındayız. Bu nedenle aktif bir şekilde geri bildirim topluyor ve sorun izleyici üzerinden geri bildirim göndermenizi rica ediyoruz.

Erişim

Bir sistemin gizliliğinin yönetilmesi, farklı tarafların farklı kaynaklara nasıl erişebileceğini yönetmeyi gerektirir. Gizlilik değeri teklifimizi karşılamak için uygulamalara, SDK'lara ve kullanıcı verilerine erişim modelini, hassas olabilecek verilere açıklanmayan erişimi önlemek amacıyla en az ayrıcalık ilkesine uygun şekilde 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 yaptığımız ön araştırmaya dayanarak, SDK Çalışma Zamanı'ndaki SDK'ların varsayılan olarak aşağıdaki izinlere erişebilmesini öneririz:

  • INTERNET: Bir web hizmetiyle iletişim kurabilmek için internet erişimi.
  • ACCESS_NETWORK_STATE: Ağlarla ilgili bilgilere erişin.
  • Uygulamalar arası tanımlayıcılara erişmeye 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 altına alınır.
  • BIND_GET_INSTALL_REFERRER_SERVICE: Bir uygulamanın yükleme kaynağını ilişkilendirmek için Google Play InstallReferrer API'yi kullanabilme.

Şu anda ek izinlerin yetkilendirilip yetkilendirilmeyeceğini ve nasıl verileceğ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ırdık. Bu izin grubunun karşılayamadığı kullanım alanları hakkında geri bildirim isteriz.

Bellek

SDK Çalışma Zamanı, kendine ait bir işlem 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. En az ayrıcalık ilkesine uygun hareket etmek için bu varsayılan davranışı sürdürmeyi öneriyoruz.

Depolama

Bu teklif, SDK'ların normal çalışmalarında depolama alanına erişme ihtiyacını dengelemeyi ve kalıcı depolama alanı kullanarak uygulamalar arası ve işlemler arası izlemeyi en aza indirmeyi amaçlamaktadır. Günümüzde depolama alanına erişimle ilgili aşağıdaki güncellemeyi öneririz:

  • Bir uygulama, SDK depolama alanına doğrudan erişemeyecektir 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 tarafından erişilebilen depolama alanı hem de belirli bir SDK'ya özel depolama alanı olur.

Mevcut depolama alanı modelinde olduğu gibi, depolama alanının da kendi boyutuyla ilişkili herhangi bir sınır yoktur. SDK'lar, öğeleri önbelleğe almak için depolama alanını kullanabilir. SDK aktif 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 (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. Burada, bu dengeyi sağlamak için çalışma zamanı ortamında yapılacak bir dizi güncelleme teklif ediyoruz.

Kod

Android kodu (uygulamalar ve SDK'lar), kodun Kotlin veya Java'da 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 alternatifleriyle (özellikle yerel kod) karşılaştırıldığında sunduğu doğrulanabilirlik özellikleri, işlev ve gizliliği uygun şekilde dengeliyor. Ç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ı bulunduğunun farkındayız. Yerel kod kullanıldığında, Android SDK'nın yerleşik SQLite sürümü gibi bir alternatifle değiştirilmesi gerekir.

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 hizmetlerine, dosyalara, cihazlara ve diğer işlemlere erişim denetimini yönetmesine olanak tanır. Geliştirmeye çalıştığımız gizlilik korumalarındaki atlatmayı en aza indirirken SDK kullanım alanlarının çoğunluğunu korumak 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 hizmetleri kümesine 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ılmasına izin verilir. Ancak bir SDK'nı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'lerin tüm teklifini gelecekteki bir güncellemede paylaşacağız.

Ayrıca son Android platform sürümleri, gizliliği iyileştirmek amacıyla 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ı öneririz.

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ının atılmasına 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. Yani uygulama ön plana girdiğinde veya ön plana girdiğinde, kapatıldığında ya da bellek baskısı nedeniyle işletim sistemi tarafından zorla durdurulduğunda uygulama 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şikliklerinin yapılmasını 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 SDK'daki işlenmemiş bir istisna nedeniyle işletim sistemi tarafından sonlandırılabilir.

    Android 13'te, bir uygulama ön plandayken SDK Çalışma Zamanı yüksek öncelikte çalışır ve büyük olasılıkla feshedilemez. Uygulama arka plana gittiğinde SDK Çalışma Zamanı sürecinin önceliği düşer ve uygulama fesih için uygun hale gelir. Uygulama geri dönse bile SDK Çalışma Zamanı sürecinin önceliği düşük kalır. Sonuç olarak, uygulamayla karşılaştırıldığında büyük olasılıkla bellek baskısı altında sonlandırılır.

    Android 14 ve sonraki sürümlerde uygulamanın işlem öncelikleri ile SDK Çalışma Zamanı birbiriyle uyumludur. 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 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 sonlandırıldığını 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 isteğinde bulunmak için başka bir girişimde bulunabilir.
    • Android 14'te, SDK Çalışma Zamanı, SDK'lar yüklenirken sona ererse ve uygulama geliştiricisi daha önce 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ükleyen uygulama işlemleri sonlandırılıp 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 DeadObjectException hatası verir.

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

    Sürekli hata oluşması durumunda uygulama geliştirici, SDK olmadan kontrollü bir kalite düşüşü planlamalı veya SDK, uygulamanın temel işlevi açısından kritik öneme sahipse kullanıcıyı bilgilendirmelidir. Bu uygulamadan SDK'ya etkileşim hakkında daha fazla ayrıntı için bu belgenin iletişim bölümüne bakın.

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

Özel durumlar

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

  • Birden fazla uygulama aynı UID'yi paylaşırsa SDK Çalışma Zamanı düzgün çalışmayabilir. Paylaşılan UID'ler için destek ileride eklenebilir.
  • Birden fazla işlem içeren uygulamalarda SDK'yı yükleme işlemi ana işlemde yapılmalı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çinden oluşturacağı ancak medyanın uygulamaya özgü bir görünümde oluşturulmasına izin vermek için SurfaceControlViewHost API'sinin kullanılacağı bir uzaktan oluşturma yaklaşımı öneririz. Bu, SDK'ya bu medyayı kullanıcı için gizli olacak şekilde oluşturma olanağı 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, bir uygulama içindeki oynatıcıda gösterilen ve videoyla birlikte yayınlanan reklamlardır. Videonun SDK'daki bir oynatıcı veya görüntüleme yerine, 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 destekleyecek mekanizmalar araştırıyoruz.

Sistem durumu

SDK Çalışma Zamanı'nın son kullanıcı cihazları üzerindeki sistem sağlığını en aza indirmeye çalışıyoruz ve bunun için çeşitli yollar 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ı desteklemeyecektir. SDK Çalışma Zamanı'nı başarıyla kullanmak için gereken minimum koşulları yakında paylaşacağız.

İletişim

Şu anda uygulamalar ve SDK'lar aynı süreçte çalıştığından, uygulamalar arasındaki iletişim kısıtlanmaz ve aracı olmadan gerçekleşir. Ayrıca Android, iletişim SDK'larla başlayıp bitse bile 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 arasında SDK'lar arasında açıklanmayan veri paylaşımına imkan tanır. Bu iletişimin değeri ile belirlediğ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'nın API'sinde ise kullanıcılara yönelik farklılaşma ve yeniliğin büyük bir kısmı bulunur. Burada SDK'ların yenilik yapma ve farklarını ortaya koyma becerisini korumayı amaçlıyoruz. Sonuç olarak teklifimiz, SDK'ları API'leri uygulamalara sunma konusunda destekler ve uygulamaların tüm bu yeniliklerden faydalanabilmesini sağlar.

SDK Çalışma Zamanı'nın süreç sınırı yapısı göz önünde bulundurulduğunda, API çağrılarını ve 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 kaynak oluşturma araçları tarafından üretileceğini düşünüyoruz.

Bu teklifle uygulama ve SDK geliştiricilerinin ortak metin düzenleme işini kaldırırken SDK geliştiricilerine de 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 halinde API tanım dilinin ve araçlarının sizin girdilerinizle tasarlanması gerekir.

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

  • Uygulama, geri çağırma yaparak 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 modeline 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 yeni süreçler arası 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. Aşağıdaki şemada kullanmayı düşündüğümüz bir yaklaşım gösterilmektedir:

Şema
Uygulama ve SDK başlatma sırasında uygulama ile SDK arasındaki 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şimde bulunmak için yeni API'leri ortaya çıkarır.

Önceki şekilde bulunan grafikte, karıştırma katmanı olmadan, daha düşük düzeyde uygulamadan SDK'ya iletişim gösterilmektedir.

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, manifest dosyalarına yüklemeyi amaçladıkları SDK'ları belirtir ve yüklenmesine izin verilen tek SDK'lar bu olur.

    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ğini bildirir 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ğlı hizmetler rehberi, IBinder hizmetini sağlamanın farklı yollarını sağlar. Hangi yöntemi seçerseniz seçin, SDK ile arayan uygulama arasında tutarlılık sağlanmalıdır. Diyagramlarda ö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 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 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() işlevini ç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)
    

Teklifimiz, IBinder ve requestSurfacePackage() API'lerinin genel olmasıdır ve doğrudan uygulamalar tarafından çağrılmak üzere tasarlanmamıştır. Bunun yerine bu API'ler, uygulama geliştiricilerin üzerindeki yükü azaltmak için yukarıda açıklanan oluşturulan API referansı tarafından bir "şim" 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'nın bileşen SDK'lardan oluşacak şekilde tasarlanması halinde ortaya çıkabilir. Bu durum, çağrı yapan uygulamadan gelen bir isteği yerine getirmek 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ı için etkin olduğunda. Bu durumda her iki SDK da tüm korumalarıyla SDK Çalışma Zamanında çalışır. SDK'lar şu anda bir uygulama içinde yaptıkları gibi iletişim kuramazlar. Sonuç olarak, yüklenen tüm RE-SDK'lar için SandboxedSdk nesnelerinin getirilmesini sağlamak amacıyla SdkSandboxController içindeki bir API eklenmiştir. Bu, RE-SDK'nın SDK Çalışma Zamanında yüklenen diğer SDK'larla iletişim kurmasını sağlar.
  • Çalışma zamanı özelliğinin yalnızca bir SDK'sı etkin olduğunda.
    • Çağrı yapan SDK uygulama içinde çalışıyorsa bu, SDK Çalışma Zamanı içinde ikinci SDK'ya çağrı yapan uygulamanın kendisinden farklı şekilde çalışmaz.
    • Çağrı yapan SDK SDK Çalışma Zamanı içinde çalışıyorsa bu teklif, uygulama-SDK bölümünde açıklanan IBinder kullanan ve uygulamadaki kodun sağlanan geri çağırmalarla dinlediği, işlediği ve yanıt veren bir yöntemi kullanıma sunması önerilir.
    • Çalışma zamanı özelliğinin etkin olmadığı reklam SDK'ları kendilerini kaydedemeyebilir. Uygulamanın doğrudan bağımlılıkları olarak iş ortağı veya uygulama SDK'larını içeren ve kayıt işlemini gerçekleştiren bir arabulucu SDK'sının oluşturulmasını öneririz. Bu aracı SDK'sı, çalışma zamanının etkin olmadığı SDK'lar veya diğer uygulama bağımlılıkları ile bağdaştırıcı görevi gören çalışma zamanı özellikli arabulucu arasında iletişim kurar.

SDK-SDK iletişimi için ayarlanan özellik aşağıdaki kategorilere ayrılmıştır:

  • SDK Çalışma Zamanı içinde SDK-SDK iletişimi (en son Geliştirici Önizlemesinde mevcuttur)
  • Uygulama ile SDK Çalışma Zamanı arasında SDK-SDK iletişimi (en son Geliştirici Önizlemesinde mevcuttur)
  • Uyumlulaştırma için görüntülemeler ve uzaktan oluşturma nasıl çalışmalıdır? (geliştirme aşamasında teklif)

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

  1. Uyumlulaştırma ve Teklif Verme. Birçok reklam SDK'sı, uyumlulaştırma veya teklifli sistem özelliği sunar. Bu özellikte SDK, reklam gösterimi (uyumlulaştırma) veya açık artırma yürütmek için sinyal toplama (teklifli sistem) için diğer SDK'ları çağırır. Genellikle koordine SDK, koordine SDK tarafından sağlanan bir bağdaştırıcı aracılığıyla diğer SDK'ları çağırır. Yukarıdaki temel unsurlara göre, koordine SDK'nın normal çalışma için tüm RE ve RE olmayan SDK'lara erişebilmesi gerekir. 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üreci aracılığıyla uygulama geliştiricisine sunulan nihai özellik grubunu belirler. Kayıt ve keşif temel öğelerinin bu kullanım alanını etkin hale getirmesi beklenir.
  3. Yayıncı abonelik modelleri. Bazı SDK'lar, diğer SDK'ların veya uygulamaların geri çağırmalar aracılığıyla bildirimler için abone olabileceği etkinliklerin merkezi bir yayıncısına sahip 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 birinin çalışma zamanı özellikli bir SDK olduğu ve açıklanmamış veri paylaşımı için potansiyel bir vektör olduğu durum budur. 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ı oluşturamaz. 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 etkinliği 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 hizmet listesi başlatabilir veya izin verilenler listesine bağlanabilir.
  • SDK, yalnızca sistemin bir alt kümesine (ContentProvider (ör. com.android.providers.settings.SettingsProvider) erişebilir. Burada 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üklemede başarısız olan etiketler SDK Çalışma Zamanı'nda desteklenmez. Yüklemede başarısız olmayan ancak sessizce yoksayılan etiketler, gelecekteki Android sürümlerinde desteklenebilir.

Bu denetimler, 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 etkinlikler oluşturur ve bunları SDK'larla paylaşır.

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

Bir SDK'nın etkinlik 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) yöntemini ç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.

Şema
Aktivite başlatma akışını gösteren adım sırası şeması.

Geliştirme

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

Yazma

Android Studio ve ilgili araçlar, SDK Çalışma Zamanına duyarlı olacak şekilde güncellenecek. Bu güncellemeyle geliştiricilerin RE uygulamalarını ve SDK'larını doğru şekilde yapılandırmalarına yardımcı olacak ve eski ya da desteklenmeyen çağrıların, uygun olduğu durumlarda yeni alternatiflerine güncellenmesini sağlayacak. 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ı belirtmeleri gerekir. Önerimizde bunu, uygulama geliştiricisinin sağladığı bilgi kaynağı olarak ele alıyoruz. Örneğin:

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

Bu, yalnızca uygulama mağazası tarafından dağıtılan SDK'lar için geçerlidir. RE'de olup olmadığına bakılmaksızın bu kural uygulanır. SDK'lara statik olarak bağlantı veren uygulamalar mevcut bağımlılık mekanizmalarını kullanacaktır.

Geliştiricilere yönelik minimum etki hedefimiz göz önünde bulundurulduğunda, SDK Çalışma Zamanı'nı destekleyen bir hedef API düzeyi belirtildiğinde, uygulama geliştiricilerin yalnızca tek bir derlemeye sahip olması gerekir. Bu derleme, SDK Çalışma Zamanı'nı destekleyen veya desteklemeyen cihazlarda çalışır.

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 etmesi gerekir. Ayrıca, bağımlılığa benzer bir değer grubunun yanı sıra 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ığı tanımlama şekline benzer şekilde tanımlamaları gerekir. RE SDK'larına bağlı olmayan RE SDK'ları, bunları statik olarak bağlar. Bu durum, RE olmayan SDK'lar, SDK Çalışma Zamanı'nın desteklemediği bir işlev gerektiriyorsa veya uygulama işleminde çalışması gerekiyorsa derleme zamanında veya test geçerken algılanabilecek sorunlara yol açabilir.

RE SDK geliştiricileri muhtemelen Android 12 veya önceki sürümler gibi ve dokümanın Sistem Sağlığı bölümünde belirtildiği gibi, çok sınırlı sistem kaynaklarına sahip giriş düzeyindeki Android 13 cihazları desteklemeye devam etmek isteyeceklerdir. SDK geliştiricilerin, RE ve RE olmayan ortamları desteklemek için tek bir kod tabanı edinebilmelerini sağlayacak yaklaşımlar üzerinde çalışıyoruz.

Derlemeler

Uygulama geliştiriciler

Uygulama geliştiricilerin, oluşturma adımında çok az değişiklik yaşayacağını düşünüyoruz. Makinede hata analizi, derleme ve derlemeler için SDK bağımlılıklarının yerel olarak dağıtılmış veya uygulama mağazasında dağıtılmış (RE veya değil) olması gerekir. Android Studio'nun normal kullanımla bu bilgileri uygulama geliştiriciden soyutlamasını ve mümkün olduğunca şeffaf yapmasını öneriyoruz.

Bir HATA AYIKLAMA derlemesinin, hata ayıklama açısından HATA AYIKLAMA derlemesinde mevcut olacak tüm kod ve sembolleri içermesi gerektiğini düşünsek de RELEASE derlemelerinde, isteğe bağlı olarak uygulama mağazasında dağıtılan tüm SDK'lar (RE veya olmayan) nihai yapıdan kaldırılır.

Tasarım aşamamızın daha başındayız ve yeni videolar ortaya çıktıkça 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ı önler.

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

Test

Uygulama geliştiriciler

Teklifimizde açıklandığı gibi, uygulama geliştiricileri Android 13 çalıştıran cihazlarda uygulamalarını normalde olduğu gibi test edebilecektir. Kullanıcılar uygulamalarını derledikten sonra, bir RE cihazına veya emülatöre yüklenebilir. SDK'lar ister uzaktan SDK deposundan ister derleme sisteminden önbellekten çekilmiş olsun, bu yükleme işlemi sayesinde cihaz veya emülatör için SDK Çalışma Zamanı'na doğru SDK'ların yüklenmesi sağlanır.

SDK geliştiricileri

SDK geliştiricileri genellikle geliştirmelerini test etmek için cihazlarda ve emülatörlerde dahili test uygulamaları 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ı adım adım ilerletebilir. Ancak gelişmiş hata ayıklama ve profil çıkarma araçlarında 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, belirli bir uygulama mağazasına özel olmayan, genel bir olasılıktır. Avantajları bellidir:

  • SDK'ların kalitesini ve tutarlılığını sağlamak.
  • SDK geliştiricileri için yayınlamayı kolaylaştırın.
  • SDK alt 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ına dağıtılabilir SDK'larını mağazaya yükleme, güncelleme, eski haline getirme ve gerektiğinde kaldırmalarını sağlayan bir mekanizma.
  • Bir SDK'nın bütünlüğünü, kökenini, uygulamasını ve kaynağını sağlama ve bağımlılıklarını çözme mekanizması.
  • Bunları cihazlara sürekli olarak güvenilir ve yüksek performanslı bir şekilde dağıtan 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ümlerinde değişmesini bekliyoruz. Uygulama uyumluluğunu sağlamak amacıyla belirli bir SDK seviyesi için bu kısıtlamaları ana hat modül güncellemeleriyle değiştirmeyeceğiz. Belirli bir targetSdkVersion ile ilişkili davranış, uygulama mağazası politikası aracılığıyla targetSdkVersion için sunulan destek kullanımdan kaldırılana kadar korunur ve targetSdkVersion desteğinin sonlandırılması, uygulamalara göre daha hızlı gerçekleşebilir. Özellikle ilk birkaç sürümde, Android SDK sürümlerinde kısıtlamalar sık sık değişir.

Buna ek olarak, harici ve dahili test kullanıcılarının Android'in yeni 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 sayede, kısıtlama grubunda önerilen değişikliklerle ilgili geri bildirim ve güven alabiliriz.

SSS

  1. Reklamcılıkla ilgili SDK nedir?

    Reklamla ilgili SDK, reklamverenin sahibi olmadığı uygulamalarda ticari amaçlarla kullanıcıları hedefleme işlemini herhangi bir kısmen kolaylaştıran bir SDK'dır. Bunlarla sınırlı olmamakla birlikte, 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ı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 yanlısı bir yaklaşım benimseyen ve yukarıda belirtilen koşullar altında çalışabileceğine inanan reklamla 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şime ihtiyaç duyan 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 seçmeniz gerekir?

    Şu anda Java tabanlı çalışma zamanı, Android kullanıcılarının istenen gizlilik güvenceleri için gereken güvenlik sınırlarını kolayca sağlamamaktadır. Böyle bir yöntemi uygulamaya çalışmak muhtemelen başarı garantisi olmadan birkaç yıllık bir çalışma gerektirir. Bu nedenle Özel Korumalı Alan, zamanla 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 edilmesini sağlar mı?

    Aynı sürümün çalışma zamanı özelliğinin etkin olduğu SDK'larla birden fazla uygulama entegre edilirse bu, indirme boyutunu ve disk alanını azaltabilir.

  5. SDK'ların SDK Çalışma Zamanı'nda, uygulamanın arka plana gitmesi gibi ne tür uygulama yaşam döngüsü etkinliklerine erişimi olur?

    İstemci uygulamasının uygulama düzeyindeki yaşam döngüsü olaylarında (ör. uygulamanın arka plana gitmesi, uygulamanın ön plana geçmesi) SDK çalışma zamanının bildirilmesi için tasarım desteği üzerinde etkin bir şekilde çalışıyoruz. Tasarım ve örnek kod, yakında yayınlanacak bir geliştirici önizlemesinde paylaşılacak.