Android 15 มีการเปลี่ยนแปลงลักษณะการทำงานที่อาจส่งผลต่อแอปของคุณเช่นเดียวกับรุ่นก่อนหน้า การเปลี่ยนแปลงลักษณะการทำงานต่อไปนี้จะมีผลกับแอปที่กำหนดเป้าหมายเป็น Android 15 ขึ้นไปเท่านั้น หากแอปกำหนดเป้าหมายเป็น Android 15 ขึ้นไป คุณควรแก้ไขแอปให้รองรับลักษณะการทำงานเหล่านี้อย่างเหมาะสมในกรณีที่ เกี่ยวข้อง
นอกจากนี้ โปรดตรวจสอบรายการการเปลี่ยนแปลงลักษณะการทำงานที่มีผลกับแอปทั้งหมด
ที่ทำงานบน Android 15 ไม่ว่า targetSdkVersion
ของแอปจะเป็นอย่างไร
ฟังก์ชันหลัก
Android 15 จะแก้ไขหรือขยายความสามารถหลักต่างๆ ของระบบ Android
การเปลี่ยนแปลงบริการที่ทำงานอยู่เบื้องหน้า
We are making the following changes to foreground services with Android 15.
- Data sync foreground service timeout behavior
- New media processing foreground service type
- Restrictions on
BOOT_COMPLETED
broadcast receivers launching foreground services - Restrictions on starting foreground services while an app holds the
SYSTEM_ALERT_WINDOW
permission
Data sync foreground service timeout behavior
Android 15 introduces a new timeout behavior to dataSync
for apps targeting
Android 15 (API level 35) or higher. This behavior also applies to the new
mediaProcessing
foreground service type.
The system permits an app's dataSync
services to run for a total of 6 hours
in a 24-hour period, after which the system calls the running service's
Service.onTimeout(int, int)
method (introduced in Android
15). At this time, the service has a few seconds to call
Service.stopSelf()
. When Service.onTimeout()
is called, the
service is no longer considered a foreground service. If the service does not
call Service.stopSelf()
, the system throws an internal exception. The
exception is logged in Logcat with the following message:
Fatal Exception: android.app.RemoteServiceException: "A foreground service of
type dataSync did not stop within its timeout: [component name]"
To avoid problems with this behavior change, you can do one or more of the following:
- Have your service implement the new
Service.onTimeout(int, int)
method. When your app receives the callback, make sure to callstopSelf()
within a few seconds. (If you don't stop the app right away, the system generates a failure.) - Make sure your app's
dataSync
services don't run for more than a total of 6 hours in any 24-hour period (unless the user interacts with the app, resetting the timer). - Only start
dataSync
foreground services as a result of direct user interaction; since your app is in the foreground when the service starts, your service has the full six hours after the app goes to the background. - Instead of using a
dataSync
foreground service, use an alternative API.
If your app's dataSync
foreground services have run for 6 hours in the last
24, you cannot start another dataSync
foreground service unless the user
has brought your app to the foreground (which resets the timer). If you try to
start another dataSync
foreground service, the system throws
ForegroundServiceStartNotAllowedException
with an error message like "Time limit already exhausted for foreground service
type dataSync".
Testing
To test your app's behavior, you can enable data sync timeouts even if your app
is not targeting Android 15 (as long as the app is running on an Android 15
device). To enable timeouts, run the following adb
command:
adb shell am compat enable FGS_INTRODUCE_TIME_LIMITS your-package-name
You can also adjust the timeout period, to make it easier to test how your
app behaves when the limit is reached. To set a new timeout period, run the
following adb
command:
adb shell device_config put activity_manager data_sync_fgs_timeout_duration duration-in-milliseconds
New media processing foreground service type
Android 15 ขอแนะนำบริการที่ทำงานอยู่เบื้องหน้าประเภทใหม่ ได้แก่ mediaProcessing
บริการประเภทนี้เหมาะสำหรับการดำเนินการต่างๆ เช่น การแปลงไฟล์สื่อ เช่น แอปสื่ออาจดาวน์โหลดไฟล์เสียงและต้องแปลงไฟล์เป็นรูปแบบอื่นก่อนเล่น คุณสามารถใช้mediaProcessing
บริการที่ทำงานอยู่เบื้องหน้าเพื่อให้ Conversion ดำเนินต่อไปได้แม้ว่าแอปจะทำงานอยู่เบื้องหลัง
ระบบอนุญาตให้บริการ mediaProcessing
ของแอปทำงานได้นาน 6 ชั่วโมงโดยรวมในระยะเวลา 24 ชั่วโมง หลังจากนั้นระบบจะเรียกใช้เมธอด Service.onTimeout(int, int)
ของบริการที่ทำงานอยู่ (เปิดตัวใน Android 15) ขณะนี้บริการมีเวลา 2-3 วินาทีในการโทรไปที่ Service.stopSelf()
หากบริการไม่ได้เรียกใช้ Service.stopSelf()
ระบบจะแสดงข้อยกเว้นภายใน ระบบจะบันทึกข้อยกเว้นใน Logcat พร้อมข้อความต่อไปนี้
Fatal Exception: android.app.RemoteServiceException: "A foreground service of
type mediaProcessing did not stop within its timeout: [component name]"
หากต้องการหลีกเลี่ยงการมีข้อยกเว้น ให้ทําอย่างใดอย่างหนึ่งต่อไปนี้
- ให้บริการของคุณใช้วิธีการ
Service.onTimeout(int, int)
ใหม่ เมื่อแอปได้รับการติดต่อกลับ โปรดโทรหาstopSelf()
ภายในไม่กี่วินาที (หากคุณไม่หยุดแอปในทันที ระบบจะล้มเหลว) - ตรวจสอบว่าบริการ
mediaProcessing
ของแอปไม่ทำงานเป็นเวลานานกว่า 6 ชั่วโมงในทุกๆ 24 ชั่วโมง (เว้นแต่ผู้ใช้โต้ตอบกับแอป จะเป็นการรีเซ็ตตัวจับเวลา) - เริ่มบริการที่ทำงานอยู่เบื้องหน้า
mediaProcessing
เฉพาะในกรณีที่มีการโต้ตอบโดยตรงจากผู้ใช้ เนื่องจากแอปของคุณอยู่เบื้องหน้าเมื่อบริการเริ่มทำงาน บริการของคุณจึงมีเวลา 6 ชั่วโมงเต็มหลังจากที่แอปเปลี่ยนไปทำงานในเบื้องหลัง - ใช้ API อื่น เช่น WorkManager แทนบริการที่ทำงานอยู่เบื้องหน้าของ
mediaProcessing
หากบริการที่ทำงานอยู่เบื้องหน้า mediaProcessing
ของแอปทำงานเป็นเวลา 6 ชั่วโมงในช่วง 24 ชั่วโมงที่ผ่านมา คุณจะไม่สามารถเริ่มบริการที่ทำงานอยู่เบื้องหน้า mediaProcessing
อื่นได้เว้นแต่ผู้ใช้จะนำแอปของคุณไปไว้ที่เบื้องหน้า (ซึ่งจะรีเซ็ตตัวจับเวลา) หากคุณพยายามเริ่มบริการที่ทำงานอยู่เบื้องหน้า mediaProcessing
รายการอื่น ระบบจะแสดงForegroundServiceStartNotAllowedException
พร้อมข้อความแสดงข้อผิดพลาด เช่น "บริการที่ทำงานอยู่เบื้องหน้าประเภท mediaProcessing หมดเวลาแล้ว"
ดูข้อมูลเพิ่มเติมเกี่ยวกับประเภทบริการ mediaProcessing
ได้ที่การเปลี่ยนแปลงประเภทบริการที่ทำงานอยู่เบื้องหน้าสำหรับ Android 15: การประมวลผลสื่อ
การทดสอบ
หากต้องการทดสอบลักษณะการทำงานของแอป ให้เปิดใช้ระยะหมดเวลาการประมวลผลสื่อ แม้ว่าแอปจะไม่ได้กำหนดเป้าหมายเป็น Android 15 ก็ตาม (ตราบใดที่แอปทำงานอยู่ในอุปกรณ์ Android 15) หากต้องการเปิดใช้การหมดเวลา ให้เรียกใช้คำสั่ง adb
ต่อไปนี้
adb shell am compat enable FGS_INTRODUCE_TIME_LIMITS your-package-name
นอกจากนี้ คุณยังปรับระยะเวลาหมดเวลาเพื่อให้ทดสอบลักษณะการทํางานของแอปเมื่อถึงขีดจํากัดได้ง่ายขึ้นได้ด้วย หากต้องการตั้งค่าระยะเวลาหมดเวลาใหม่ ให้เรียกใช้คำสั่ง adb
ต่อไปนี้
adb shell device_config put activity_manager media_processing_fgs_timeout_duration duration-in-milliseconds
Restrictions on BOOT_COMPLETED
broadcast receivers launching foreground services
มีข้อจำกัดใหม่ในการเปิดตัว Broadcast Receiver ของ BOOT_COMPLETED
บริการที่ทำงานอยู่เบื้องหน้า ระบบไม่อนุญาตให้ Receiver BOOT_COMPLETED
เปิดบริการที่ทำงานอยู่เบื้องหน้าประเภทต่อไปนี้
dataSync
camera
mediaPlayback
phoneCall
mediaProjection
microphone
(ข้อจำกัดนี้มีการใช้มาเป็นเวลาmicrophone
ตั้งแต่ Android 14)
หากตัวรับสัญญาณ BOOT_COMPLETED
พยายามเปิดเบื้องหน้าประเภทใดก็ตามเหล่านี้
ระบบอาจไม่แสดง ForegroundServiceStartNotAllowedException
การทดสอบ
หากต้องการทดสอบลักษณะการทำงานของแอป คุณสามารถเปิดใช้ข้อจำกัดใหม่เหล่านี้ได้ แม้ว่า
แอปไม่ได้กําหนดเป้าหมายเป็น Android 15 (ตราบใดที่แอปยังทํางานอยู่ใน Android 15
อุปกรณ์) เรียกใช้คำสั่ง adb
ต่อไปนี้
adb shell am compat enable FGS_BOOT_COMPLETED_RESTRICTIONS your-package-name
หากต้องการส่งประกาศBOOT_COMPLETED
โดยไม่ต้องรีสตาร์ทอุปกรณ์ ให้ทำดังนี้
เรียกใช้คำสั่ง adb
ต่อไปนี้
adb shell am broadcast -a android.intent.action.BOOT_COMPLETED your-package-name
Restrictions on starting foreground services while an app holds the SYSTEM_ALERT_WINDOW
permission
ก่อนหน้านี้ หากแอปมีสิทธิ์ SYSTEM_ALERT_WINDOW
แอปจะเปิดบริการที่ทำงานอยู่เบื้องหน้าได้แม้ว่าในขณะนั้นแอปจะทำงานอยู่เบื้องหลังก็ตาม (ตามที่ได้อธิบายไว้ในการยกเว้นจากการจำกัดการเริ่มทำงานในเบื้องหลัง)
หากแอปกำหนดเป้าหมายเป็น Android 15 การยกเว้นนี้จะแคบลงแล้ว ตอนนี้แอปต้องมีสิทธิ์ SYSTEM_ALERT_WINDOW
และต้องมีหน้าต่างวางซ้อนที่มองเห็นได้ กล่าวคือ แอปต้องเปิดหน้าต่าง TYPE_APPLICATION_OVERLAY
ก่อน และหน้าต่างต้องปรากฏขึ้นก่อนที่คุณจะเริ่มบริการที่ทำงานอยู่เบื้องหน้า
หากแอปพยายามเริ่มบริการที่ทำงานอยู่เบื้องหน้าจากเบื้องหลังโดยไม่เป็นไปตามข้อกำหนดใหม่เหล่านี้ (และไม่มีข้อยกเว้นอื่นๆ) ระบบจะแสดงข้อผิดพลาด ForegroundServiceStartNotAllowedException
หากแอปประกาศสิทธิ์ SYSTEM_ALERT_WINDOW
และเปิดบริการที่ทำงานอยู่เบื้องหน้าจากเบื้องหลัง แอปอาจได้รับผลกระทบจากการเปลี่ยนแปลงนี้ หากแอปได้รับ ForegroundServiceStartNotAllowedException
ให้ตรวจสอบลําดับการทํางานของแอปและตรวจสอบว่าแอปมีหน้าต่างวางซ้อนที่ใช้งานอยู่ก่อนที่จะพยายามเริ่มบริการที่ทำงานอยู่เบื้องหน้าจากเบื้องหลัง คุณสามารถตรวจสอบว่าขณะนี้หน้าต่างวางซ้อนแสดงอยู่หรือไม่โดยเรียกใช้ View.getWindowVisibility()
หรือจะลบล้าง View.onWindowVisibilityChanged()
เพื่อรับการแจ้งเตือนทุกครั้งที่ระดับการแชร์มีการเปลี่ยนแปลงก็ได้
การทดสอบ
หากต้องการทดสอบลักษณะการทํางานของแอป คุณสามารถเปิดใช้ข้อจํากัดใหม่เหล่านี้ได้แม้ว่าแอปของคุณจะไม่กําหนดเป้าหมายเป็น Android 15 ก็ตาม (ตราบใดที่แอปทํางานบนอุปกรณ์ Android 15) หากต้องการเปิดใช้ข้อจำกัดใหม่เหล่านี้เกี่ยวกับการเริ่มบริการที่ทำงานอยู่เบื้องหน้าจากเบื้องหลัง ให้เรียกใช้คำสั่ง adb
ต่อไปนี้
adb shell am compat enable FGS_SAW_RESTRICTIONS your-package-name
การเปลี่ยนแปลงเวลาที่แอปจะแก้ไขสถานะส่วนกลางของโหมดห้ามรบกวนได้
แอปที่กำหนดเป้าหมายเป็น Android 15 (API ระดับ 35) ขึ้นไปจะไม่สามารถเปลี่ยนแปลงสถานะหรือนโยบายแบบรวมของโหมดห้ามรบกวน (DND) ในอุปกรณ์ได้อีกต่อไป (ไม่ว่าจะแก้ไขการตั้งค่าของผู้ใช้หรือปิดโหมด DND) แต่แอปต้องส่งAutomaticZenRule
ซึ่งระบบจะรวมเข้ากับนโยบายส่วนกลางโดยใช้รูปแบบ "นโยบายที่เข้มงวดที่สุดจะชนะ" ที่มีอยู่ การเรียก API ที่มีอยู่ซึ่งก่อนหน้านี้ส่งผลต่อสถานะส่วนกลาง (setInterruptionFilter
,
setNotificationPolicy
) จะส่งผลให้มีการสร้างหรืออัปเดต AutomaticZenRule
ที่ไม่ชัดแจ้ง ซึ่งจะเปิดและปิดอยู่โดยขึ้นอยู่กับรอบการเรียกของ API เหล่านั้น
โปรดทราบว่าการเปลี่ยนแปลงนี้มีผลต่อลักษณะการทำงานที่สังเกตได้เฉพาะในกรณีที่แอปเรียกใช้ setInterruptionFilter(INTERRUPTION_FILTER_ALL)
และคาดว่าการเรียกใช้ดังกล่าวจะปิดใช้งาน AutomaticZenRule
ที่เจ้าของเปิดใช้งานไว้ก่อนหน้านี้
การเปลี่ยนแปลง API ของ OpenJDK
Android 15 continues the work of refreshing Android's core libraries to align with the features in the latest OpenJDK LTS releases.
Some of these changes can affect app compatibility for apps targeting Android 15 (API level 35):
Changes to string formatting APIs: Validation of argument index, flags, width, and precision are now more strict when using the following
String.format()
andFormatter.format()
APIs:String.format(String, Object[])
String.format(Locale, String, Object[])
Formatter.format(String, Object[])
Formatter.format(Locale, String, Object[])
For example, the following exception is thrown when an argument index of 0 is used (
%0
in the format string):IllegalFormatArgumentIndexException: Illegal format argument index = 0
In this case, the issue can be fixed by using an argument index of 1 (
%1
in the format string).Changes to component type of
Arrays.asList(...).toArray()
: When usingArrays.asList(...).toArray()
, the component type of the resulting array is now anObject
—not the type of the underlying array's elements. So the following code throws aClassCastException
:String[] elements = (String[]) Arrays.asList("one", "two").toArray();
For this case, to preserve
String
as the component type in the resulting array, you could useCollection.toArray(Object[])
instead:String[] elements = Arrays.asList("two", "one").toArray(new String[0]);
Changes to language code handling: When using the
Locale
API, language codes for Hebrew, Yiddish, and Indonesian are no longer converted to their obsolete forms (Hebrew:iw
, Yiddish:ji
, and Indonesian:in
). When specifying the language code for one of these locales, use the codes from ISO 639-1 instead (Hebrew:he
, Yiddish:yi
, and Indonesian:id
).Changes to random int sequences: Following the changes made in https://bugs.openjdk.org/browse/JDK-8301574, the following
Random.ints()
methods now return a different sequence of numbers than theRandom.nextInt()
methods do:Generally, this change shouldn't result in app-breaking behavior, but your code shouldn't expect the sequence generated from
Random.ints()
methods to matchRandom.nextInt()
.
The new SequencedCollection
API can affect your app's compatibility
after you update compileSdk
in your app's build configuration to use
Android 15 (API level 35):
Collision with
MutableList.removeFirst()
andMutableList.removeLast()
extension functions inkotlin-stdlib
The
List
type in Java is mapped to theMutableList
type in Kotlin. Because theList.removeFirst()
andList.removeLast()
APIs have been introduced in Android 15 (API level 35), the Kotlin compiler resolves function calls, for examplelist.removeFirst()
, statically to the newList
APIs instead of to the extension functions inkotlin-stdlib
.If an app is re-compiled with
compileSdk
set to35
andminSdk
set to34
or lower, and then the app is run on Android 14 and lower, a runtime error is thrown:java.lang.NoSuchMethodError: No virtual method removeFirst()Ljava/lang/Object; in class Ljava/util/ArrayList;
The existing
NewApi
lint option in Android Gradle Plugin can catch these new API usages../gradlew lint
MainActivity.kt:41: Error: Call requires API level 35 (current min is 34): java.util.List#removeFirst [NewApi] list.removeFirst()To fix the runtime exception and lint errors, the
removeFirst()
andremoveLast()
function calls can be replaced withremoveAt(0)
andremoveAt(list.lastIndex)
respectively in Kotlin. If you're using Android Studio Ladybug | 2024.1.3 or higher, it also provides a quick fix option for these errors.Consider removing
@SuppressLint("NewApi")
andlintOptions { disable 'NewApi' }
if the lint option has been disabled.Collision with other methods in Java
New methods have been added into the existing types, for example,
List
andDeque
. These new methods might not be compatible with the methods with the same name and argument types in other interfaces and classes. In the case of a method signature collision with incompatibility, thejavac
compiler outputs a build-time error. For example:Example error 1:
javac MyList.java
MyList.java:135: error: removeLast() in MyList cannot implement removeLast() in List public void removeLast() { ^ return type void is not compatible with Object where E is a type-variable: E extends Object declared in interface ListExample error 2:
javac MyList.java
MyList.java:7: error: types Deque<Object> and List<Object> are incompatible; public class MyList implements List<Object>, Deque<Object> { both define reversed(), but with unrelated return types 1 errorExample error 3:
javac MyList.java
MyList.java:43: error: types List<E#1> and MyInterface<E#2> are incompatible; public static class MyList implements List<Object>, MyInterface<Object> { class MyList inherits unrelated defaults for getFirst() from types List and MyInterface where E#1,E#2 are type-variables: E#1 extends Object declared in interface List E#2 extends Object declared in interface MyInterface 1 errorTo fix these build errors, the class implementing these interfaces should override the method with a compatible return type. For example:
@Override public Object getFirst() { return List.super.getFirst(); }
ความปลอดภัย
Android 15 มีการเปลี่ยนแปลงที่ส่งเสริมความปลอดภัยของระบบเพื่อช่วยปกป้องแอป และผู้ใช้จากแอปที่เป็นอันตราย
เวอร์ชัน TLS ที่ถูกจำกัด
Android 15 restricts the usage of TLS versions 1.0 and 1.1. These versions had previously been deprecated in Android, but are now disallowed for apps targeting Android 15.
เปิดใช้กิจกรรมในเบื้องหลังที่ปลอดภัย
Android 15 protects users from malicious apps and gives them more control over their devices by adding changes that prevent malicious background apps from bringing other apps to the foreground, elevating their privileges, and abusing user interaction. Background activity launches have been restricted since Android 10 (API level 29).
Other changes
In addition to the restriction for UID matching, these other changes are also included:
- Change
PendingIntent
creators to block background activity launches by default. This helps prevent apps from accidentally creating aPendingIntent
that could be abused by malicious actors. - Don't bring an app to the foreground unless the
PendingIntent
sender allows it. This change aims to prevent malicious apps from abusing the ability to start activities in the background. By default, apps are not allowed to bring the task stack to the foreground unless the creator allows background activity launch privileges or the sender has background activity launch privileges. - Control how the top activity of a task stack can finish its task. If the top activity finishes a task, Android will go back to whichever task was last active. Moreover, if a non-top activity finishes its task, Android will go back to the home screen; it won't block the finish of this non-top activity.
- Prevent launching arbitrary activities from other apps into your own task. This change prevents malicious apps from phishing users by creating activities that appear to be from other apps.
- Block non-visible windows from being considered for background activity launches. This helps prevent malicious apps from abusing background activity launches to display unwanted or malicious content to users.
Intent ที่ปลอดภัยกว่า
Android 15 introduces new optional security measures to make intents safer and more robust. These changes are aimed at preventing potential vulnerabilities and misuse of intents that can be exploited by malicious apps. There are two main improvements to the security of intents in Android 15:
- Match target intent-filters: Intents that target specific components must accurately match the target's intent-filter specifications. If you send an intent to launch another app's activity, the target intent component needs to align with the receiving activity's declared intent-filters.
- Intents must have actions: Intents without an action will no longer match any intent-filters. This means that intents used to start activities or services must have a clearly defined action.
In order to check how your app responds to these changes, use
StrictMode
in your app. To see detailed
logs about Intent
usage violations, add the following method:
Kotlin
fun onCreate() { StrictMode.setVmPolicy(VmPolicy.Builder() .detectUnsafeIntentLaunch() .build() ) }
Java
public void onCreate() { StrictMode.setVmPolicy(new VmPolicy.Builder() .detectUnsafeIntentLaunch() .build()); }
ประสบการณ์ของผู้ใช้และ UI ของระบบ
Android 15 มีการเปลี่ยนแปลงบางอย่างที่มุ่งสร้างประสบการณ์ของผู้ใช้ที่สอดคล้องกันมากขึ้น และใช้งานง่าย
การเปลี่ยนแปลงส่วนที่เว้นไว้ในหน้าต่าง
การเปลี่ยนแปลงที่เกี่ยวข้องกับส่วนแทรกของหน้าต่างใน Android 15 มี 2 อย่าง ได้แก่ ระบบจะบังคับใช้การแสดงผลแบบเต็มหน้าจอโดยค่าเริ่มต้น และยังมีการเปลี่ยนแปลงการกำหนดค่า เช่น การกําหนดค่าเริ่มต้นของแถบระบบ
การบังคับใช้แบบไร้ขอบ
แอปจะแสดงผลแบบไร้ขอบโดยค่าเริ่มต้นในอุปกรณ์ที่ใช้ Android 15 หากแอปกำหนดเป้าหมายเป็น Android 15 (API ระดับ 35)
งานที่ต้องทำเพื่อให้เข้ากันได้กับการบังคับใช้แบบขอบจรดขอบของ Android 15
นี่เป็นการเปลี่ยนแปลงที่ไม่รองรับการทำงานร่วมกันซึ่งอาจส่งผลเสียต่อ UI ของแอป การเปลี่ยนแปลงนี้ส่งผลต่อพื้นที่ UI ต่อไปนี้
- แถบนำทางด้วยแฮนเดิลท่าทางสัมผัส
- โปร่งใสโดยค่าเริ่มต้น
- ปิดใช้การชดเชยด้านล่างเพื่อให้เนื้อหาแสดงอยู่ด้านหลังแถบนำทางของระบบ เว้นแต่จะใช้ Inset
setNavigationBarColor
และR.attr#navigationBarColor
เลิกใช้งานแล้วและไม่ส่งผลต่อการไปยังส่วนต่างๆ ด้วยท่าทางสัมผัสsetNavigationBarContrastEnforced
และR.attr#navigationBarContrastEnforced
จะยังคงไม่มีผลต่อ การนำทางด้วยท่าทางสัมผัส
- การนำทางแบบ 3 ปุ่ม
- ความทึบแสงตั้งค่าเป็น 80% โดยค่าเริ่มต้น และสีอาจตรงกับพื้นหลังของหน้าต่าง
- ปิดใช้การชดเชยด้านล่างเพื่อให้เนื้อหาแสดงอยู่ด้านหลังแถบนำทางของระบบ เว้นแต่จะใช้ Inset
setNavigationBarColor
และR.attr#navigationBarColor
จะ ตั้งค่าให้ตรงกับพื้นหลังของหน้าต่างโดยค่าเริ่มต้น พื้นหลังของหน้าต่าง ต้องเป็น Drawable สีเพื่อให้ค่าเริ่มต้นนี้มีผล API นี้ เลิกใช้งานแล้ว แต่ยังคงส่งผลต่อการนำทางด้วย 3 ปุ่มsetNavigationBarContrastEnforced
และR.attr#navigationBarContrastEnforced
เป็นจริงโดยค่าเริ่มต้น ซึ่งจะเพิ่มพื้นหลังทึบแสง 80% ในการนำทางแบบ 3 ปุ่ม
- แถบสถานะ
- โปร่งใสโดยค่าเริ่มต้น
- ระบบจะปิดใช้การชดเชยด้านบนเพื่อให้เนื้อหาแสดงอยู่ด้านหลังแถบสถานะ เว้นแต่จะมีการใช้ ระยะขอบ
setStatusBarColor
และR.attr#statusBarColor
เลิกใช้งานแล้วและจะไม่มีผลกับ Android 15setStatusBarContrastEnforced
และR.attr#statusBarContrastEnforced
ถูกเลิกใช้งานแล้ว แต่ยังคงส่งผลต่อ Android 15
- รอยบากบนจอแสดงผล
layoutInDisplayCutoutMode
ของหน้าต่างที่ไม่ลอยต้องเป็นLAYOUT_IN_DISPLAY_CUTOUT_MODE_ALWAYS
ระบบจะตีความSHORT_EDGES
,NEVER
และDEFAULT
เป็นALWAYS
เพื่อให้ผู้ใช้ไม่เห็นแถบสีดำ ที่เกิดจากการเว้นขอบจอแสดงผล และปรากฏแบบขอบจรดขอบ
ตัวอย่างต่อไปนี้แสดงแอปก่อนและหลังกำหนดเป้าหมายเป็น Android 15 (API ระดับ 35) รวมถึงก่อนและหลังใช้ส่วนที่เว้นไว้ ตัวอย่างนี้ไม่ครอบคลุมทั้งหมด และอาจปรากฏแตกต่างกันใน Android Auto



สิ่งที่ต้องตรวจสอบหากแอปเป็นแบบขอบจรดขอบอยู่แล้ว
หากแอปเป็นแบบขอบจรดขอบอยู่แล้วและใช้ Inset คุณจะได้รับผลกระทบน้อยมาก ยกเว้นในสถานการณ์ต่อไปนี้ อย่างไรก็ตาม แม้ว่าคุณจะคิดว่าไม่ได้รับผลกระทบ เราขอแนะนำให้ทดสอบแอป
- คุณมีหน้าต่างที่ไม่ลอย เช่น
Activity
ที่ใช้SHORT_EDGES
,NEVER
หรือDEFAULT
แทนLAYOUT_IN_DISPLAY_CUTOUT_MODE_ALWAYS
หากแอปขัดข้องเมื่อเปิดใช้งาน ปัญหานี้ อาจเกิดจากหน้าจอเริ่มต้น คุณจะอัปเกรดการขึ้นต่อกันของ core splashscreen เป็น 1.2.0-alpha01 หรือใหม่กว่า หรือตั้งค่าwindow.attributes.layoutInDisplayCutoutMode = WindowManager.LayoutInDisplayCutoutMode.always
ก็ได้ - อาจมีหน้าจอที่มีการเข้าชมต่ำซึ่งมี UI ที่ถูกบดบัง ตรวจสอบว่าหน้าจอที่มีการเข้าชมน้อยกว่า
ไม่มี UI ที่ถูกบดบัง หน้าจอที่มีการเข้าชมต่ำ ได้แก่
- หน้าจอเริ่มต้นใช้งานหรือลงชื่อเข้าใช้
- หน้าการตั้งค่า
สิ่งที่ต้องตรวจสอบหากแอปยังไม่แสดงแบบขอบจรดขอบ
หากแอปของคุณยังไม่ได้แสดงผลแบบขอบถึงขอบ คุณอาจได้รับผลกระทบ นอกเหนือจากสถานการณ์สำหรับแอปที่แสดงแบบเต็มหน้าจออยู่แล้ว คุณควรพิจารณาสิ่งต่อไปนี้
- หากแอปใช้คอมโพเนนต์ Material 3 (
androidx.compose.material3
) ใน Compose เช่นTopAppBar
,BottomAppBar
และNavigationBar
คอมโพเนนต์เหล่านี้ไม่ น่าจะได้รับผลกระทบเนื่องจากจะจัดการระยะขอบโดยอัตโนมัติ - หากแอปใช้คอมโพเนนต์ Material 2 (
androidx.compose.material
) ใน Compose คอมโพเนนต์เหล่านี้ จะไม่จัดการ Inset โดยอัตโนมัติ อย่างไรก็ตาม คุณสามารถเข้าถึงระยะขอบ และใช้ระยะขอบด้วยตนเองได้ ใน androidx.compose.material 1.6.0 ขึ้นไป ให้ใช้พารามิเตอร์windowInsets
เพื่อใช้ระยะขอบด้วยตนเองสำหรับBottomAppBar
,TopAppBar
,BottomNavigation
และNavigationRail
ในทำนองเดียวกัน ให้ใช้พารามิเตอร์contentWindowInsets
สำหรับScaffold
- หากแอปใช้ View และคอมโพเนนต์ Material
(
com.google.android.material
) คอมโพเนนต์ Material ส่วนใหญ่ที่อิงตาม View เช่นBottomNavigationView
,BottomAppBar
,NavigationRailView
หรือNavigationView
จะจัดการ Inset และไม่จำเป็นต้องดำเนินการเพิ่มเติม แต่คุณต้องเพิ่มandroid:fitsSystemWindows="true"
หากใช้AppBarLayout
- สำหรับ Composable ที่กำหนดเอง ให้ใช้ Insets เป็น Padding ด้วยตนเอง หากเนื้อหาอยู่ภายใน
Scaffold
คุณจะใช้ขอบแทรกได้โดยใช้Scaffold
ค่าระยะห่างจากขอบ หรือใช้ระยะห่างโดยใช้หนึ่งในWindowInsets
- หากแอปใช้มุมมองและ
BottomSheet
,SideSheet
หรือคอนเทนเนอร์ที่กำหนดเอง ให้ใช้ระยะขอบโดยใช้ViewCompat.setOnApplyWindowInsetsListener
สำหรับRecyclerView
ให้ใช้ระยะห่างจากขอบโดยใช้ Listener นี้ และเพิ่มclipToPadding="false"
ด้วย
สิ่งที่ต้องตรวจสอบหากแอปต้องมีการป้องกันพื้นหลังที่กำหนดเอง
หากแอปต้องมีการป้องกันพื้นหลังที่กำหนดเองสำหรับการนำทางด้วย 3 ปุ่มหรือแถบสถานะ แอปควรวาง Composable หรือ View ไว้ด้านหลังแถบระบบโดยใช้ WindowInsets.Type#tappableElement()
เพื่อรับความสูงของแถบนำทางด้วย 3 ปุ่มหรือ WindowInsets.Type#statusBars
แหล่งข้อมูลเพิ่มเติมแบบขอบถึงขอบ
ดูข้อควรพิจารณาเพิ่มเติมเกี่ยวกับการใช้ระยะขอบได้ในคำแนะนำมุมมองแบบขอบถึงขอบและการเขียนแบบขอบถึงขอบ
API ที่เลิกใช้งานแล้ว
API ต่อไปนี้เลิกใช้งานแล้วแต่ยังไม่ได้ปิดใช้
R.attr#enforceStatusBarContrast
R.attr#navigationBarColor
(สำหรับการนำทางแบบ 3 ปุ่มที่มีอัลฟ่า 80% )Window#isStatusBarContrastEnforced
Window#setNavigationBarColor
(สำหรับการนำทางแบบ 3 ปุ่มที่มี อัลฟ่า 80%)Window#setStatusBarContrastEnforced
API ต่อไปนี้เลิกใช้งานแล้วและถูกปิดใช้
R.attr#navigationBarColor
(สำหรับการนำทางด้วยท่าทางสัมผัส)R.attr#navigationBarDividerColor
R.attr#statusBarColor
Window#setDecorFitsSystemWindows
Window#getNavigationBarColor
Window#getNavigationBarDividerColor
Window#getStatusBarColor
Window#setNavigationBarColor
(สำหรับการนำทางด้วยท่าทางสัมผัส)Window#setNavigationBarDividerColor
Window#setStatusBarColor
การกำหนดค่าที่เสถียร
หากแอปกำหนดเป้าหมายเป็น Android 15 (API ระดับ 35) ขึ้นไป Configuration
จะไม่
รวมแถบระบบอีกต่อไป หากคุณใช้ขนาดหน้าจอในคลาส Configuration
เพื่อคำนวณเลย์เอาต์ คุณควรแทนที่ด้วยตัวเลือกอื่นที่ดีกว่า เช่น ViewGroup
, WindowInsets
หรือ WindowMetricsCalculator
ที่เหมาะสม ทั้งนี้ขึ้นอยู่กับความต้องการของคุณ
Configuration
พร้อมใช้งานตั้งแต่ API 1 โดยปกติแล้วจะได้รับจาก
Activity.onConfigurationChanged
โดยจะให้ข้อมูล เช่น ความหนาแน่นของหน้าต่าง
การวางแนว และขนาด ลักษณะสำคัญอย่างหนึ่งเกี่ยวกับขนาดหน้าต่างที่ส่งคืนจาก Configuration
คือก่อนหน้านี้จะไม่รวมแถบระบบ
โดยปกติแล้ว ขนาดการกำหนดค่าจะใช้สำหรับการเลือกทรัพยากร เช่น
/res/layout-h500dp
และนี่ก็ยังคงเป็น Use Case ที่ถูกต้อง อย่างไรก็ตาม เราไม่แนะนำให้ใช้สำหรับ
การคำนวณเลย์เอาต์มาโดยตลอด หากคุณกำลังทำเช่นนั้น คุณควรหยุด
ทำทันที คุณควรแทนที่การใช้ Configuration
ด้วยสิ่งอื่นที่เหมาะสมกว่าตามกรณีการใช้งาน
หากใช้เพื่อคำนวณเลย์เอาต์ ให้ใช้ ViewGroup
ที่เหมาะสม เช่น
CoordinatorLayout
หรือ ConstraintLayout
หากคุณใช้เพื่อกำหนดความสูง
ของแถบนำทางของระบบ ให้ใช้ WindowInsets
หากต้องการทราบขนาดปัจจุบัน
ของหน้าต่างแอป ให้ใช้ computeCurrentWindowMetrics
รายการต่อไปนี้อธิบายฟิลด์ที่ได้รับผลกระทบจากการเปลี่ยนแปลงนี้
- ขนาด
Configuration.screenWidthDp
และscreenHeightDp
จะไม่ รวมแถบระบบอีกต่อไป Configuration.smallestScreenWidthDp
ได้รับผลกระทบโดยอ้อมจากการเปลี่ยนแปลง ในscreenWidthDp
และscreenHeightDp
Configuration.orientation
ได้รับผลกระทบโดยอ้อมจากการเปลี่ยนแปลงในscreenWidthDp
และscreenHeightDp
ในอุปกรณ์ที่มีสัดส่วนใกล้เคียงกับสี่เหลี่ยมจัตุรัสDisplay.getSize(Point)
ได้รับผลกระทบโดยอ้อมจากการเปลี่ยนแปลงในConfiguration
ซึ่งเลิกใช้งานแล้วตั้งแต่ API ระดับ 30 เป็นต้นไปDisplay.getMetrics()
ทำงานในลักษณะนี้มาตั้งแต่ API ระดับ 33 แล้ว
แอตทริบิวต์ elegantTextHeight จะมีค่าเริ่มต้นเป็น true
For apps targeting Android 15 (API level 35), the
elegantTextHeight
TextView
attribute
becomes true
by default, replacing the compact font used by default with some
scripts that have large vertical metrics with one that is much more readable.
The compact font was introduced to prevent breaking layouts; Android 13 (API
level 33) prevents many of these breakages by allowing the text layout to
stretch the vertical height utilizing the fallbackLineSpacing
attribute.
In Android 15, the compact font still remains in the system, so your app can set
elegantTextHeight
to false
to get the same behavior as before, but it is
unlikely to be supported in upcoming releases. So, if your app supports the
following scripts: Arabic, Lao, Myanmar, Tamil, Gujarati, Kannada, Malayalam,
Odia, Telugu or Thai, test your app by setting elegantTextHeight
to true
.

elegantTextHeight
behavior for apps targeting Android 14 (API level 34) and lower.
elegantTextHeight
behavior for apps targeting Android 15.การเปลี่ยนแปลงความกว้างของ TextView สำหรับรูปร่างตัวอักษรที่ซับซ้อน
In previous versions of Android, some cursive fonts or languages that have
complex shaping might draw the letters in the previous or next character's area.
In some cases, such letters were clipped at the beginning or ending position.
Starting in Android 15, a TextView
allocates width for drawing enough space
for such letters and allows apps to request extra paddings to the left to
prevent clipping.
Because this change affects how a TextView
decides the width, TextView
allocates more width by default if the app targets Android 15 (API level 35) or
higher. You can enable or disable this behavior by calling the
setUseBoundsForWidth
API on TextView
.
Because adding left padding might cause a misalignment for existing layouts, the
padding is not added by default even for apps that target Android 15 or higher.
However, you can add extra padding to preventing clipping by calling
setShiftDrawingOffsetForStartOverhang
.
The following examples show how these changes can improve text layout for some fonts and languages.

<TextView android:fontFamily="cursive" android:text="java" />

<TextView android:fontFamily="cursive" android:text="java" android:useBoundsForWidth="true" android:shiftDrawingOffsetForStartOverhang="true" />

<TextView android:text="คอมพิวเตอร์" />

<TextView android:text="คอมพิวเตอร์" android:useBoundsForWidth="true" android:shiftDrawingOffsetForStartOverhang="true" />
ความสูงของบรรทัดเริ่มต้นที่รับรู้ภาษาสำหรับ EditText
ใน Android เวอร์ชันก่อนหน้า เลย์เอาต์ข้อความจะยืดความสูงของข้อความให้เท่ากับความสูงของบรรทัดแบบอักษรที่ตรงกับภาษาปัจจุบัน เช่น หากเนื้อหาเป็นภาษาญี่ปุ่น ความสูงของบรรทัดของแบบอักษรญี่ปุ่นจะสูงกว่าแบบอักษรละตินเล็กน้อย ความสูงของข้อความจึงเพิ่มขึ้นเล็กน้อย อย่างไรก็ตาม แม้ความสูงของบรรทัดจะแตกต่างกัน แต่องค์ประกอบ EditText
ก็มีการปรับขนาดให้เหมือนกัน โดยไม่คำนึงถึงภาษาที่ใช้ ดังที่แสดงในภาพต่อไปนี้

EditText
ซึ่งอาจมีข้อความจากภาษาอังกฤษ (en), ญี่ปุ่น (ja) และพม่า (my) ความสูงของ EditText
เหมือนกัน แม้ว่าภาษาเหล่านี้จะมีความสูงของบรรทัดต่างกันสำหรับแอปที่กำหนดเป้าหมายเป็น Android 15 (API ระดับ 35) ระบบจะสงวนความสูงบรรทัดขั้นต่ำไว้สำหรับ EditText
เพื่อให้ตรงกับแบบอักษรอ้างอิงสำหรับภาษาที่ระบุ ดังที่แสดงในภาพต่อไปนี้

EditText
ซึ่งอาจมีข้อความจากภาษาอังกฤษ (en), ญี่ปุ่น (ja) และพม่า (my) ตอนนี้ความสูงของ EditText
จะรวมช่องว่างไว้เพื่อรองรับความสูงของบรรทัดเริ่มต้นสำหรับแบบอักษรของภาษาเหล่านี้หากจําเป็น แอปจะกู้คืนลักษณะการทํางานก่อนหน้าได้โดยระบุแอตทริบิวต์ useLocalePreferredLineHeightForMinimum
เป็น false
และแอปจะตั้งค่าเมตริกแนวตั้งขั้นต่ำที่กําหนดเองได้โดยใช้ setMinimumFontMetrics
API ใน Kotlin และ Java
กล้องและสื่อ
Android 15 จะทำการเปลี่ยนแปลงลักษณะการทำงานของกล้องและสื่อสำหรับแอปที่กำหนดเป้าหมายเป็น Android 15 ขึ้นไปดังนี้
ข้อจำกัดในการขอโฟกัสเสียง
แอปที่กำหนดเป้าหมายเป็น Android 15 (API ระดับ 35) ต้องเป็นแอปที่ทำงานอยู่ด้านบนหรือกำลังใช้บริการที่ทำงานอยู่เบื้องหน้าเพื่อขอโฟกัสเสียง หากแอปพยายามขอโฟกัสเมื่อไม่เป็นไปตามข้อกำหนดข้อใดข้อหนึ่งเหล่านี้ การเรียกใช้จะแสดงผลเป็น AUDIOFOCUS_REQUEST_FAILED
ดูข้อมูลเพิ่มเติมเกี่ยวกับโหมดโฟกัสเสียงได้ที่จัดการโหมดโฟกัสเสียง
ข้อจำกัดที่ไม่ใช่ SDK ที่อัปเดตแล้ว
Android 15 มีรายการอินเทอร์เฟซที่ไม่ใช่ SDK ที่ถูกจำกัดซึ่งอัปเดตแล้วโดยอิงตามการทำงานร่วมกับนักพัฒนาแอป Android และการทดสอบภายในล่าสุด เราจะตรวจสอบว่ามีทางเลือกสาธารณะ พร้อมใช้งานก่อนที่จะจำกัดอินเทอร์เฟซที่ไม่ใช่ SDK ทุกครั้งที่ทำได้
หากแอปไม่ได้กำหนดเป้าหมายเป็น Android 15 การเปลี่ยนแปลงบางอย่างเหล่านี้ อาจไม่มีผลกับคุณในทันที อย่างไรก็ตาม แม้ว่าแอปของคุณจะ เข้าถึงอินเทอร์เฟซที่ไม่ใช่ SDK บางรายการได้ ขึ้นอยู่กับระดับ API เป้าหมายของแอป แต่การใช้วิธีการหรือฟิลด์ที่ไม่ใช่ SDK ใดๆ ก็ตามมีความเสี่ยงสูงที่จะทำให้แอปของคุณใช้งานไม่ได้
หากไม่แน่ใจว่าแอปใช้อินเทอร์เฟซที่ไม่ใช่ SDK หรือไม่ คุณสามารถทดสอบแอปเพื่อดูได้ หากแอปของคุณใช้ อินเทอร์เฟซที่ไม่ใช่ SDK คุณควรเริ่มวางแผนการย้ายข้อมูลไปยังทางเลือกอื่นของ SDK อย่างไรก็ตาม เราเข้าใจว่าแอปบางแอปมี Use Case ที่ถูกต้องสำหรับการใช้อินเทอร์เฟซที่ไม่ใช่ SDK หากไม่พบวิธีอื่นในการใช้อินเทอร์เฟซที่ไม่ใช่ SDK สำหรับฟีเจอร์ในแอป คุณควรขอ API สาธารณะใหม่
To learn more about the changes in this release of Android, see Updates to non-SDK interface restrictions in Android 15. To learn more about non-SDK interfaces generally, see Restrictions on non-SDK interfaces.