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

Android 9 (API düzeyi 28), Android sisteminde bazı değişiklikler yaptık. Aşağıdaki davranış değişiklikleri, uygulamaların Android 9 platformunda çalıştırdıkları tüm uygulamalar için, hedefledikleri API düzeyi ne olursa olsun geçerlidir. Tüm geliştiriciler bu değişiklikleri incelemeli ve uygulamalarını, uygun olduğu durumlarda uygun şekilde desteklenecek şekilde değiştirmelidir.

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 ve 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 sunuyor. Bu değişiklikler ve Android 9'dan önce zaten mevcut olan özellikler, sistem kaynaklarının en çok ihtiyaç duyan uygulamalar için kullanılabilir olmasını sağlamaya yardımcı oluyor.

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

Gizlilikle ilgili değişiklikler

Android 9, kullanıcı gizliliğini geliştirmek için arka plan uygulamaları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üne bakılmaksızın 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ş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ştirilebilir 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 bir ön plan hizmeti kullanın.

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

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

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

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 grupların değişmesi ve çalışma zamanında verilmesi nedeniyle kullanıcı, uygulamanızın telefon arama kaydı bilgilerine erişimini reddedebilir. Bu durumda, uygulamanız bilgilere erişim eksikliğini sorunsuz bir şekilde halledebilmelidir.

Uygulamanız, çalışma zamanı izinleriyle ilgili en iyi uygulamaları zaten kullanıyorsa 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) ve bu numaralara PhoneStateListener sınıfından erişilebilir. Ancak READ_CALL_LOG izni olmadan 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 konum ve bağlantı bilgilerine kısıtlı erişim

Android 9'da, uygulamaların kablosuz ağ taraması gerçekleştirmesine ilişkin izin şartları önceki sürümlerden daha katıdır. Ayrıntılı bilgi için Kablosuz ağ taraması kısıtlamaları başlıklı makaleyi 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).

Kablosuz ağ hizmeti 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 NETWORK_STATE_CHANGED_ACTION sistem yayını artık SSID (eski adıyla STR_SSID), BSSID (eski adıyla EXTRA_BSSID) veya bağlantı bilgilerini (eski adıyla EXTRA_NETWORK_INFO) içermez. Uygulamanızın bu bilgilere ihtiyacı varsa bunun yerine getConnectionInfo() numaralı telefonu arayı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ç sağlamaz:

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

Platform, uygulama kararlılığı ve uyumluluğu sağlamak için SDK olmayan bazı yöntem ve alanların kullanımını kısıtlar. Bu yöntemlere ve alanlara doğrudan, düşünme yoluyla veya JNI kullanarak erişmeye çalışsanız bile bu kısıtlamalar geçerlidir. Uygulamanız, Android 9'da bu kısıtlanmış arayüzlere erişmeye devam edebilir. Platform, bunları dikkatinize sunmak için durum iletilerini ve günlük girişlerini kullanır. Uygulamanızda böyle bir durum mesajı gösteriliyorsa kısıtlanmış 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 hata bildiriminde bulunabilirsiniz.

SDK Dışı Arayüzlerle İlgili Kısıtlamalar bölümünde de önemli bilgiler yer almaktadır. Uygulamanızın düzgün bir şekilde çalışmaya devam ettiğinden emin olmak için kodu 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ı ve işlenmesiyle ilgili çeşitli değişiklikler sunar.

Parametre ve algoritma uygulamalarını kodlama

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 itibarıyla 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ı için istekte bulunurken uyarı alırsınız. Ancak Android 9'u hedeflerseniz bu isteklerin her biri bir NoSuchAlgorithmException döndürür.

Diğer değişiklikler

Android 9'da, kriptografiyle ilgili birkaç değişiklik daha sunulmaktadır:

  • PBE anahtarlarını kullanırken Bouncy Castle bir başlatma vektörü (IV) bekliyorsa ve uygulamanız 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") çağrısı yaparsa NoSuchProviderException oluşur.
  • Uygulamanız, RSA anahtarlarını anahtar yapısından daha büyük arabelleklerden ayrıştırırsa artık bir istisna olmaz.

