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:
PHONE_STATE
amaç işlemindeki sayıları okumak için hemREAD_CALL_LOG
hem deREAD_PHONE_STATE
iznine sahip olmanız gerekir.onCallStateChanged()
kapsamındaki numaraları okumak için yalnızcaREAD_CALL_LOG
iznine sahip olmanız gerekir.READ_PHONE_STATE
iznine ihtiyacınız yoktur.
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:
WifiManager
kapsamındakigetScanResults()
vegetConnectionInfo()
yöntemleri.WifiP2pManager
kapsamındakidiscoverServices()
veaddServiceRequest()
yöntemleri.NETWORK_STATE_CHANGED_ACTION
yayını.
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
SSLSocket
örneği oluşturulurken bağlanamazsa sistem,NullPointerException
yerine birIOException
gönderir. SSLEngine
sınıfı, oluşan tümclose_notify
uyarılarını düzgün bir şekilde işler.
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ı yaparsaNoSuchProviderException
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 kodluUTC
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 vejava.util.TimeZone.getTimeZone()
değeri tanımaz. Bu davranış, mevcutandroid.icu
davranışıyla tutarlıdır.
- Platform, GMT ve UTC'yi daha iyi işlemektedir; UTC artık GMT ile eş anlamlı değildir.
android.icu.text.NumberFormat.getInstance(ULocale, PLURALCURRENCYSTYLE).parse(String)
yöntemi, geçerli para birimi metni ayrıştırılırken bileParseException
hatası verebilir.PLURALCURRENCYSTYLE
stili para birimi metinleri için Android 7.0'dan (API düzeyi 24) itibaren kullanılabilenNumberFormat.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()
veyaNewStringUTF()
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.