Önceki sürümlerde olduğu gibi Android 17 de uygulamanızı etkileyebilecek davranış değişiklikleri içerir. Aşağıdaki davranış değişiklikleri yalnızca Android 17 veya sonraki sürümleri hedefleyen uygulamalar için geçerlidir. Uygulamanız Android 17 veya sonraki sürümleri hedefliyorsa uygulamanızı, geçerli olduğu durumlarda bu davranışları destekleyecek şekilde değiştirmeniz gerekir.
Uygulamanızın targetSdkVersion değerinden bağımsız olarak Android 17'de çalışan tüm uygulamaları etkileyen davranış değişiklikleri listesini de inceleyin.
Kullanıcı deneyimi ve sistem arayüzü
Android 17, daha tutarlı ve sezgisel bir kullanıcı deneyimi oluşturmayı amaçlayan aşağıdaki değişiklikleri içerir.
Bellek sınırı widget'ı
Beginning with Android 17, for apps targeting
Android 17 (API level 37) or higher, the system enforces a strict memory
limit (1.5 * screen width * screen height * 4) against the combined memory usage
of both Bitmaps and Icons present in the RemoteViews parcel. Exceeding these
limits throws a fatal IllegalArgumentException and crashes the app's process.
For more information, see UpdateAppWidget.
Temel işlevler
Android 17, Android sisteminin çeşitli temel özelliklerini değiştiren veya genişleten aşağıdaki değişiklikleri içerir.
MessageQueue'nun yeni kilit içermeyen uygulaması
Android 17'den itibaren, Android 17'yi (API düzeyi 37) veya sonraki sürümleri hedefleyen uygulamalar, android.os.MessageQueue için yeni bir kilit içermeyen uygulama alır. Yeni uygulama performansı artırır ve kaçırılan kare sayısını azaltır ancak MessageQueue özel alanlarını ve yöntemlerini yansıtan istemcilerin çalışmasını bozabilir.
Azaltma stratejileri de dahil olmak üzere daha fazla bilgi için MessageQueue davranış değişikliği rehberi başlıklı makaleyi inceleyin.
Statik nihai alanlar artık değiştirilemiyor
Android 17 veya sonraki sürümlerde çalışan ve Android 17'yi (API düzeyi 37) veya sonraki sürümleri hedefleyen uygulamalar static final alanlarını değiştiremez. Bir uygulama, yansıtma kullanarak static final alanını değiştirmeye çalışırsa IllegalAccessException hatasına neden olur. Bu alanlardan birini JNI API'leri (ör. SetStaticLongField()) aracılığıyla değiştirmeye çalışmak uygulamanın kilitlenmesine neden olur.
Erişilebilirlik
Android 17, erişilebilirliği iyileştirmek için aşağıdaki değişiklikleri yapar.
Karmaşık IME fiziksel klavye yazma özelliğinin erişilebilirlik desteği
This feature introduces new AccessibilityEvent and TextAttribute
APIs to enhance screen reader spoken feedback for CJKV language input. CJKV IME
apps can now signal whether a text conversion candidate has been selected during
text composition. Apps with edit fields can specify text change types when
sending text changed accessibility events.
For example, apps can specify that a text change occurred during text
composition, or that a text change resulted from a commit.
Doing this enables accessibility
services such as screen readers to deliver more precise feedback based on the
nature of the text modification.
App adoption
IME Apps: When setting composing text in edit fields, IMEs can use
TextAttribute.Builder.setTextSuggestionSelected()to indicate whether a specific conversion candidate was selected.Apps with Edit Fields: Apps that maintain a custom
InputConnectioncan retrieve candidate selection data by callingTextAttribute.isTextSuggestionSelected(). These apps should then callAccessibilityEvent.setTextChangeTypes()when dispatchingTYPE_VIEW_TEXT_CHANGEDevents. Apps targeting Android 17 (API level 37) that use the standardTextViewwill have this feature enabled by default. (That is,TextViewwill handle retrieving data from the IME and setting text change types when sending events to accessibility services).Accessibility Services: Accessibility services that process
TYPE_VIEW_TEXT_CHANGEDevents can callAccessibilityEvent.getTextChangeTypes()to identify the nature of the modification and adjust their feedback strategies accordingly.
Gizlilik
Android 17, kullanıcı gizliliğini iyileştirmek için aşağıdaki değişiklikleri içerir.
ECH (Encrypted Client Hello) etkinleştirildi
Android 17 introduces platform support for Encrypted Client Hello (ECH), a TLS extension that enhances user privacy by encrypting the Server Name Indication (SNI) in the TLS handshake. This encryption helps prevent network observers from easily identifying the specific domain your app is connecting to.
For apps targeting Android 17 (API level 37) or higher, ECH is used for TLS connections. ECH is active only if the networking library used by the app (for example, HttpEngine, WebView, or OkHttp) has integrated ECH support and the remote server also supports the ECH protocol. If ECH cannot be negotiated, the client sends an ECH extension with randomized contents (a mechanism called ECH GREASE). See RFC 9849 for more details on how ECH GREASE works.
To allow apps to customize this behavior, Android 17 adds a new
<domainEncryption> element to the Network Security Configuration file.
Developers can use <domainEncryption> within <base-config> or
<domain-config> tags to select an ECH mode (for example,
"enabled" or "disabled") on a global or per-domain basis.
For more information, see the Encrypted Client Hello documentation.
Android 17'yi hedefleyen uygulamalar için yerel ağ izni gerekiyor
Android 17 introduces the ACCESS_LOCAL_NETWORK runtime permission
to protect users from unauthorized local network access. Because this falls
under the existing NEARBY_DEVICES permission group, users who have already
granted other NEARBY_DEVICES permissions aren't prompted again. This new
requirement prevents malicious apps from exploiting unrestricted local network
access for covert user tracking and fingerprinting. By declaring and requesting
this permission, your app can discover and connect to devices on the local area
network (LAN), such as smart home devices or casting receivers.
Apps targeting Android 17 (API level 37) or higher now have two paths to maintain communication with LAN devices: Adopt system-mediated, privacy-preserving device pickers to skip the permission prompt, or explicitly request this new permission at runtime to maintain local network communication.
For more information, see the Local network permission documentation.
Şifreleri fiziksel cihazlardan gizleme
Android 17'yi (API düzeyi 37) veya sonraki sürümleri hedefleyen bir uygulamada kullanıcı fiziksel bir giriş cihazı (ör. harici klavye) kullanıyorsa Android işletim sistemi, şifre alanındaki tüm karakterlere yeni show_passwords_physical ayarını uygular. Bu ayar, varsayılan olarak tüm şifre karakterlerini gizler.
Android sistemi, kullanıcının şifreyi yanlış yazıp yazmadığını görmesine yardımcı olmak için en son yazılan şifre karakterini gösterir. Ancak bu, daha büyük harici klavyelerde çok daha az gereklidir. Ayrıca, harici klavyesi olan cihazlarda genellikle daha büyük ekranlar bulunur. Bu da yazılan şifrenin başkaları tarafından görülme tehlikesini artırır.
Kullanıcı cihazın dokunmatik ekranını kullanıyorsa sistem yeni show_passwords_touch ayarını uygular.
Standart SMS mesajları için tek kullanımlık şifre koruması
Android 17'den itibaren Android, SMS OTP korumasını standart SMS iletilerini (WebOTP veya SMS Retriever biçimlerini kullanmayan OTP içeren SMS iletileri) kapsayacak şekilde genişletiyor. Android 17 (API düzeyi 37) veya sonraki sürümleri hedefleyen çoğu uygulamada bu SMS mesajları, alındıktan üç saat sonra kullanılabilir. Bu gecikme, tek kullanımlık şifrelerin ele geçirilmesini önlemeye yardımcı olmak için uygulanır. Bu üç saatlik gecikme süresinde SMS_RECEIVED_ACTION yayını bekletilir ve SMS sağlayıcı veritabanı sorguları filtrelenir. SMS mesajı, gecikmenin ardından bu uygulamalarda kullanılabilir.
Varsayılan SMS asistanı uygulaması ve bağlı cihaz yardımcı uygulamaları gibi belirli uygulamalar bu gecikmeden muaftır. OTP çıkarma için SMS mesajlarını okumaya dayalı tüm uygulamalar, işlevselliğin devam etmesini sağlamak amacıyla SMS Retriever veya SMS User Consent API'lerini kullanmaya geçmelidir.
Güvenlik
Android 17, cihaz ve uygulama güvenliğiyle ilgili aşağıdaki iyileştirmeleri sunar.
Etkinlik Güvenliği
Android 17'de platform, "varsayılan olarak güvenli" bir mimariye geçişini sürdürüyor. Bu kapsamda, kimlik avı, etkileşim ele geçirme ve confused deputy saldırıları gibi yüksek düzeyde ciddi güvenlik açıklarını azaltmak için tasarlanmış bir dizi iyileştirme sunuluyor. Bu güncelleme, uygulama uyumluluğunu ve kullanıcı korumasını sürdürmek için geliştiricilerin yeni güvenlik standartlarını açıkça etkinleştirmesini gerektirir.
Geliştiriciler için önemli etkiler:
- BAL'ı güçlendirme ve gelişmiş izin verme: Korumaları
IntentSender'a genişleterek Arka Planda Etkinlik Başlatma (BAL) kısıtlamalarını iyileştiriyoruz. Geliştiricilerin eskiMODE_BACKGROUND_ACTIVITY_START_ALLOWEDsabitinden geçiş yapması gerekir. Bunun yerine,MODE_BACKGROUND_ACTIVITY_START_ALLOW_IF_VISIBLEgibi ayrıntılı kontrolleri kullanmanız gerekir. Bu kontrol, etkinlik başlatma işlemlerini arayan uygulamanın görünür olduğu senaryolarla kısıtlayarak saldırı yüzeyini önemli ölçüde azaltır. - Adaptasyon araçları: Geliştiriciler, eski kalıpları belirlemek ve gelecekteki hedef SDK gereksinimlerine hazırlıklı olmak için yüksek düzey modu ve güncellenmiş hata analizi kontrollerini kullanmalıdır.
CT'yi varsayılan olarak etkinleştirme
Android 17'yi (API düzeyi 37) veya sonraki sürümleri hedefleyen uygulamalarda sertifika şeffaflığı (CT) varsayılan olarak etkindir. (Android 16'da CT kullanılabilir ancak uygulamaların kaydolması gerekir.)
Daha güvenli yerel DCL—C
If your app targets Android 17 (API level 37) or higher, the Safer Dynamic Code Loading (DCL) protection introduced in Android 14 for DEX and JAR files now extends to native libraries.
All native files loaded using System.load() must be marked as read-only.
Otherwise, the system throws UnsatisfiedLinkError.
We recommend that apps avoid dynamically loading code whenever possible, as doing so greatly increases the risk that an app can be compromised by code injection or code tampering.
CP2 veri görünümünde kimliği tanımlayabilecek bilgi (PII) alanlarını kısıtlama
For apps targeting Android 17 (API level Android 17 (API level 37)) and higher, Contacts Provider 2 (CP2) restricts certain columns containing Personally Identifiable Information (PII) from the data view. When this change is enabled, these columns are removed from the data view to enhance user privacy. The restricted columns include:
Apps that are using these columns from ContactsContract.Data
can extract them from ContactsContract.RawContacts
instead, by joining with RAW_CONTACT_ID.
CP2'de sıkı SQL kontrollerini zorunlu kılma
For apps targeting Android 17 (API level Android 17 (API level 37)) and
higher, Contacts Provider 2 (CP2) enforces strict SQL query validation when
the ContactsContract.Data table is accessed without
READ_CONTACTS permission.
With this change, if an app doesn't have READ_CONTACTS
permission, StrictColumns and
StrictGrammar options are set when querying
the ContactsContract.Data table. If a query
uses a pattern that isn't compatible with these, it will be
rejected and cause an exception to be thrown.
Intelligence
Android 17, sistem zekasıyla ilgili aşağıdaki değişiklikleri içerir.
setContentCaptureEnabled'ın desteğinin sonlandırılması
Content Capture is enabled by default on certain devices to allow on-device AI features to analyze screen contents for intelligent experiences.
Starting in Android 17, the
ContentCaptureManager.setContentCaptureEnabled(boolean)
API method is deprecated. For apps that target Android 17 (API level 37) or
higher, calling setContentCaptureEnabled(false) no longer disables Content
Capture.
If your app needs to continue disabling Content Capture or restrict screen
contents from being captured by the system, you must transition to using the
FLAG_SECURE window layout parameter.
To disable Content Capture, set the FLAG_SECURE flag on your window as shown
in the following example:
Kotlin
window.setFlags(
WindowManager.LayoutParams.FLAG_SECURE,
WindowManager.LayoutParams.FLAG_SECURE
)
Java
getWindow().setFlags(
WindowManager.LayoutParams.FLAG_SECURE,
WindowManager.LayoutParams.FLAG_SECURE
);
For more details, see the
WindowManager.LayoutParams.FLAG_SECURE reference
documentation.
Medya
Android 17, medya davranışıyla ilgili aşağıdaki değişiklikleri içerir.
Arka planda ses sağlamlaştırma
Android 17'den itibaren ses çerçevesi, bu değişikliklerin kullanıcı tarafından kasıtlı olarak başlatılmasını sağlamak için ses çalma, ses odağı istekleri ve ses seviyesi değişikliği API'leri dahil olmak üzere arka plandaki ses etkileşimleriyle ilgili kısıtlamaları zorunlu kılar.
Tüm uygulamalar için geçerli olan bazı ses kısıtlamaları vardır. Ancak bir uygulama Android 17'yi (API düzeyi 37) hedefliyorsa kısıtlamalar daha katıdır. Bu uygulamalardan biri arka plandayken sesle etkileşime giriyorsa ön plan hizmeti çalıştırıyor olmalıdır. Ayrıca, uygulama aşağıdaki koşullardan birini veya her ikisini de karşılamalıdır:
- Ön plan hizmeti, kullanım sırasında (WIU) özelliklerine sahip olmalıdır.
- Uygulamada kesin zamanlı alarm izni olmalı ve
USAGE_ALARMses akışlarıyla etkileşimde bulunulmalıdır.
Azaltma stratejileri de dahil olmak üzere daha fazla bilgi için Arka planda ses sağlamlaştırma başlıklı makaleyi inceleyin.
Cihaz form faktörleri
Android 17, çeşitli cihaz boyutları ve form faktörlerinde kullanıcı deneyimini iyileştirmek için aşağıdaki değişiklikleri içerir.
Büyük ekranlarda (sw>=600dp) yön, yeniden boyutlandırılabilirlik ve en-boy oranı kısıtlamalarını yoksaymak için platform API'sinde yapılan değişiklikler
Android 16'da, API düzeyi 36 veya sonraki sürümleri hedefleyen uygulamalar için büyük ekranlarda (sw >= 600 dp) yön, en-boy oranı ve yeniden boyutlandırma kısıtlamalarını yoksaymak amacıyla Platform API değişiklikleri yaptık. Geliştiriciler, SDK 36 ile bu değişiklikleri devre dışı bırakabilir. Ancak bu devre dışı bırakma seçeneği, Android 17 (API düzeyi 37) veya sonraki sürümleri hedefleyen uygulamalarda artık kullanılamayacaktır.
Daha fazla bilgi için Yön ve yeniden boyutlandırma kısıtlamaları yoksayılır başlıklı makaleyi inceleyin.
Bağlantı
Android 17, tutarlılığı artırmak ve Bluetooth RFCOMM soketleri için standart Java InputStream davranışı ile uyumlu hale getirmek amacıyla aşağıdaki değişikliği sunar.
RFCOMM için tutarlı BluetoothSocket read() davranışı
For apps targeting Android 17 (API level 37), the
read() method of the InputStream obtained from an
RFCOMM-based BluetoothSocket now returns -1 when the
socket is closed or the connection is dropped.
This change makes RFCOMM socket behavior consistent with LE CoC sockets and
aligns with the standard InputStream.read()
documentation, which states that -1 is returned when the end of the stream is
reached.
Apps that rely solely on catching an IOException to break out of a read loop may
be impacted by this change and should update the BluetoothSocket read loops to
explicitly check for a return value of -1. This ensures the loop terminates
correctly when the remote device disconnects or the socket is closed. For an
example of the recommended implementation, see the
code snippet in the Transfer Bluetooth data
guide.