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

Android 9 (API düzeyi 28), Android sisteminde bir dizi değişiklik sunmaktadır. Aşağıdaki davranış değişiklikleri, hedefledikleri API düzeyi ne olursa olsun Android 9 platformunda çalıştırılan tüm uygulamalar için geçerlidir. Tüm geliştiriciler, bu değişiklikleri incelemeli ve uygulamalarını, uygun olduğu durumlarda doğru bir şekilde destekleyecek şekilde düzenlemelidir.

Yalnızca API düzeyi 28 veya üstünü hedefleyen uygulamaları etkileyen değişiklikler için Davranış değişiklikleri: API Düzeyi 28 veya sonraki sürümleri hedefleyen uygulamalar bölümüne bakın.

Güç yönetimi

Android 9, cihaz güç yönetimini iyileştirmek için yeni özellikler sunar. Bu değişiklikler ve Android 9'dan önce zaten mevcut olan özellikler, sistem kaynaklarının en çok ihtiyaç duyan uygulamalarda kullanıma sunulmasına yardımcı oluyor.

Ayrıntılar için Güç yönetimi başlıklı makaleye bakın.

Gizlilikle ilgili değişiklikler

Android 9, kullanıcı gizliliğini iyileştirmek için arka plan uygulamalarının cihaz sensörlerine erişimini sınırlama, kablosuz ağ taramalarından alınan bilgilerin kısıtlanması, telefon aramaları, telefon durumu ve kablosuz ağ taramalarıyla ilgili yeni izin kuralları ve izin grupları gibi çeşitli davranış değişiklikleri sunar.

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

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

Android 9, arka plan uygulamalarının kullanıcı girişi ve sensör verilerine erişme özelliğini sınırlandırır. 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çer ve jiroskop gibi sürekli raporlama modunu kullanan sensörler etkinlik almaz.
  • Değişiklik veya tek çekim raporlama modlarını kullanan sensörler etkinlik almaz.

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

Arama kayıtlarına kısıtlı erişim

Android 9, CALL_LOG izin grubunu kullanıma sunarak 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 bulunuyordu.

Bu CALL_LOG izin grubu, telefon arama kayıtlarını okuma ve telefon numaralarını tanımlama gibi telefon aramalarıyla ilgili hassas bilgilere erişmesi gereken uygulamaları kullanıcılara daha iyi kontrol etme ve görme olanağı sunar.

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

Not: Bu izinler farklı gruplar haline geldiğinden ve çalışma zamanında verildiğinden kullanıcının, uygulamanızın telefon arama kaydı bilgilerine erişimini reddetmesi mümkündür. Bu durumda, uygulamanız bilgiye erişim eksikliği sorununu sorunsuz şekilde halledebilmelidir.

Uygulamanız zaten çalışma zamanı izinleri ile ilgili en iyi uygulamaları takip ediyorsa izin grubundaki değişikliği işleyebilir.

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

Android 9'da çalışan uygulamalar, uygulamanızın kullanım alanlarının gerektirdiği diğer izinlere ek olarak, READ_CALL_LOG iznini almadan 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 için). Bu numaralara PhoneStateListener sınıfından erişilebilir. Ancak READ_CALL_LOG izni olmadığında, PHONE_STATE_CHANGED yayınlarında ve PhoneStateListener aracılığıyla sağlanan telefon numarası alanı boş olur.

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

Kablosuz konuma ve bağlantı bilgilerine kısıtlı erişim

Android 9'da, uygulamaların kablosuz ağ taraması gerçekleştirmesine ilişkin izin gereksinimleri önceki sürümlerden daha katıdır. Ayrıntılı bilgi için Kablosuz ağ taraması kısıtlamaları bölümünü inceleyin.

Mevcut kablosuz bağlantıyı açıklayan bir WifiInfo nesnesi döndüren getConnectionInfo() yöntemi için de benzer kısıtlamalar geçerlidir. Bu nesnenin yöntemlerini yalnızca, çağıran uygulama aşağıdaki izinlere sahipse SSID ve BSSID değerlerini almak için 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 altında).

