Davranış değişiklikleri: tüm uygulamalar

Android 9 (API düzeyi 28), Android sisteminde bir dizi değişiklik içerir. Aşağıdaki davranış değişiklikleri, hedefledikleri API düzeyinden bağımsız olarak Android 9 platformunda çalıştırılan tüm uygulamalar için geçerlidir. Tüm geliştiriciler bu değişiklikleri incelemeli ve uygulama için geçerli olduğu durumlarda uygulamalarını bu değişiklikleri düzgün şekilde destekleyecek şekilde değiştirmelidir.

Yalnızca API düzeyi 28 veya sonraki sürümleri hedefleyen uygulamaları etkileyen değişiklikler için Davranış değişiklikleri: API düzeyi 28 ve sonraki sürümleri hedefleyen uygulamalar başlıklı makaleyi inceleyin.

Güç yönetimi

Android 9, cihaz güç yönetimini iyileştirmeye yönelik yeni özellikler sunar. Android 9'dan önce mevcut olan özelliklerle birlikte bu değişiklikler, sistem kaynaklarının en çok ihtiyaç duyan uygulamalara sunulmasını sağlar.

Ayrıntılı bilgi için Güç yönetimi başlıklı makaleyi inceleyin.

Gizlilik değişiklikleri

Android 9, kullanıcı gizliliğini artırmak için arka plan uygulamalarının cihaz sensörlerine erişimini sınırlama, kablosuz taramadan alınan bilgileri kısıtlama ve telefon aramaları, telefon durumu ve kablosuz taramalar ile ilgili yeni izin kuralları ve izin grupları gibi çeşitli davranış değişiklikleri sunar.

Bu değişiklikler, hedeflenen SDK sürümünden bağımsız olarak Android 9'da çalışan tüm uygulamaları etkiler.

Arka planda sensörlere sınırlı erişim

Android 9, arka plan uygulamalarının kullanıcı girişine ve sensör verilerine erişme özelliğini sınırlar. Uygulamanız Android 9 çalıştıran bir cihazda arka planda çalışıyorsa sistem uygulamanıza aşağıdaki kısıtlamaları uygular:

  • Uygulamanız mikrofona veya kameraya erişemiyor.
  • İvme ölçerler ve jiroskoplar gibi sürekli raporlama modunu kullanan sensörler etkinlik almaz.
  • Değişiklik olduğunda veya tek seferlik raporlama modlarını kullanan sensörler etkinlik almaz.

Uygulamanızın Android 9 çalıştıran cihazlarda sensör etkinliklerini algılaması gerekiyorsa ön plan hizmeti kullanın.

Arama günlüklerine erişim kısıtlandı

Android 9, CALL_LOG izin grubunu kullanıma sunar ve READ_CALL_LOG, WRITE_CALL_LOG ve PROCESS_OUTGOING_CALLS izinlerini bu gruba taşır. Android'in önceki sürümlerinde bu izinler PHONE izin grubunda yer alıyordu.

Bu CALL_LOG izin grubu, kullanıcılara telefon aramalarıyla ilgili hassas bilgilere (ör. telefon araması kayıtlarını okuma ve telefon numaralarını tanımlama) erişmesi gereken uygulamalar üzerinde daha fazla kontrol ve görünürlük sağlar.

Uygulamanızın arama kayıtlarına erişmesi veya giden aramaları işlemesi gerekiyorsa bu izinleri CALL_LOG izin grubundan açıkça istemeniz gerekir. Aksi takdirde SecurityException oluşur.

Not: Bu izinler grup değiştirdiği ve çalışma zamanında verildiği için kullanıcının, uygulamanızın telefon araması kayıtlarına erişimini reddedebileceğini unutmayın. Bu durumda uygulamanız, bilgiye erişememe durumunu sorunsuz bir şekilde ele alabilmelidir.

Uygulamanız zaten çalışma zamanındaki izinlerle ilgili en iyi uygulamaları uyguluyorsa izin grubundaki değişikliği kaldırabilir.

Telefon numaralarına erişim kısıtlandı

