SDK olmayan arayüzlerle ilgili kısıtlamalar

Platform, Android 9'dan (API düzeyi 28) itibaren uygulamanızın kullanabileceği SDK olmayan arayüzleri kısıtlar. Bu kısıtlamalar, bir uygulama SDK olmayan bir arayüze referans verdiğinde veya yansıtma ya da JNI kullanarak herkese açık kullanıcı adını almaya çalıştığında geçerli olur. Bu kısıtlamalar, kullanıcı ve geliştirici deneyimini iyileştirmeye, kullanıcılar için kilitlenme ve geliştiriciler için acil durumda kullanıma sunma risklerini azaltmaya yardımcı olmak amacıyla uygulanmıştır. Bu kararla ilgili daha fazla bilgi için SDK dışı arayüzlerin kullanımını azaltarak kararlılığı artırma bölümüne bakın.

SDK ve SDK olmayan arayüzleri birbirinden ayırt etme

Genel olarak, herkese açık SDK arayüzleri, Android çerçevesi Package Index'te belgelenen arayüzlerdir. SDK olmayan arayüzlerin işlenmesi, API'nin soyutladığı bir uygulama ayrıntısıdır. Bu nedenle bu arayüzler önceden haber verilmeden değiştirilebilir.

Kilitlenmeleri ve beklenmedik davranışları önlemek için uygulamalar, yalnızca SDK'daki sınıfların resmi olarak belgelenmiş bölümlerini kullanmalıdır. Bu aynı zamanda, yansıtma gibi mekanizmalar kullanarak bir sınıfla etkileşimde bulunduğunuzda SDK'da listelenmeyen yöntemlere veya alanlara erişmemeniz gerektiği anlamına gelir.

SDK olmayan API listeleri

Android'in her sürümünde ek SDK olmayan arayüzler kısıtlanır. Bu kısıtlamaların sürüm iş akışınızı etkileyebileceğini biliyoruz. Bu nedenle, SDK dışı arayüzlerin kullanımını tespit edecek araçlara sahip olmanızı, bize geri bildirim verme fırsatı tanımanızı ve yeni politikalarla ilgili plan yapıp ayarlama yapmanızı sağlayacak araçlara sahip olmanızı istiyoruz.

SDK dışı kısıtlamaların geliştirme iş akışınız üzerindeki etkisini en aza indirmek için SDK olmayan arayüzler, hedeflenen API düzeyine bağlı olarak kullanımlarının ne kadar sıkı kısıtlandığını tanımlayan listelere bölünür. Aşağıdaki tabloda bu listelerin her biri açıklanmaktadır:

Liste Kod etiketleri Açıklama
Engellenenler listesi
  • blocked
  • Kullanımdan kaldırıldı: blacklist
Uygulamanızın hedef API düzeyi ne olursa olsun kullanamayacağınız SDK olmayan arayüzler. Uygulamanız bu arayüzlerden birine erişmeye çalışırsa sistem hata verir.
Koşula bağlı olarak engellendi
  • max-target-x
  • Kullanımdan kaldırıldı: greylist-max-x

Android 9'dan (API düzeyi 28) başlayarak, her API düzeyinin SDK olmayan arayüzleri, bir uygulama bu API düzeyini hedeflediğinde kısıtlanır.

Bu listeler, söz konusu uygulama listedeki SDK olmayan arayüzlere artık erişememeden önce uygulamanın hedefleyebileceği maksimum API düzeyiyle (max-target-x) etiketlenir. Örneğin, Android Pie'de engellenmemiş ancak artık Android 10'da engellenmiş olan SDK olmayan bir arayüz, max-target-p (greylist-max-p) listesinde yer alır. Burada "p", Pie veya Android 9 (API düzeyi 28) anlamına gelir.

Uygulamanız hedef API düzeyiniz için kısıtlanmış bir arayüze erişmeye çalışırsa sistem, API, engellenenler listesinin parçasıymış gibi davranır.

Desteklenmiyor
  • unsupported
  • Kullanımdan kaldırıldı: greylist
Kısıtlanmamış ve uygulamanızın kullanabileceği SDK olmayan arayüzler. Ancak bu arayüzlerin desteklenmediğini ve önceden bildirimde bulunulmaksızın değişebileceğini unutmayın. Bu arayüzlerin, gelecekteki Android sürümlerinde bir max-target-x listesinde koşullu olarak engelleneceğini unutmayın.
SDK
  • public-api ve sdk
  • Kullanımdan kaldırıldı: public-api ve whitelist