Bilgiler kablosuz ağ hizmeti yöntemlerinden kaldırıldı

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 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 bu bilgilere ihtiyaç duyuyorsa getConnectionInfo() numaralı telefonu arayın.

Telefon bilgileri artık cihaz konum ayarlarını temel alıyor

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

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

Uygulama kararlılığını ve uyumluluğu sağlamaya yardımcı olmak için platform, bazı SDK dışı yöntem ve alanların kullanımını kısıtlar. Bu yöntem ve alanlara doğrudan, düşünme yoluyla veya JNI kullanarak erişmeye çalışmanız fark etmeksizin bu kısıtlamalar geçerlidir. Android 9'da uygulamanız bu kısıtlanmış arayüzlere erişmeye devam edebilir. Platform, bunları dikkatinize sunmak için durum bildirimlerini ve günlük girişlerini kullanır. Uygulamanızda bu tür bir bilgilendirme yapıldığında, kısıtlı arayüz dışında bir uygulama stratejisi izlemeniz önemlidir. Alternatif bir stratejinin uygulanabilir olmadığını düşünüyorsanız kısıtlamanın yeniden değerlendirilmesini istemek için bir hata bildiriminde bulunabilirsiniz.

SDK dışı arayüzlere yönelik kısıtlamalar bölümünde ise başka önemli bilgiler yer almaktadır. Uygulamanızın düzgün çalışmaya devam ettiğinden emin olmak için bunu gözden geçirmeniz gerekir.

Güvenlik davranışı değişiklikleri

Cihaz güvenlik değişiklikleri

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

TLS uygulama değişiklikleri

Android 9'da sistemin TLS uygulamasında birkaç değişiklik yapıldı:

Bir Android uygulamasında güvenli web istekleri oluşturma hakkında daha fazla bilgi edinmek için HTTPS örneğine bakın.

Daha sıkı SECCOMP filtresi

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

Kriptografik değişiklikler

Android 9, kriptografik algoritmaların uygulanmasında ve işlenmesinde çeşitli değişiklikler yapar.

Parametre ve algoritmaların uygulamalarını ayırt edebilme

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

Uygulamanız Android 8.1 (API düzeyi 27) veya önceki sürümleri hedefliyorsa kullanımdan kaldırılan bu algoritmalardan birinin Bouncy Castle uygulamasını istediğinizde bir uyarı alırsınız. Ancak Android 9'u hedeflerseniz bu isteklerin her biri NoSuchAlgorithmException döndürür.

Diğer değişiklikler

Android 9, kriptografiyle ilgili birkaç değişiklik daha sunar:

  • PBE anahtarları kullanırken Bouncy Castle bir başlatma vektörü (IV) bekliyorsa ve uygulamanız böyle bir başlatma vektörü 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 Cryptography Architecture (JCA) sağlayıcısı kaldırıldı. Sonuç olarak, uygulamanız SecureRandom.getInstance("SHA1PRNG", "Crypto") yöntemini çağırırsa NoSuchProviderException oluşur.
  • Uygulamanız, anahtar yapısından daha büyük olan arabelleklerden RSA anahtarlarını ayrıştırıyorsa artık bir istisnayla karşılaşmazsınız.

Android'in şifreleme özelliklerini kullanma hakkında daha fazla bilgi edinmek için Kriptografi konusuna bakın.

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

Android 9, Android güvenli şifrelenmiş dosyalara (ASEC) desteğini tamamen kaldırır.

Android 2.2'de (API düzeyi 8) Android, SD kart üzerindeki uygulamalar işlevini desteklemek için ASEC'leri kullanıma sunmuştur. Platform, Android 6.0'da (API düzeyi 23) geliştiricilerin ASEC'ler yerine kullanabileceği bir benimseilebilir depolama cihazı teknolojisini kullanıma sunmuştur.

ICU kitaplıklarıyla ilgili 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. Uluslararasılaştırma desteği için Android platformunda dahili olarak da kullanılır. Örneğin, java.util, java.text ve android.text.format uygulamalarında Android sınıflarını uygulamak için kullanılır.