Android 9'da çalışan uygulamalar, uygulamanızın kullanım alanlarının gerektirdiği diğer izinlerin yanı sıra önce READ_CALL_LOG iznine sahip olmadan telefon numaralarını veya telefon durumunu okuyamaz.

Gelen ve giden aramalarla ilişkili telefon numaraları, telefon durumu yayınında görünür (ör. gelen ve giden aramalar) ve PhoneStateListener sınıfından erişilebilir. Ancak READ_CALL_LOG izni olmadan PHONE_STATE_CHANGED yayınlarında ve PhoneStateListener üzerinden sağlanan telefon numarası alanı boş olur.

Telefon durumundaki telefon numaralarını okumak için uygulamanızı, kullanım alanınıza göre gerekli izinleri isteyecek şekilde güncelleyin:

Kablosuz bağlantı konumu ve bağlantı bilgilerine erişim kısıtlandı

Android 9'da, bir uygulamanın kablosuz ağ taraması yapması için gereken izin koşulları önceki sürümlere göre daha katı. Ayrıntılar için Kablosuz tarama kısıtlamaları başlıklı makaleyi inceleyin.

Benzer kısıtlamalar, mevcut kablosuz bağlantıyı açıklayan bir WifiInfo nesnesi döndüren getConnectionInfo() yöntemi için de geçerlidir. SSID ve BSSID değerlerini almak için bu nesnenin yöntemlerini yalnızca arayan uygulamanın aşağıdaki izinlere sahip olması durumunda kullanabilirsiniz:

  • ACCESS_FINE_LOCATION veya ACCESS_COARSE_LOCATION
  • ACCESS_WIFI_STATE

SSID veya BSSID'yi almak için cihazda konum hizmetlerinin de etkinleştirilmesi gerekir (Ayarlar > Konum bölümünde).

Kablosuz hizmet yöntemlerinden kaldırılan bilgiler

Android 9'da aşağıdaki etkinlikler ve yayınlar, kullanıcının konumu veya kimliği tanımlayabilecek veriler hakkında bilgi almaz:

Kablosuz ağdan yayınlanan NETWORK_STATE_CHANGED_ACTION sistem yayını artık SSID (eski adıyla EXTRA_SSID), BSSID (eski adıyla EXTRA_BSSID) veya bağlantı bilgilerini (eski adıyla EXTRA_NETWORK_INFO) içermiyor. Uygulamanız için bu bilgilere ihtiyaç varsa bunun yerine getConnectionInfo() işlevini çağırın.

Telefon bilgileri artık cihaz konum ayarına bağlı

Kullanıcı, Android 9 çalıştıran bir cihazda cihaz konumunu devre dışı bıraktıysa aşağıdaki yöntemler sonuç vermez:

SDK olmayan arayüzlerin kullanımıyla ilgili kısıtlamalar

Platform, uygulama kararlılığı ve uyumluluğunu sağlamak için SDK dışındaki bazı yöntemlerin ve alanların kullanımını kısıtlar. Bu kısıtlamalar, bu yöntemlere ve alanlara doğrudan, yansıma yoluyla veya JNI'yi kullanarak erişmeye çalıştığınızda geçerli olur. Android 9'da uygulamanız bu kısıtlanmış arayüzlere erişmeye devam edebilir. Platform, bu arayüzleri size bildirmek için pop-up'lar ve günlük girişleri kullanır. Uygulamanızda bu tür bir pop-up gösteriliyorsa kısıtlanmış arayüz dışında bir uygulama stratejisi izlemeniz önemlidir. Alternatif bir stratejinin uygulanamayacağını düşünüyorsanız kısıtlamanın yeniden değerlendirilmesini istemek için bir hata kaydı gönderebilirsiniz.

SDK Olmayan Arayüzlerde Kısıtlamalar başlıklı makalede daha fazla önemli bilgi verilmektedir. Uygulamanızın düzgün şekilde çalışmaya devam etmesini sağlamak için bu raporu incelemeniz gerekir.

Güvenlik davranışında yapılan değişiklikler

Cihaz güvenliğiyle ilgili değişiklikler

Android 9, uygulamanızın hangi sürümü hedeflediğinden bağımsız olarak uygulamanızın güvenliğini artıran çeşitli özellikler ekler.