Ücretsiz olarak kullanılabilen ve artık resmi olarak belgelenmiş Android çerçevesi Package Index kapsamında desteklenen arayüzler.
API'leri test etme
  • test-api
Dahili sistem testi için kullanılan arayüzler (ör. Uyumluluk Test Paketi (CTS)) aracılığıyla testi kolaylaştıran API'ler). Test API'leri, SDK'nın bir parçası değildir. Test API'leri, Android 11'den (API düzeyi 30) itibaren engellenenler listesine eklenir. Bu nedenle, hedef API düzeyleri ne olursa olsun uygulamaların bunları kullanmasına izin verilmez. Tüm test API'leri desteklenmez ve platform API düzeyi ne olursa olsun haber verilmeden değiştirilebilir.

Bazı SDK dışı arayüzleri de (uygulamanızın hedef API düzeyine bağlı olarak) kullanabilirsiniz, ancak herhangi bir SDK olmayan yöntem veya alanı kullanmak her zaman uygulamanızın bozulma riskini artırır. Uygulamanız SDK olmayan arayüzlere kullanıyorsa SDK arayüzlerine veya diğer alternatiflere geçiş planlamaya başlamalısınız. Uygulamanızdaki bir özellik için SDK olmayan arayüz kullanmanın alternatifini bulamıyorsanız yeni bir genel API isteğinde bulunmanız gerekir.

Bir arayüzün hangi listeye ait olduğunu belirleme

SDK olmayan arayüzlerin listeleri, platformun bir parçası olarak oluşturulmuştur. Her bir Android sürümü hakkında bilgi almak için aşağıdaki bölümlere bakın.

Android 14 (Beta)

Android 14 (API düzeyi 34) için SDK olmayan tüm arayüzleri ve bunlara karşılık gelen listelerini açıklayan aşağıdaki dosyayı indirebilirsiniz:

Dosya: hiddenapi-flags.csv

SHA-256 sağlaması: 7e00db074cbe51c51ff4b411f7b48e98692951395c5c17d069c822cc1d0eae0f

Android 14'te SDK dışı API listesinde yapılan değişiklikler hakkında daha fazla bilgi edinmek için Android 14'te SDK dışı arayüz kısıtlamalarıyla ilgili güncellemeler bölümüne göz atın.

Android 13

Android 13 (API düzeyi 33) için SDK dışı tüm arayüzleri ve bunlara karşılık gelen listelerini açıklayan aşağıdaki dosyayı indirebilirsiniz:

Dosya: hiddenapi-flags.csv

SHA-256 sağlaması: 233a277aa8ac475b6df61bffd95665d86aac6eb2ad187b90bf42a98f5f2a11a3

Koşullu olarak engellenen API'ler için önerilen genel API alternatifleri de dahil olmak üzere Android 13'te SDK dışı API listesindeki değişiklikler hakkında daha fazla bilgi edinmek için Android 13'te SDK dışı arayüz kısıtlamalarıyla ilgili güncellemeler bölümüne bakın.

Android 12

Android 12 (API düzeyi 31) için SDK dışı tüm arayüzleri ve bunlara karşılık gelen listelerini açıklayan aşağıdaki dosyayı indirebilirsiniz:

Dosya: hiddenapi-flags.csv

SHA-256 sağlaması: 40674ff4291eb268f86561bf687e69dbd013df9ec9531a460404532a4ac9a761

Android 12'de koşullu olarak engellenen API'ler için önerilen herkese açık API alternatifleri de dahil olmak üzere Android 12'de SDK dışı API listesindeki değişiklikler hakkında daha fazla bilgi edinmek için Android 12 için değişiklikleri listeleme bölümüne bakın.

Android 11

Android 11 (API düzeyi 30) için SDK olmayan tüm arayüzleri ve bunlara karşılık gelen listelerini açıklayan aşağıdaki dosyayı indirebilirsiniz:

Dosya: hiddenapi-flags.csv

SHA-256 sağlaması: a19d839f4f61dc9c94960ae977b2e0f3eb30f880ba1ffe5108e790010b477a56