Android'in kriptografik ö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'ler) yönelik desteği 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 benimseilebilir bir 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 dahil olmak üzere birç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 işlemektedir; 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 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çiminin biçimlendirilmesi, birçok yerel ayar için yerelleştirilmiş uzun bir dize oluşturur. Daha önce, UTC için "UTC" ve GMT için "GMT+00:00" gibi dizeler üretiyordu.
      • zzzz ayrıştırması, "Evrensel Eşgüdümlü Zaman" ve "Greenwich Saati" gibi dizeleri tanır.
      • Uygulamalar, zzzz için tüm dillerde "UTC" veya "GMT+00:00" çıkışının alındığını varsayarsa uyumluluk sorunlarıyla karşılaşabilir.
    • java.text.DateFormatSymbols.getZoneStrings() 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 saat dilimi varyantları, GMT+00:00 haline gelir. Başka bir ad olmadığında, sabit kodlu UTC dizesi yerine standart yedek 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, geçerli 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 özelliğini kullanarak bu sorunun önüne geçebilirsiniz.

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 sunar. Bu değişiklikler, geliştiricilerin çerçeve destekli, herkese açık API'leri kullanmalarına yardımcı olur. Ancak değişiklikler, üçüncü taraf kitaplıklar veya özel mantık kullanarak testler 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ık halinde yeniden düzenler: android.test.base, android.test.runner ve android.test.mock. Bu değişiklik, projenizin bağımlılıklarıyla en iyi çalışan bir JUnit sürümünde testler çalıştırmanızı sağlar. 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ı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şiklikleri

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 olan bağımsız değişkenler sağlamasını gerektiriyordu ve bu da API'yi geçersiz hale getiriyor.

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ümlere kıyasla daha katı bir şekilde uygular. Söz konusu değişiklikler şunlardır:

  • UTF-8'in en kısa olmayan biçimi (ör. <C0, AF>), hatalı olarak kabul edilir.
  • UTF-8'in vekil biçimi (ör. U+D800..U+DFFF) hatalı olarak kabul edilir.
  • 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" ifadesinin 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ında kullanılabilir adları kullanarak veya SAN uzantısı olmadığında commonName (CN) uzantısına geri döner.

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 ile bir sertifika sunması gerekir. Ana makine adıyla eşleşen 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şlemleri olarak kabul edilir. Ana iş parçacığındaki işlemleri engellemek, duraklatmalara veya jank'a neden olabilir.

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

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

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

Sayısal bir 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 kapsayıcısı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 istiyorsanız 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ı bir bilgi grubu raporladı ancak NET_CAPABILITY_NOT_VPN belirtmedi. Bu sınırlı bilgi, VPN kullanmanın uygulama kullanıcısı için ödeme alınıp alınmayacağının belirlenmesini zorlaştırıyordu. Örneğin, NET_CAPABILITY_NOT_METERED'i kontrol etmek temel ağların ölçülü olup olmadığını belirlemez.

Android 9 ve sonraki sürümlerde, bir VPN setUnderlyingNetworks() yöntemini çağırdığında Android sistemi alttaki 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ılamayacak

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 dosyalara sahip olmayan 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 şartı artık zorunlu kılındı

Android 9'da amaç işaretini FLAG_ACTIVITY_NEW_TASK iletmediğiniz sürece etkinlik dışı 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 rotasyon modunda önemli değişiklikler yapılmıştır. Android 8.0'da (API düzeyi 26) kullanıcılar, Hızlı Ayarlar kutusunu veya Ekran ayarlarını kullanarak otomatik döndürme ile dikey rotasyon modları arasında geçiş yapabilirler. Dikey mod, döndürme kilidi olarak yeniden adlandırılmıştır ve otomatik döndürme ayarı devre dışı bırakıldığında etkindir. Otomatik döndürme modunda herhangi bir değişiklik yoktur.

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

Belirli bir yön isteğinde bulunan etkinlikler (örneğin, 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 programatik olarak setRequestedOrientation() ile ayarlanabilir.

Döndürme kilidi modu, WindowManager'ın Etkinlik rotasyonunu 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 doğal dönüşüne geri dönme eğiliminin olduğunu unutmayın. Bu, normalde telefon form faktörüne sahip cihazlarda dikeydir:

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

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

Ekran Yönlendirme Davranış
belirtilmedi, kullanıcı Otomatik döndürme ve döndürme kilidinde, Etkinlik dikey veya yatay (ve ters) yönde oluşturulabilir. Bu özellik, hem dikey hem de yatay düzenleri destekler.
kullanıcıYatayı Otomatik döndürme ve döndürme kilidinde, Etkinlik yatay veya ters yatay yönde oluşturulabilir. Yalnızca yatay düzenleri destekler.
kullanıcıPortresi 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 (ve ters) yönde oluşturulabilir. Hem dikey hem de yatay düzenler desteklenir.

Rotasyon kilidi kullanıcılarına, genellikle 180o (ters) dikey yönde kilitleme seçeneği sunulur.
sensör, fullSensor, sensörPortrait, sensörLandscape Döndürme kilidi modu tercihi yok sayılır ve otomatik döndürme etkin gibi kabul edilir. Bunu yalnızca kullanıcı deneyimiyle ilgili çok dikkatli bir değerlendirme yapılan istisnai durumlarda kullanın.

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

Android 6.0'da 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 bir etkisi yoktur. Bununla birlikte, uygulamalar Android 9 veya sonraki sürümleri hedeflemese bile standart olmayan bir ClassLoader yapısı kullanan belirli uygulamaları etkileyebilir.

ClassLoader sistemine açıkça yetki veren standart olmayan bir ClassLoader kullanan uygulamalar bu durumdan etkilenebilir. org.apache.http.* bölgesinde sınıf ararken bu uygulamaların bunun yerine ClassLoader uygulamasına yetki vermesi gerekir. ClassLoader adlı sisteme 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 ClassLoader sistemi tarafından 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 mevcut her kamerayı keşfedebilir. Uygulama, cihazda yalnızca tek bir arka kamera veya tek bir ön kamera olduğunu varsaymamalıdır.

Örneğin, uygulamanızda ön ve arka kameralar arasında geçiş yapmak için bir düğme varsa seçebileceğiniz birden fazla ön veya arka kamera olabilir. Kamera listesinde gezinmeniz, her kameranın özelliklerini incelemeniz ve kullanıcıya hangi kameraların gösterileceğine karar vermeniz gerekir.