TLS uygulama değişiklikleri

Sistemin TLS uygulaması Android 9'da birkaç değişikliğe uğradı:

Android uygulamasında güvenli web istekleri gönderme hakkında daha fazla bilgi edinmek için HTTPS örneği başlıklı makaleyi inceleyin.

Daha katı SECCOMP filtresi

Android 9, uygulamaların kullanabileceği sistem çağrılarını daha da kısıtlar. Bu davranış, Android 8.0 (API seviyesi 26) sürümündeki SECCOMP filtresinin bir uzantısıdır.

Kriptografi değişiklikleri

Android 9, şifreleme algoritmalarının uygulanması ve işlenmesi konusunda çeşitli değişiklikler içerir.

Parametrelerin ve algoritmaların Conscrypt uygulamaları

Android 9, Conscrypt'te algoritma parametrelerinin ek uygulamalarını sağlar. Bu parametreler şunlardır: AES, DESEDE, OAEP ve EC. Bu parametrelerin ve birçok algoritmanın Bouncy Castle sürümleri Android 9'dan itibaren kullanımdan kaldırıldı.

Uygulamanız Android 8.1 (API düzeyi 27) veya daha eski sürümleri hedefliyorsa desteği sonlandırılan bu algoritmalardan birinin Bouncy Castle uygulamasını istediğinizde uyarı alırsınız. Ancak Android 9'u hedefliyorsanız bu isteklerin her biri NoSuchAlgorithmException hatası verir.

Diğer değişiklikler

Android 9, kriptografiyle ilgili başka değişiklikler de sunar:

  • PBE anahtarları kullanılırken Bouncy Castle bir başlatma vektörü (IV) bekliyorsa ve uygulamanız bunu sağlamıyorsa bir uyarı alırsınız.
  • ARC4 şifresinin Conscrypt uygulaması, ARC4/ECB/NoPadding veya ARC4/NONE/NoPadding'i belirtmenize olanak tanır.
  • Crypto Java Kriptografi Mimarisi (JCA) sağlayıcısı kaldırıldı. Sonuç olarak, uygulamanız SecureRandom.getInstance("SHA1PRNG", "Crypto")'ü çağırırsa NoSuchProviderException meydana gelir.
  • Uygulamanız, RSA anahtarlarını anahtar yapısından daha büyük arabellekten ayrıştırırsa artık istisna oluşmaz.

Android'in kriptografik özelliklerini kullanma hakkında daha fazla bilgi edinmek için Kriptografi başlıklı makaleyi inceleyin.

Android güvenli şifrelenmiş dosyaları artık desteklenmiyor