Android 11'de koşullu olarak engellenen API'ler için önerilen, herkese açık API alternatifleri dahil olmak üzere Android 11'deki SDK dışı API listesindeki değişiklikler hakkında daha fazla bilgi edinmek için Android 11 için değişiklikleri listeleme bölümüne bakın.

Android 10

Android 10 (API düzeyi 29) için SDK olmayan tüm arayüzleri ve bunlara karşılık gelen listelerini açıklayan aşağıdaki dosyayı indirebilirsiniz:

Dosya: hiddenapi-flags.csv

SHA-256 sağlaması: f22a59c215e752777a114bd9b07b0b6b4aedfc8e49e6efca0f99681771c5bfeb

Android 10'da koşullu olarak engellenen API'ler için önerilen, herkese açık API alternatifleri dahil olmak üzere Android 10'da SDK dışı API listesindeki değişiklikler hakkında daha fazla bilgi edinmek için Android 10 için değişiklikleri listeleme bölümüne bakın.

Android 9

Android 9 (API düzeyi 28) için aşağıdaki metin dosyası, kısıtlanmamış (gri listeye alınmış) SDK olmayan API'lerin listesini içerir: hiddenapi-light-greylist.txt.

Engellenenler listesi (blacklist) ve koşullu olarak engellenen API'lerin listesi (koyu gri liste) derleme zamanında türetilir.

AOSP'den liste oluşturma

AOSP ile çalışırken, SDK olmayan tüm arayüzleri ve bunlara karşılık gelen listelerini içeren bir hiddenapi-flags.csv dosyası oluşturabilirsiniz. Bunu yapmak için AOSP kaynağını indirin ve ardından aşağıdaki komutu çalıştırın:

m out/soong/hiddenapi/hiddenapi-flags.csv

Ardından dosyayı şu konumda bulabilirsiniz:

out/soong/hiddenapi/hiddenapi-flags.csv

Kısıtlanmış SDK dışı arayüzlere erişildiğinde beklenen davranış

Aşağıdaki tabloda, uygulamanız engellenenler listesinde bulunan SDK olmayan bir arayüze erişmeye çalıştığında karşılaşabileceğiniz davranış açıklanmaktadır.

Erişim yöntemleri Sonuç
Bir alana referans veren Dalvik talimatı NoSuchFieldError atıldı
Bir yönteme referans veren Dalvik talimatı NoSuchMethodError atıldı
Class.getDeclaredField() veya Class.getField() kullanarak düşünme NoSuchFieldException atıldı
Class.getDeclaredMethod(), Class.getMethod() kullanarak düşünme NoSuchMethodException atıldı
Class.getDeclaredFields(), Class.getFields() kullanarak düşünme SDK üyesi olmayan üyeler sonuçlarda yok
Class.getDeclaredMethods(), Class.getMethods() kullanarak düşünme SDK üyesi olmayan üyeler sonuçlarda yok
env->GetFieldID() kullanan JNI NULL geri verildi, NoSuchFieldError atıldı
env->GetMethodID() kullanan JNI NULL geri verildi, NoSuchMethodError atıldı

Uygulamanızı SDK dışı arayüzler için test etme

Uygulamanızdaki SDK olmayan arayüzleri test etmek için kullanabileceğiniz birkaç yöntem vardır.

Hata ayıklaması yapılabilecek bir uygulama kullanarak test etme

Android 9 (API düzeyi 28) veya sonraki sürümleri çalıştıran bir cihazda ya da emülatörde hata ayıklaması yapılabilir bir uygulama oluşturup çalıştırarak SDK dışı arayüzleri test edebilirsiniz. Kullandığınız cihazın veya emülatörün, uygulamanızın hedef API düzeyiyle eşleştiğinden emin olun.

Uygulamanızda yapılan testlerde çalışırken, uygulamanız SDK olmayan belirli arayüzlere erişiyorsa sistem bir günlük mesajı yazdırır. Aşağıdaki ayrıntıları bulmak için uygulamanızın günlük mesajlarını inceleyebilirsiniz:

  • Tanımlayan sınıf, ad ve tür (Android çalışma zamanı tarafından kullanılan biçimde).
  • Erişim yöntemi: bağlantı oluşturma, düşünme kullanarak veya JNI kullanarak.
  • SDK olmayan arayüzün ait olduğu liste.