ICU 60 güncellemesi, 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 gibi pek çok küçük ama 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 ele alır; UTC artık GMT'nin eş anlamlısı değildir.

      Yoğun bakım ünitesi 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 alt bölgeler için 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 üzere ICU'yu kullanıyor. Bunun anlamı:
      • zzzz biçimlendirmesi, birçok yerel ayar için yerelleştirilmiş uzun bir dize oluşturur. Önceden, UTC için "UTC" ve GMT için "GMT+00:00" gibi dizeler oluşturuyordu.
      • zzzz ayrıştırılması, "Evrensel Eşgüdümlü Zaman" ve "Greenwich Saati" gibi dizeleri tanır.
      • Uygulamalar, zzzz için "UTC" veya "GMT+00:00" çıkışının tüm dillerde olduğunu varsayarsa uyumluluk sorunlarıyla karşılaşabilir.
    • java.text.DateFormatSymbols.getZoneStrings() özelliğinin davranışı değişti:
      • SimpleDateFormat'da olduğu gibi UTC ve GMT'nin de artık uzun adları var. UTC bölgesi için saat dilimi adlarının "UTC", "Etc/UTC" ve "Zulu" gibi DST varyantları, sabit kodlu UTC dizesi yerine standart yedek olan GMT+00:00 haline gelir.
      • Bazı alt bölge kimlikleri, diğer alt bölgelerin eş anlamlıları olarak doğru şekilde tanınır. Böylece Android, Eire gibi eski alt bölge kimliklerine ait daha önce çözülemeyen dizeleri 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() 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, meşru para birimi metni ayrıştırılırken bile ParseException hatası verebilir. PLURALCURRENCYSTYLE stili para birimi metinleri için Android 7.0'dan (API düzeyi 24) itibaren kullanılabilen NumberFormat.parseCurrency kullanarak bu sorundan kaçınabilirsiniz.

Android Test değişiklikleri

Android 9, Android Test çerçevesinin kitaplığında ve sınıf yapısında çeşitli değişiklikler yapar. Bu değişiklikler, geliştiricilerin çerçeve destekli, herkese açık API'leri kullanmasına yardımcı olur. Bununla birlikte değişiklikler, üçüncü taraf kitaplıklar veya özel mantık kullanarak testler oluşturup çalıştırmada da daha fazla esneklik 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, projenizin bağımlılıklarına en uygun olan JUnit sürümüne göre testler çalıştırmanızı sağlar. JUnit'in bu sürümü, android.jar tarafından sunulan sürümden farklı olabilir.

JUnit tabanlı sınıfların bu kitaplıklar halinde 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 bölümüne bakın.

Test paketi derleme değişikliklerini test etme

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

Java UTF kod çözücü

UTF-8, Android'de varsayılan karakter kümesidir. UTF-8 bayt dizisinin kodu, String(byte[] bytes) gibi bir String oluşturucu tarafından çözülebilir.

Android 9'daki UTF-8 kod çözücü, Unicode standartlarını önceki sürümlerden daha katı bir şekilde uygular. Değişiklikler aşağıdakileri içerir:

  • UTF-8'in en kısa olmayan biçimi (ör. <C0, AF>) hatalı olarak değerlendirilir.
  • UTF-8'in vekil biçimi (ör. U+D800..U+DFFF) hatalı 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 dizisindeki maksimum alt bölümler "C0", "AF" ve "F4 80 80" şeklindedir."F4 80 80", "F4 80 80 80" öğesinin ilk alt dizisi olabilir ancak "C0", iyi biçimlendirilmiş herhangi bir kod birimi dizisinin ilk alt dizisi olamaz. Bu nedenle, çı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() veya NewStringUTF() JNI yöntemini kullanın.

Sertifika kullanarak ana makine adı doğrulaması

RFC 2818, bir alan adını bir sertifikayla eşleştirmek için iki yöntemi açıklar: subjectAltName (SAN) uzantısındaki kullanılabilir adlar kullanılarak veya bir SAN uzantısı olmadığında commonName (CN).