Android 9, Android güvenli şifrelenmiş dosyalar (ASEC'ler) için desteği tamamen kaldırır.

Android 2.2'de (API düzeyi 8), SD karttaki uygulamaları desteklemek için ASEC'ler kullanıma sunulmuştur. Android 6.0'ta (API düzeyi 23) platform, geliştiricilerin ASEC'ler yerine kullanabileceği bir uygulanabilir depolama cihazı teknolojisi kullanıma sundu.

ICU kitaplıklarında yapılan güncellemeler

Android 9, ICU kitaplığının 60. sürümünü kullanır. Android 8.0 (API düzeyi 26) ve Android 8.1 (API düzeyi 27), ICU 58'i kullanır.

ICU, android.icu package altında herkese açık API'ler sağlamak için kullanılır ve uluslararasılaştırma desteği için Android platformunda dahili olarak kullanılır. Örneğin, java.util, java.text ve android.text.format'de Android sınıflarını uygulamak için kullanılır.

ICU 60'a yapılan güncelleme, ICU 59 ve ICU 60 sürüm notlarında belirtildiği gibi Emoji 5.0 veri desteği ve iyileştirilmiş tarih/saat biçimleri dahil olmak üzere birçok küçük ancak yararlı değişiklik içerir.

Bu güncellemedeki önemli değişiklikler:

  • Platformun saat dilimlerini işleme şekli değişti.
    • Platform, GMT ve UTC'yi daha iyi yönetir. UTC artık GMT ile eş anlamlı değildir.

      ICU artık GMT ve UTC için çevrilmiş bölge adları sağlıyor. Bu değişiklik, "GMT", "Etc/GMT", "UTC", "Etc/UTC" ve "Zulu" gibi bölgelerin android.icu biçimlendirme ve ayrıştırma davranışını etkiler.

    • java.text.SimpleDateFormat artık UTC /GMT için görünen adlar sağlamak amacıyla ICU'yu kullanıyor. Bu, şu anlama gelir:
      • zzzz biçimlendirildiğinde birçok yerel ayar için uzun bir yerelleştirilmiş dize oluşturulur. Daha önce, UTC için "UTC" ve GMT için "GMT+00:00" gibi dizelerin döndürülmesi
      • zzzz ayrıştırma işlemi, "Eşgüdümlü Evrensel Zaman" ve "Greenwich
      • Uygulamalar, "UTC" veya "GMT+00:00" değerinin tüm dillerde zzzz için çıktı olarak verileceğini varsayarsa uyumluluk sorunlarıyla karşılaşabilir.
    • java.text.DateFormatSymbols.getZoneStrings()'ün davranışı değişti:
      • SimpleDateFormat ile birlikte UTC ve GMT'nin de uzun adları var. UTC bölgesi için saat dilimi adlarının yaz saati varyantları ("UTC", "Etc/UTC" ve "Zulu" gibi) GMT+00:00 olur. Bu, UTC sabit kodlu dizesi yerine, kullanılabilecek ad olmadığında standart yedek değerdir.
      • Bazı bölge kimlikleri, diğer bölgelerin eş anlamlıları olarak doğru şekilde tanınır. Böylece Android, daha önce çözülemeyen Eire gibi eski bölge kimlikleri için dize bulur.
    • Asya/Hanoi artık tanınan bir bölge değil. Bu nedenle, java.util.TimeZones.getAvailableIds() bu değeri döndürmez ve java.util.TimeZone.getTimeZone() bu değeri tanımaz. Bu davranış, mevcut android.icu davranışıyla tutarlıdır.
  • android.icu.text.NumberFormat.getInstance(ULocale, PLURALCURRENCYSTYLE).parse(String) yöntemi, geçerli para birimi metnini ayrıştırırken bile ParseException hatası verebilir. PLURALCURRENCYSTYLE stilinde para birimi metni için Android 7.0 (API düzeyi 24) sürümünden beri kullanılabilen NumberFormat.parseCurrency öğesini kullanarak bu sorunu önleyin.

Android Testi değişiklikleri

Android 9, Android Test çerçevesinin kitaplığında ve sınıf yapısında çeşitli değişiklikler içerir. Bu değişiklikler, geliştiricilerin çerçeve destekli herkese açık API'leri kullanmasına yardımcı olur ancak üçüncü taraf kitaplıkları veya özel mantık kullanarak test oluşturma ve çalıştırma konusunda daha fazla esneklik de sağlar.

Kitaplıklar çerçeveden kaldırıldı

Android 9, JUnit tabanlı sınıfları üç kitaplıkta yeniden düzenler: android.test.base, android.test.runner ve android.test.mock. Bu değişiklik, JUnit'in projenizin bağımlılıklarıyla en iyi çalışan sürümüne göre test çalıştırmanıza olanak tanır. JUnit'in bu sürümü, android.jar tarafından sağlanan sürümden farklı olabilir.

JUnit tabanlı sınıfların bu kitaplıklarda nasıl düzenlendiği ve uygulamanızın projesini test yazmak ve çalıştırmak için nasıl hazırlayacağınız hakkında daha fazla bilgi edinmek için Android Test için proje oluşturma başlıklı makaleyi inceleyin.

Test grubu derleme değişiklikleri

TestSuiteBuilder sınıfındaki addRequirements() yöntemi kaldırıldı ve TestSuiteBuilder sınıfının desteği sonlandırıldı. addRequirements() yöntemi, geliştiricilerin türü gizli API olan bağımsız değişkenler sağlamasını gerektiriyordu. Bu da API'yi geçersiz kılıyordu.

Java UTF kod çözücü

UTF-8, Android'de varsayılan karakter kümesidir. UTF-8 bayt dizisi, String(byte[] bytes) gibi bir String kurucu tarafından kod çözülebilir.

Android 9'daki UTF-8 kod çözücü, Unicode standartlarını önceki sürümlere kıyasla daha katı bir şekilde uygular. Yapılan değişiklikler şunlardır:

  • UTF-8'in en kısa olmayan biçimi (ör. <C0, AF>) hatalı biçimli olarak değerlendirilir.
  • UTF-8'in U+D800..U+DFFF gibi yedek biçimi, hatalı biçimlendirilmiş olarak değerlendirilir.
  • Maksimum alt bölüm tek bir U+FFFD ile değiştirilir. Örneğin, "41 C0 AF 41 F4 80 80 41" bayt dizisinde maksimum alt parçalar "C0", "AF" ve "F4 80 80" şeklindedir."F4 80 80", "F4 80 80 80" dizisinin ilk alt dizisi olabilir ancak "C0", iyi biçimlendirilmiş herhangi bir kod birimi dizisinin ilk alt dizisi olamaz. Dolayısıyla, çıkış "A\ufffd\ufffdA\ufffdA" olmalıdır.
  • Android 9 veya sonraki sürümlerde değiştirilmiş bir UTF-8 / CESU-8 dizisinin kodunu çözmek için DataInputStream.readUTF() yöntemini veya NewStringUTF() JNI yöntemini kullanın.

Sertifika kullanarak ana makine adı doğrulama

RFC 2818, bir alan adını sertifika ile eşleştirmenin iki yöntemini açıklar: subjectAltName (SAN) uzantısındaki mevcut adları kullanarak veya SAN uzantısı olmadığında commonName (CN) uzantısına geri dönerek.

Ancak CN'e yedek olarak başvurma özelliği RFC 2818'de kullanımdan kaldırılmıştır. Bu nedenle Android artık CN'ü kullanmaya geri dönmez. Bir ana makine adını doğrulamak için sunucunun eşleşen bir SAN içeren sertifika sunması gerekir. Ana makine adıyla eşleşen bir SAN içermeyen sertifikalara artık güvenilmez.

Ağ adresi aramaları ağ ihlallerine neden olabilir

Ad çözümlemesi gerektiren ağ adresi aramaları, ağ G/Ç'sini içerebilir ve bu nedenle engelleme işlemleri olarak kabul edilir. Ana ileti dizisindeki engelleme işlemleri duraklamaya veya takılmaya neden olabilir.

StrictMode sınıfı, geliştiricilerin kodlarındaki sorunları tespit etmelerine yardımcı olan bir geliştirme aracıdır.

Android 9 ve sonraki sürümlerde StrictMode, ad çözümlemesi gerektiren ağ adresi aramalarının neden olduğu ağ ihlallerini tespit eder.

Uygulamalarınızı StrictMode etkinken dağıtmamanız gerekir. Bu durumda, ağ ihlallerini algılayan bir politika almak için detectNetwork() veya detectAll() yöntemlerini kullanırken NetworkOnMainThreadException gibi istisnalar uygulamalarınızda yaşanabilir.

Sayısal bir IP adresinin çözülmesi, engelleme işlemi olarak kabul edilmez. Sayısal IP adresi çözümü, Android 9'dan önceki sürümlerde olduğu gibi çalışır.

Yuva etiketleme

Android 9'dan önceki platform sürümlerinde, bir soket setThreadStatsTag() yöntemi kullanılarak etiketlenirse ParcelFileDescriptor kapsayıcısıyla bağlantılayıcı IPC kullanılarak başka bir işleme gönderildiğinde soketin etiketi kaldırılır.

Android 9 ve sonraki sürümlerde, soket etiketi, binder IPC kullanılarak başka bir sürece gönderilirken saklanır. Bu değişiklik, ağ trafiği istatistiklerini etkileyebilir (ör. queryDetailsForUidTag() yöntemi kullanıldığında).

Başka bir işleme gönderilen bir soketin etiketini kaldıran önceki sürümlerin davranışını korumak istiyorsanız soketi göndermeden önce untagSocket() işlevini çağırabilirsiniz.

Soketteki kullanılabilir baytların bildirilen miktarı

available() yöntemi, shutdownInput() yöntemi çağrıldıktan sonra çağrıldığında 0 değerini döndürür.

VPN'ler için daha ayrıntılı ağ özellikleri raporlaması

Android 8.1 (API düzeyi 27) ve önceki sürümlerde NetworkCapabilities sınıfı, VPN'ler için yalnızca sınırlı bir bilgi grubu (ör. TRANSPORT_VPN) raporlar ancak NET_CAPABILITY_NOT_VPN bilgisini atlar. Bu sınırlı bilgi, VPN kullanımının uygulamanın kullanıcısından ücret alınmasına yol açıp açmayacağını belirlemeyi zorlaştırıyordu. Örneğin, NET_CAPABILITY_NOT_METERED değerini kontrol etmek, temel ağların ölçülü olup olmadığını belirlemez.

Android 9 ve sonraki sürümlerde, bir VPN setUnderlyingNetworks()metodunu çağrdığında Android sistemi, temel ağların aktarımlarını ve özelliklerini birleştirir ve sonucu VPN ağının etkili ağ özellikleri olarak döndürür.

Android 9 ve sonraki sürümlerde, NET_CAPABILITY_NOT_METERED değerini zaten kontrol eden uygulamalar VPN'nin ve temel ağların ağ özelliklerini alır.

xt_qtaguid klasöründeki dosyalar artık uygulamalar tarafından kullanılamıyor

Android 9'dan itibaren uygulamaların /proc/net/xt_qtaguid klasöründeki dosyalara doğrudan okuma erişimine sahip olmasına izin verilmez. Bunun nedeni, bu dosyaların hiç bulunmadığı bazı cihazlarla tutarlılığı sağlamaktır.

Bu dosyalara dayanan herkese açık API'ler (TrafficStats ve NetworkStatsManager) amaçlandığı gibi çalışmaya devam eder. Ancak qtaguid_tagSocket() gibi desteklenmeyen cutils işlevleri farklı cihazlarda beklendiği gibi çalışmayabilir veya hiç çalışmayabilir.

FLAG_ACTIVITY_NEW_TASK koşulu artık zorunlu kılınıyor

Android 9'da, intent işaretini FLAG_ACTIVITY_NEW_TASK iletmediğiniz sürece etkinlik dışı bir bağlamda etkinlik başlatamazsınız. Bu işareti iletmeden bir etkinlik başlatmaya çalışırsanız etkinlik başlatılmaz ve sistem günlükte bir mesaj yazdırır.

Ekran döndürme değişiklikleri

Android 9'dan itibaren dikey rotasyon modunda önemli değişiklikler yapıldı. Android 8.0'da (API düzeyi 26) kullanıcılar, Hızlı Ayarlar kartını veya Ekran ayarlarını kullanarak otomatik döndürme ile dikey döndürme modları arasında geçiş yapabilirdi. Dikey mod, döndürme kilidi olarak yeniden adlandırıldı ve otomatik döndürme devre dışı bırakıldığında etkinleştirilir. Otomatik döndürme modunda herhangi bir değişiklik yapılmadı.

Cihaz döndürme kilidi modundayken kullanıcılar ekranlarını, üstteki görünür etkinlik tarafından desteklenen herhangi bir döndürme moduna kilitleyebilir. Etkinlikler her zaman dikey olarak oluşturulacağını varsayamaz. Üstteki etkinlik, otomatik döndürme modunda birden fazla rotasyonda oluşturulabiliyorsa etkinlik screenOrientation ayarına bağlı bazı istisnalar dışında aynı seçenekler, döndürme kilitli modda da kullanılabilir (aşağıdaki tabloya bakın).

Belirli bir yönü isteyen etkinlikler (ör. screenOrientation=landscape), kullanıcı kilidi tercihini yoksayar ve Android 8.0'deki gibi davranır.

Ekran yönü tercihi, AndroidManifest'te etkinlik düzeyinde veya setRequestedOrientation() ile programatik olarak ayarlanabilir.

Döndürme kilidi modu, WindowManager'ın etkinlik dönüşümünü yönetirken kullandığı kullanıcı dönüşüm tercihini ayarlayarak çalışır. Kullanıcı rotasyonu tercihi aşağıdaki durumlarda değiştirilebilir. Cihazın doğal rotasyonuna (telefon form faktörü cihazlarda genellikle dikey) dönme eğilimi olduğunu unutmayın:

  • Kullanıcı bir rotasyon önerisini kabul ettiğinde rotasyon tercihi öneriye göre değişir.
  • Kullanıcı, zorunlu dikey bir uygulamaya (kilit ekranı veya başlatıcı dahil) geçtiğinde döndürme tercihi dikey olarak değişir.

Aşağıdaki tabloda, yaygın ekran yönleri için döndürme davranışı özetlenmiştir:

Ekran Yönlendirme Davranış
belirtilmedi, kullanıcı Otomatik döndürme ve döndürme kilidi ayarlarında etkinlik dikey veya yatay olarak (ve bunun tersi olarak) oluşturulabilir. Hem dikey hem de yatay düzenleri desteklemeniz gerekir.
userLandscape Otomatik döndürme ve döndürme kilidi ayarlarında etkinlik yatay veya ters yatay olarak oluşturulabilir. Yalnızca yatay düzenler desteklenir.
userPortrait Otomatik döndürme ve döndürme kilidi ayarlarında etkinlik, dikey veya ters dikey olarak oluşturulabilir. Yalnızca dikey düzenler desteklenir.
fullUser Otomatik döndürme ve döndürme kilidi ayarlarında etkinlik dikey veya yatay olarak (ve bunun tersi olarak) oluşturulabilir. Hem dikey hem de yatay düzenleri destekleyecektir.

Döndürme kilidi kullanıcılarına, genellikle 180º'lik ters dikey kilitleme seçeneği sunulur.
sensör, tamSensör, sensörDikey, sensörYatay Döndürme kilidi modu tercihi yoksayılır ve otomatik döndürme etkinmiş gibi değerlendirilir. Bu seçeneği yalnızca istisnai durumlarda ve kullanıcı deneyimini dikkate alarak kullanın.

Apache HTTP istemcisinin desteğinin sonlandırılması, standart olmayan ClassLoader'a sahip uygulamaları etkiler

Android 6.0 ile birlikte Apache HTTP istemcisi desteğini kaldırdık. Bu değişiklik, Android 9 veya sonraki sürümleri hedeflemeyen uygulamaların büyük çoğunluğunu etkilemez. Ancak bu değişiklik, Android 9 veya sonraki sürümleri hedeflemese bile standart olmayan bir ClassLoader yapısı kullanan belirli uygulamaları etkileyebilir.

Sisteme açıkça yetki veren standart olmayan bir ClassLoader kullanan uygulamalar bu durumdan etkilenebilir.ClassLoader Bu uygulamaların, org.apache.http.*'da sınıf ararken ClassLoader uygulaması yerine ClassLoader uygulamasına yetki vermesi gerekir. ClassLoader sistemine yetki verirlerse bu sınıflar artık ClassLoader sistemi tarafından bilinmediğinden, uygulamalar Android 9 veya sonraki sürümlerde NoClassDefFoundError hatasıyla başarısız olur. Gelecekte benzer sorunların yaşanmaması için uygulamaların, sınıfları doğrudan ClassLoader sistemine erişmek yerine genellikle ClassLoader uygulaması üzerinden yüklemesi gerekir.

Kameraları numaralandırma

Android 9 cihazlarda çalışan uygulamalar, getCameraIdList() çağrısını yaparak mevcut tüm kameraları keşfedebilir. Uygulamalar, cihazda yalnızca tek bir arka kamera veya tek bir ön kamera olduğunu varsayamaz.

Örneğin, uygulamanızda ön ve arka kameralar arasında geçiş yapma düğmesi varsa aralarından seçim yapabileceğiniz birden fazla ön veya arka kamera olabilir. Kamera listesini gözden geçirip her kameranın özelliklerini inceleyin ve kullanıcıya hangi kameraların gösterileceğine karar verin.