Çalışan uygulamanın PID'si altında görünen bu günlük mesajlarına erişmek için adb logcat kullanabilirsiniz. Örneğin, günlükteki bir giriş aşağıdaki gibi olabilir:

Accessing hidden field Landroid/os/Message;->flags:I (light greylist, JNI)

StrictMode API'sini kullanarak test etme

StrictMode API'yi kullanarak SDK olmayan arayüzleri de test edebilirsiniz. Bunu etkinleştirmek için detectNonSdkApiUsage yöntemini kullanın. StrictMode API'yi etkinleştirdikten sonra, özel işleme uygulayabileceğiniz bir penaltyListener kullanarak SDK dışı arayüzün her kullanımı için geri çağırma alabilirsiniz. Geri çağırmada sağlanan Violation nesnesi Throwable türünden türetilir ve ekteki yığın izleme (stack trace), kullanımın bağlamını sağlar.

Veridex aracını kullanarak test etme

APK'nızda veridex statik analiz aracını da çalıştırabilirsiniz. Veridex aracı, üçüncü taraf kitaplıklar da dahil olmak üzere APK'nın tüm kod tabanını tarar ve bulduğu SDK olmayan arayüz kullanımlarını bildirir.

Veridex aracının sınırlamaları aşağıdakileri içerir:

  • JNI üzerinden yapılan çağrıları tespit edemez.
  • Yansıma aracılığıyla çağrıların yalnızca bir alt kümesini algılayabilir.
  • Etkin olmayan kod yollarının analizi API düzeyi kontrollerle sınırlıdır.
  • Yalnızca SSE4.2 ve POPCNT talimatlarını destekleyen makinelerde çalıştırılabilir.

Windows

Yerel Windows ikili programları sağlanmamıştır ancak Linux için Windows Alt Sistemi (WSL) ile Linux ikili programlarını çalıştırarak Windows'da veridex aracını çalıştırabilirsiniz. Bu bölümdeki adımları uygulamadan önce WSL'yi yükleyin ve Linux dağıtımınız olarak Ubuntu'yu seçin.

Ubuntu yüklendikten sonra, bir Ubuntu terminali başlatın ve şu adımları uygulayın:

  1. Android çalışma zamanı önceden oluşturulmuş deposundan veridex aracını indirin.
  2. appcompat.tar.gz dosyasının içeriğini çıkarın.
  3. Çıkarılan klasörde veridex-linux.zip dosyasını bulup çıkarın.
  4. Açılmış klasöre gidin ve aşağıdaki komutu çalıştırın. Buradaki your-app.apk, test etmek istediğiniz APK'dır:

    ./appcompat.sh --dex-file=your-app.apk
    

macOS

Veridex aracını macOS'te çalıştırmak için aşağıdaki adımları uygulayın:

  1. Android çalışma zamanı önceden oluşturulmuş deposundan veridex aracını indirin.
  2. appcompat.tar.gz dosyasının içeriğini çıkarın.
  3. Çıkarılan klasörde veridex-mac.zip dosyasını bulup çıkarın.
  4. Çıkarılan klasöre gidin ve aşağıdaki komutu çalıştırın. Burada /path-from-root/your-app.apk, test etmek istediğiniz APK'nın sisteminizin kök dizininden başlayarak yoludur:

    ./appcompat.sh --dex-file=/path-from-root/your-app.apk
    

Linux

Veridex aracını Linux'ta çalıştırmak için şu adımları uygulayın:

  1. Android çalışma zamanı önceden oluşturulmuş deposundan veridex aracını indirin.
  2. appcompat.tar.gz dosyasının içeriğini çıkarın.
  3. Çıkarılan klasörde veridex-linux.zip dosyasını bulup çıkarın.
  4. Açılmış klasöre gidin ve aşağıdaki komutu çalıştırın. Buradaki your-app.apk, test etmek istediğiniz APK'dır:

    ./appcompat.sh --dex-file=your-app.apk
    

Android Studio lint aracını kullanarak test etme

Uygulamanızı Android Studio'da her derlediğiniz zaman lint aracı, kodunuzu olası sorunlara karşı inceler. Uygulamanız SDK olmayan arayüzler kullanıyorsa bu arayüzlerin ait olduğu listeye bağlı olarak derleme hataları veya uyarıları görebilirsiniz.