Ancak, CN yedeği RFC 2818'de kullanımdan kaldırılmıştır. Bu nedenle, Android artık CN kullanmaya devam etmemektedir. Bir ana makine adını doğrulamak için sunucunun eşleşen SAN öğesine sahip bir 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/Ç'si içerebilir ve bu nedenle engelleme işlemi olarak kabul edilir. Ana iş parçacığındaki işlemlerin engellenmesi, duraklamalara veya jank'a neden olabilir.

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

Android 9 ve sonraki sürümlerde StrictMode, ad çözümlemeyi gerektiren ağ adresi aramalarından kaynaklanan ağ ihlallerini tespit eder.

Uygulamalarınızı StrictMode etkin durumdayken göndermemeniz gerekir. Bunu yaparsanız uygulamalarınız ağ ihlallerini tespit eden bir politika almak için detectNetwork() veya detectAll() yöntemlerini kullanırken NetworkOnMainThreadException gibi istisnalarla karşılaşabilir.

Sayısal IP adresini çözümlemek, engelleme işlemi olarak kabul edilmez. Sayısal IP adresi çözünürlüğü, Android 9'dan önceki sürümlerle aynı şekilde çalışır.

Yuva etiketleme

Android 9'dan düşük platform sürümlerinde setThreadStatsTag() yöntemi kullanılarak etiketlenen bir yuva, ParcelFileDescriptor container'ına sahip bağlayıcı IPC kullanılarak başka bir işleme gönderildiğinde etiketlenmez.

Android 9 ve sonraki sürümlerde yuva etiketi, bağlayıcı IPC kullanılarak başka bir işleme gönderildiğinde korunur. Bu değişiklik, örneğin queryDetailsForUidTag() yöntemini kullanırken ağ trafiği istatistiklerini etkileyebilir.

Başka bir işleme gönderilen bir yuvanın etiketini kaldıran önceki sürümlerin davranışını korumak isterseniz yuvayı göndermeden önce untagSocket() yöntemini çağırabilirsiniz.

Yuvada bildirilen kullanılabilir bayt 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 TRANSPORT_VPN gibi yalnızca sınırlı sayıda bilgi raporluyor ancak NET_CAPABILITY_NOT_VPN bilgisini atlıyordu. Bu sınırlı bilgiler, VPN kullanmanın uygulama kullanıcısı için ücret ödemelerine neden olup olmayacağının belirlenmesini zorlaştırıyordu. Örneğin, NET_CAPABILITY_NOT_METERED kontrolünün yapılması temel ağların ölçülüp ölçülmediğini belirlemez.

Android 9 ve sonraki sürümlerde, bir VPN setUnderlyingNetworks() yöntemini çağırdığında Android sistemi, temeldeki 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 olup olmadığını kontrol eden uygulamalar VPN'in ve temel ağların ağ özelliklerini alır.

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

Android 9'dan itibaren uygulamaların /proc/net/xt_qtaguid klasöründeki dosyalara doğrudan okuma erişimine sahip olmasına izin verilmemektedir. Bunun nedeni, bu dosyaları hiç barındırmayan bazı cihazlarda tutarlılığın sağlanmasıdır.

Bu dosyaları kullanan herkese açık API'ler (TrafficStats ve NetworkStatsManager) beklendiği 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 gereksinimi artık uygulanmaktadır

Android 9'da amaç işaretini FLAG_ACTIVITY_NEW_TASK iletmediğiniz sürece etkinlik olmayan bir bağlamdan etkinlik başlatamazsınız. Bu işareti iletmeden bir etkinlik başlatmaya çalışırsanız etkinlik başlamaz ve sistem günlüğe bir mesaj yazdırır.

Ekran döndürme değişiklikleri

Android 9'dan itibaren, dikey döndürme modunda önemli değişiklikler var. Android 8.0'da (API düzeyi 26) kullanıcılar, bir Quicksettings kutusunu veya Görüntüleme ayarlarını kullanarak otomatik döndürme ve dikey döndürme modları arasında geçiş yapabildiler. Dikey mod, döndürme kilidi olarak yeniden adlandırılmıştır ve otomatik döndürme ayarı kapalıyken etkindir. Otomatik döndürme modunda herhangi bir değişiklik yoktur.