Ayrıca lint aracını komut satırından çalıştırabilir ya da belirli bir proje, klasör veya dosya üzerinde denetlemeleri manuel olarak çalıştırabilirsiniz.

Play Console'u kullanarak test etme

Uygulamanızı Play Console'da bir test kanalına yüklediğinizde potansiyel sorunlara karşı otomatik olarak test edilir ve bir lansman öncesi rapor oluşturulur. Uygulamanız SDK olmayan arayüzler kullanıyorsa bu arayüzlerin ait olduğu listeye bağlı olarak lansman öncesi raporda hata veya uyarı görüntülenir.

Daha fazla bilgi için Sorunları tanımlamak için lansman öncesi raporları kullanma makalesinin Android Uyumluluğu bölümüne bakın.

Yeni bir genel API isteyin

Uygulamanızdaki bir özellik için SDK olmayan arayüz kullanmanın alternatifini bulamıyorsanız sorun izleyicimizde özellik isteği oluşturarak yeni bir herkese açık API isteyebilirsiniz.

Özellik isteği oluştururken aşağıdaki bilgileri sağlayın:

  • Accessing hidden ... logcat mesajında görünen tam açıklayıcı da dahil olmak üzere hangi desteklenmeyen API'yi kullandığınız.
  • Bu API'leri neden kullanmanız gerekir? Yalnızca alt seviyedeki ayrıntılar değil, API'nin gerekli olduğu üst düzey özelliklerle ilgili ayrıntılar da dahil olmak üzere bu API'leri neden kullanmanız gerektiği
  • İlgili genel SDK API'lerinin amaçlarınız için neden yeterli olmadığı.
  • Denediğiniz diğer alternatifler ve bunların neden işe yaramadığı.

Özellik isteğinizde bu ayrıntıları sağladığınızda, yeni bir genel API'nin verilme olasılığını artırırsınız.

Diğer sorular

Bu bölümde, geliştiricilerin sık sorduğu diğer soruların bazı yanıtları yer almaktadır:

Genel sorular

Google, sorun izleyici aracılığıyla tüm uygulamaların ihtiyaçlarını karşılayabildiğinden nasıl emin olabilir?

Android 9 (API düzeyi 28) için ilk listeleri, aşağıdaki yöntemler kullanılarak eklenen uygulamaların statik analiziyle oluşturduk:

  • en popüler Play ve Play dışındaki uygulamaları manuel olarak test etme
  • dahili raporlar
  • dahili kullanıcılardan otomatik veri toplama
  • geliştirici önizleme raporları
  • daha fazla yanlış pozitif içermek için konservatif olarak tasarlanmış ek statik analiz

Her yeni sürümün listelerini değerlendirirken sorun izleyici aracılığıyla geliştirici geri bildirimlerinin yanı sıra API kullanımını da dikkate alırız.

SDK olmayan arayüzlere erişimi nasıl etkinleştirebilirim?

API zorunlu kılma politikasını değiştirmek için adb komutlarını kullanarak geliştirme cihazlarında SDK olmayan arayüzlere erişimi etkinleştirebilirsiniz. Kullandığınız komutlar API düzeyine göre değişiklik gösterir. Bu komutlar root erişimli cihaz gerektirmez.

Android 10 (API düzeyi 29) veya sonraki sürümler

Erişimi etkinleştirmek için aşağıdaki adb'yi kullanın

komutu:

adb shell settings put global hidden_api_policy  1

API zorunlu kılma politikasını varsayılan ayarlara sıfırlamak için aşağıdaki komutu kullanın:

adb shell settings delete global hidden_api_policy
Android 9 (API düzeyi 28)

Erişimi etkinleştirmek için aşağıdaki adb komutlarını kullanın:

adb shell settings put global hidden_api_policy_pre_p_apps  1
adb shell settings put global hidden_api_policy_p_apps 1

API zorunlu kılma politikasını varsayılan ayarlara sıfırlamak için aşağıdaki komutları kullanın:

adb shell settings delete global hidden_api_policy_pre_p_apps
adb shell settings delete global hidden_api_policy_p_apps

API yaptırım politikasındaki tam sayıyı aşağıdaki değerlerden birine ayarlayabilirsiniz:

  • 0: SDK olmayan arayüzlerin tüm algılamasını devre dışı bırak. Bu ayarın kullanılması SDK dışı arayüz kullanımı için tüm günlük mesajlarını devre dışı bırakır ve StrictMode API'yi kullanarak uygulamanızı test etmenizi engeller. Bu ayar önerilmez.
  • 1: SDK olmayan tüm arayüzlere erişimi etkinleştirin ancak SDK olmayan arayüz kullanımları için günlük mesajlarını uyarıyla yazdırın. Bu ayarı kullanmanız, StrictMode API'yi kullanarak uygulamanızı test etmenize de olanak tanır.
  • 2: Engellenenler listesine ait olan veya hedef API düzeyiniz için koşullu olarak engellenmiş SDK dışı arayüzlerin kullanımına izin verme.

SDK olmayan arayüz listeleri hakkında sorular

SDK olmayan API listelerini sistem görüntüsünde nerede bulabilirim?

Bunlar, platform dex dosyalarındaki alan ve yöntem erişimi işareti bitlerinde kodlanır. Sistem görüntüsünde bu listeleri içeren ayrı bir dosya yoktur.

SDK olmayan API listeleri, aynı Android sürümlerine sahip farklı OEM cihazlarda aynı mıdır?

OEM'ler, engellenenler listesine (kara listeye) kendi arayüzlerini ekleyebilir ancak arayüzleri AOSP SDK olmayan API listelerinden kaldıramaz. CDD bu tür değişiklikleri engeller ve CTS testleri, Android Çalışma Zamanı'nın listeyi uyguladığını sağlar.

Yerel kodda, NDK olmayan arayüzlerde herhangi bir kısıtlama var mı?

Android SDK'sı Java arayüzleri içerir. Platform, Android 7'de (API düzeyi 26) yerel C/C++ kodu için NDK olmayan arayüzlere erişimi kısıtlamaya başladı. Daha fazla bilgi için Android N'de Özel C/C++ Sembolü Kısıtlamalarıyla Kararlılığı Artırma başlıklı makaleye göz atın.

dex2oat veya DEX dosya manipülasyonunu kısıtlamak için herhangi bir plan var mı?

dex2oat ikili programına erişimi kısıtlamaya yönelik etkin planlarımız bulunmamaktadır, ancak DEX dosya biçiminin Dalvik Yürütülebilir biçiminde herkese açık olarak belirtilen bölümlerin ötesinde sabit veya herkese açık bir arayüz olması gibi bir amacımız yoktur. dex2oat'ı ve DEX biçiminin tanımlanmamış bölümlerini herhangi bir zamanda değiştirme veya kaldırma hakkımızı saklı tutarız. Ayrıca, ODEX (OAT olarak da bilinir), VDEX ve CDEX gibi dex2oat tarafından oluşturulan tüm türetilmiş dosyaların belirtilmemiş biçimler olduğunu unutmayın.

Önemli bir üçüncü taraf SDK'sı (örneğin, kod karartıcı) SDK olmayan arayüzleri kullanmaktan kaçınıp gelecekteki Android sürümleriyle uyumluluğu sürdürmeyi taahhüt ediyorsa ne olur? Android bu durumda uyumluluk gereksinimlerinden feragat edebilir mi?

SDK bazında uyumluluk şartlarından feragat etmeyi planlamıyoruz. Bir SDK geliştiricisi, yalnızca desteklenmeyen (eski adıyla gri) listelerdeki arayüzlere bağlı olarak uyumluluğu koruyabiliyorsa SDK arayüzlerine veya diğer alternatiflere geçiş planlamaya başlamalı ve SDK dışı bir arayüz kullanmaya alternatif bulamadığında yeni bir genel API istemelidir.

SDK dışı arayüz kısıtlamaları yalnızca üçüncü taraf uygulamaları için değil, sistem ve birinci taraf uygulamaları da dahil olmak üzere tüm uygulamalar için geçerli midir?

Evet, ancak platform anahtarı ve bazı sistem görüntüsü uygulamaları ile imzalanmış uygulamaları muaf tutarız. Bu muafiyetlerin yalnızca sistem görüntüsünün (veya güncellenmiş sistem görüntüsü uygulamalarının) bir parçası olan uygulamalar için geçerli olduğunu unutmayın. Liste, SDK API'lerine (LOCAL_PRIVATE_PLATFORM_APIS := true olan kodda) değil, yalnızca özel platform API'lerine dayalı olarak oluşturulan uygulamalar için hazırlanmıştır.