Cihaz dönme kilidi modundayken, kullanıcılar ekranlarını üstte görünür olan Etkinlik'in desteklediği herhangi bir rotasyona kilitleyebilirler. Bir Etkinlik her zaman dikey olarak oluşturulacağını varsaymamalıdır. Üstteki Etkinlik, otomatik döndürme modunda birden fazla rotasyonla oluşturulabiliyorsa aynı seçenekler, Etkinliğin screenOrientation ayarına bağlı bazı istisnalarla birlikte rotasyon kilitli modda da sunulmalıdır (aşağıdaki tabloya bakın).

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

Ekran yönü tercihi AndroidManifest'te Etkinlik düzeyinde veya programlı olarak setRequestedOrientation() ile ayarlanabilir.

Döndürme kilidi modu, WindowManager'ın Etkinlik döndürmeyi işlerken kullandığı kullanıcı döndürme tercihini ayarlayarak çalışır. Kullanıcı rotasyonu tercihi aşağıdaki durumlarda değiştirilebilir. Cihazın normal dönüşüne dönmeye yönelik bir ağırlık olduğunu unutmayın. Bu, telefon form faktörüne sahip cihazlar için normalde dikeydir:

  • Kullanıcı bir rotasyon önerisini kabul ettiğinde, rotasyon tercihi öneriye dönüşür.
  • Kullanıcı, zorunlu dikey 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, user, user Otomatik döndürme ve döndürme kilidinde, Etkinlik dikey veya yatay olarak (ve tersi) oluşturulabilir. Hem dikey hem de yatay düzenleri desteklemesi beklenir.
kullanıcıYatay Otomatik döndürme ve döndürme kilidinde, Etkinlik yatay veya ters yatay modda oluşturulabilir. Yalnızca yatay düzenleri destekler.
kullanıcıDikey Otomatik döndürme ve döndürme kilidinde, Etkinlik dikey veya ters dikey olarak oluşturulabilir. Yalnızca dikey düzenleri destekler.
tamKullanıcı Otomatik döndürme ve döndürme kilidinde, Etkinlik dikey veya yatay olarak (ve tersi) oluşturulabilir. Hem dikey hem de yatay düzenleri destekler.

Döndürme kilidi kullanıcılarına, genellikle 180o derecelik ters dikey için kilitleme seçeneği sunulur.
sensör, tamSensör, sensörPortre, sensörYatay Döndürme kilidi modu tercihi yok sayılır ve otomatik döndürme etkin gibi kabul edilir. Bu özelliği yalnızca kullanıcı deneyimi üzerinde son derece dikkatli bir şekilde değerlendirilen istisnai durumlarda kullanın.

Apache HTTP istemcisinin kullanımdan kaldırılması, standart olmayan ClassLoader içeren uygulamaları etkiliyor

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

Uygulama, ClassLoader sistemine açıkça yetki veren standart dışı bir ClassLoader kullanıyorsa bu durumdan etkilenebilir. org.apache.http.* bölgesinde sınıf ararken bu uygulamaların ClassLoader uygulamaya yetki vermesi gerekir. ClassLoader sistemine yetki verirlerse uygulamalar Android 9 veya sonraki sürümlerde NoClassDefFoundError ile başarısız olur. Bunun nedeni, bu sınıfların artık sistem tarafından ClassLoader tanınmamasıdır. Gelecekte benzer sorunların önüne geçmek için, uygulamalar genel olarak sınıfları sisteme doğrudan ClassLoader erişmek yerine ClassLoader uygulaması üzerinden yüklemelidir.

Kameraları numaralandırma

Android 9 cihazlarda çalışan uygulamalar, getCameraIdList() numaralı telefonu arayarak kullanılabilir her kamerayı keşfedebilir. Uygulamalar, cihazda yalnızca tek bir arka kamera veya tek bir ön kamera bulunduğunu varsaymamalıdır.

Örneğin, uygulamanızda ön ve arka kameralar arasında geçiş yapmak için bir düğme varsa, birden fazla ön veya arka kamera arasından seçim yapabilirsiniz. Kamera listesinde yürümeli, her bir kameranın özelliklerini incelemeli ve hangi kameraların kullanıcıya gösterileceğine karar vermelisiniz.