이전 버전과 마찬가지로 Android 15에는 앱에 영향을 줄 수 있는 동작 변경사항이 포함되어 있습니다. 다음 동작 변경사항은 Android 15 이상을 타겟팅하는 앱에만 적용됩니다. 앱이 Android 15 이상을 타겟팅한다면 이러한 동작을 올바르게 지원하도록 앱을 수정해야 합니다(해당하는 경우).
앱의 targetSdkVersion
와 관계없이 Android 15에서 실행되는 모든 앱에 영향을 미치는 동작 변경사항 목록도 검토해야 합니다.
핵심 기능
Android 15는 Android 시스템의 다양한 핵심 기능을 수정하거나 확장합니다.
포그라운드 서비스 변경사항
我们将对 Android 15 中的前台服务做出以下更改。
数据同步前台服务超时行为
Android 15 introduces a new timeout behavior to dataSync
for apps targeting
Android 15 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()
, a failure will occur with this error message: "A
foreground service of
<fgs_type> did not stop within its timeout:
<component_name>". In Beta 2, the failure message is shown as an
ANR, but in a future Beta release, this failure message will throw a custom
exception.
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".
新增媒体处理前台服务类型
Android 15에서는 새로운 포그라운드 서비스 유형인 mediaProcessing
를 도입합니다. 이 서비스 유형은 미디어 파일 트랜스코딩과 같은 작업에 적합합니다. 예를 들어 미디어 앱은 오디오 파일을 다운로드하여 재생하기 전에 다른 형식으로 변환해야 할 수 있습니다. mediaProcessing
포그라운드 서비스를 사용하면 앱이 백그라운드에 있는 동안에도 전환이 계속되도록 할 수 있습니다.
시스템은 앱의 mediaProcessing
서비스가 24시간 동안 총 6시간 동안 실행되도록 허용합니다. 그 후 시스템은 실행 중인 서비스의 Service.onTimeout(int, int)
메서드 (Android 15에서 도입됨)를 호출합니다. 현재 서비스는 Service.stopSelf()
를 호출할 수 있는 몇 초 정도 걸립니다. 서비스가 Service.stopSelf()
를 호출하지 않으면 '<fgs_type>의 포그라운드 서비스가 제한 시간 내에 중지되지 않았습니다. <component_name>' 오류 메시지와 함께 오류가 발생합니다. 베타 2에서는 실패 메시지가 ANR로 표시되지만 향후 베타 출시에서는 이 실패 메시지에 커스텀 예외가 발생합니다.
ANR이 발생하지 않도록 하려면 다음 중 하나를 수행하세요.
- 서비스에서 새
Service.onTimeout(int, int)
메서드를 구현하도록 합니다. 앱이 콜백을 수신하면 몇 초 이내에stopSelf()
를 호출해야 합니다. 앱을 즉시 중지하지 않으면 시스템에서 실패가 발생합니다. - 앱의
mediaProcessing
서비스가 24시간 동안 총 6시간을 초과하여 실행되지 않아야 합니다 (사용자가 앱과 상호작용하여 타이머를 재설정하지 않는 경우). - 직접적인 사용자 상호작용의 결과로만
mediaProcessing
포그라운드 서비스만 시작합니다. 서비스가 시작될 때 앱이 포그라운드에 있으므로 앱이 백그라운드로 전환되고 6시간 후에 서비스가 제공됩니다. mediaProcessing
포그라운드 서비스를 사용하는 대신 WorkManager와 같은 대체 API를 사용하세요.
앱의 mediaProcessing
포그라운드 서비스가 지난 24일 동안 6시간 동안 실행된 경우, 사용자가 앱을 포그라운드로 가져와 타이머를 재설정하지 않는 한 다른 mediaProcessing
포그라운드 서비스를 시작할 수 없습니다. 다른 mediaProcessing
포그라운드 서비스를 시작하려고 하면 시스템에서 ForegroundServiceStartNotAllowedException
이 발생하며 '포그라운드 서비스 유형 mediaProcessing의 시간 제한이 이미 소진되었습니다'와 같은 오류 메시지가 표시됩니다.
mediaProcessing
서비스 유형에 관한 자세한 내용은 Android 15의 포그라운드 서비스 유형 변경사항: 미디어 처리를 참고하세요.
对启动前台服务的 BOOT_COMPLETED
广播接收器的限制
针对启动前台服务的 BOOT_COMPLETED
广播接收器存在新的限制。BOOT_COMPLETED
接收器不能启动以下类型的前台服务:
dataSync
camera
mediaPlayback
phoneCall
mediaProjection
microphone
(从 Android 14 开始,系统针对microphone
实施了此限制)
如果 BOOT_COMPLETED
接收器尝试启动任何此类前台服务,系统会抛出 ForegroundServiceStartNotAllowedException
。
限制在应用拥有 SYSTEM_ALERT_WINDOW
权限的情况下启动前台服务
Previously, if an app held the SYSTEM_ALERT_WINDOW
permission, it could launch
a foreground service even if the app was currently in the background (as
discussed in exemptions from background start restrictions).
If an app targets Android 15, this exemption is now narrower. The app now needs
to have the SYSTEM_ALERT_WINDOW
permission and also have a visible overlay
window. That is, the app needs to first launch a
TYPE_APPLICATION_OVERLAY
window and the window
needs to be visible before you start a foreground service.
If your app attempts to start a foreground service from the background without
meeting these new requirements (and it does not have some other exemption), the
system throws ForegroundServiceStartNotAllowedException
.
If your app declares the SYSTEM_ALERT_WINDOW
permission
and launches foreground services from the background, it may be affected by this
change. If your app gets a ForegroundServiceStartNotAllowedException
, check
your app's order of operations and make sure your app already has an active
overlay window before it attempts to start a foreground service from the
background. You can check if your overlay window is currently visible
by calling View.getWindowVisibility()
, or you
can override View.onWindowVisibilityChanged()
to get notified whenever the visibility changes.
앱이 방해 금지 모드의 전체 상태를 수정할 수 있는 경우에 대한 변경사항
以 Android 15 为目标平台的应用无法再更改设备上的全局状态或勿扰 (DND) 政策(通过修改用户设置或关闭 DND 模式)。相反,应用必须提供一个 AutomaticZenRule
,系统会将后者合并到一个具有现有最严格的政策胜出方案的全局政策中。调用之前影响全局状态的现有 API(setInterruptionFilter
、setNotificationPolicy
)会导致创建或更新隐式 AutomaticZenRule
,该 AutomaticZenRule
根据这些 API 调用的调用周期而开启或关闭。
请注意,只有在应用调用 setInterruptionFilter(INTERRUPTION_FILTER_ALL)
且预期调用会停用之前由其所有者激活的 AutomaticZenRule
时,此变更才会影响可观察的行为。
OpenJDK 17 변경사항
Android 15 continues the work of refreshing Android's core libraries to align with the features in the latest OpenJDK LTS releases.
One of these changes can affect app compatibility for apps targeting Android 15:
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()
.
보안
Android 15에는 앱과 사용자를 악성 앱으로부터 보호하기 위해 시스템 보안을 촉진하는 변경사항이 포함되어 있습니다.
보안 백그라운드 활동 시작
Android 15는 악성 백그라운드 앱이 다른 앱을 포그라운드로 가져오고 권한을 승격하며 사용자 상호작용을 악용하지 못하도록 하는 변경사항을 추가하여 악성 앱으로부터 사용자를 보호하고 사용자가 기기를 더 잘 제어할 수 있도록 합니다. 백그라운드 활동 실행은 Android 10 (API 수준 29)부터 제한되었습니다.
스택의 상단 UID와 일치하지 않는 앱이 활동을 실행하지 못하도록 차단
악성 앱은 동일한 작업 내에서 다른 앱의 활동을 실행한 다음 그 위에 오버레이되어 앱이 있는 것처럼 보이게 할 수 있습니다. 이 '작업 도용' 공격은 모두 동일한 작업 내에서 발생하므로 현재의 백그라운드 실행 제한을 우회합니다. 이러한 위험을 완화하기 위해 Android 15에서는 스택의 상단 UID와 일치하지 않는 앱이 활동을 실행하지 못하도록 차단하는 플래그를 추가합니다. 앱의 모든 활동을 선택하려면 다음과 같이 앱의 AndroidManifest.xml
파일에서 allowCrossUidActivitySwitchFromBelow
속성을 업데이트합니다.
<application android:allowCrossUidActivitySwitchFromBelow="false" >
새로운 보안 조치는 다음 조건을 모두 충족하는 경우 적용됩니다.
- 출시를 실행하는 앱이 Android 15를 타겟팅합니다.
- 작업 스택 위에 있는 앱은 Android 15를 타겟팅합니다.
- 눈에 보이는 모든 활동이 새로운 보호 조치를 선택했습니다.
보안 조치가 사용 설정된 경우, 앱이 자체 작업을 완료하면 마지막으로 표시된 앱이 아닌 홈으로 돌아갈 수 있습니다.
기타 변경사항
UID 매칭 제한 외에도 다음과 같은 다른 변경사항도 포함되어 있습니다.
- 기본적으로 백그라운드 활동 실행을 차단하도록
PendingIntent
생성자를 변경합니다. 이렇게 하면 앱에서 악의적인 행위자가 악용할 수 있는PendingIntent
를 실수로 만드는 것을 방지할 수 있습니다. PendingIntent
발신자가 허용하지 않는 한 앱을 포그라운드로 가져오지 않습니다. 이 변경사항은 악성 앱이 백그라운드에서 활동을 시작하는 기능을 악용하지 않도록 하기 위한 것입니다. 기본적으로 앱은 개발자가 백그라운드 활동 실행 권한을 허용하거나 발신자가 백그라운드 활동 실행 권한을 가지고 있지 않는 한 앱에서 작업 스택을 포그라운드로 가져올 수 없습니다.- 작업 스택의 상단 활동이 작업을 완료하는 방법을 제어합니다. 최상위 활동이 작업을 완료하면 Android는 마지막으로 활성 상태였던 작업으로 돌아갑니다. 또한 최상위가 아닌 활동이 작업을 완료하면 Android는 홈 화면으로 돌아갑니다. 또한 최상위가 아닌 활동의 종료를 차단하지 않습니다.
- 다른 앱의 임의 활동을 자체 작업으로 실행하는 것을 방지합니다. 이 변경사항으로 인해 다른 앱에서 전송된 것처럼 보이는 활동을 생성하여 악성 앱이 피싱 사용자로부터 피해를 입지 않도록 방지할 수 있습니다.
- 보이지 않는 창이 백그라운드 활동 실행에 고려되지 않도록 차단합니다. 이렇게 하면 악성 앱이 백그라운드 활동 실행을 악용하여 원치 않는 콘텐츠나 악성 콘텐츠를 사용자에게 표시하는 것을 방지할 수 있습니다.
더 안전한 인텐트
Android 15 introduces new 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.
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의 창 인셋과 관련된 두 가지 변경사항이 있습니다. 에지 투 에지가 기본적으로 적용되고 시스템 표시줄의 기본 구성과 같은 구성 변경사항도 있습니다.
全面强制执行
Apps are edge-to-edge by default on devices running Android 15 if the app is targeting Android 15.
This is a breaking change that might negatively impact your app's UI. The changes affect the following UI areas:
- Gesture handle navigation bar
- Transparent by default.
- Bottom offset is disabled so content draws behind the system navigation bar unless insets are applied.
setNavigationBarColor
andR.attr#navigationBarColor
are deprecated and don't affect gesture navigation.setNavigationBarContrastEnforced
andR.attr#navigationBarContrastEnforced
continue to have no effect on gesture navigation.
- 3-button navigation
- Opacity set to 80% by default, with color possibly matching the window background.
- Bottom offset disabled so content draws behind the system navigation bar unless insets are applied.
setNavigationBarColor
andR.attr#navigationBarColor
are set to match the window background by default. The window background must be a color drawable for this default to apply. This API is deprecated but continues to affect 3-button navigation.setNavigationBarContrastEnforced
andR.attr#navigationBarContrastEnforced
is true by default, which adds an 80% opaque background across 3-button navigation.
- Status bar
- Transparent by default.
- The top offset is disabled so content draws behind the status bar unless insets are applied.
setStatusBarColor
andR.attr#statusBarColor
are deprecated and have no effect on Android 15.setStatusBarContrastEnforced
andR.attr#statusBarContrastEnforced
are deprecated but still have an effect on Android 15.
- Display cutout
layoutInDisplayCutoutMode
of non-floating windows must beLAYOUT_IN_DISPLAY_CUTOUT_MODE_ALWAYS
.SHORT_EDGES
,NEVER
andDEFAULT
are interpreted asALWAYS
so that users don't see a Black bar caused by the display cutout and appear edge-to-edge.
The following example shows an app before and after targeting Android 15, and before and after applying insets.
What to check if your app is already edge-to-edge
If your app is already edge-to-edge and applies insets, you are mostly unimpacted, except in the following scenarios. However, even if you think you aren't impacted, we recommend you test your app.
- You have a non-floating window, such as an
Activity
that usesSHORT_EDGES
,NEVER
orDEFAULT
instead ofLAYOUT_IN_DISPLAY_CUTOUT_MODE_ALWAYS
. If your app crashes on launch, this might be due to your splashscreen. You can either upgrade the core splashscreen dependency to 1.2.0-alpha01 or later or setwindow.attributes.layoutInDisplayCutoutMode = WindowManager.LayoutInDisplayCutoutMode.always
. - There might be lower-traffic screens with occluded UI. Verify these
less-visited screens don't have occluded UI. Lower-traffic screens include:
- Onboarding or sign-in screens
- Settings pages
What to check if your app is not already edge-to-edge
If your app is not already edge-to-edge, you are most likely impacted. In addition to the scenarios for apps that are already edge-to-edge, you should consider the following:
- If your app uses Material 3 Components (
androidx.compose.material3
) in compose, such asTopAppBar
,BottomAppBar
, andNavigationBar
, these components are likely not impacted because they automatically handle insets. - If your app is using Material 2 Components (
androidx.compose.material
) in Compose, these components don't automatically handle insets. However, you can get access to the insets and apply them manually. In androidx.compose.material 1.6.0 and later, use thewindowInsets
parameter to apply the insets manually forBottomAppBar
,TopAppBar
,BottomNavigation
, andNavigationRail
. Likewise, use thecontentWindowInsets
parameter forScaffold
. - If your app uses views and Material Components
(
com.google.android.material
), most views-based Material Components such asBottomNavigationView
,BottomAppBar
,NavigationRailView
, orNavigationView
, handle insets and require no additional work. However, you need to addandroid:fitsSystemWindows="true"
if usingAppBarLayout
. - For custom composables, apply the insets manually as padding. If your
content is within a
Scaffold
, you can consume insets using theScaffold
padding values. Otherwise, apply padding using one of theWindowInsets
. - If your app is using views and
BottomSheet
,SideSheet
or custom containers, apply padding usingViewCompat.setOnApplyWindowInsetsListener
. ForRecyclerView
, apply padding using this listener and also addclipToPadding="false"
.
What to check if your app must offer custom background protection
If your app must offer custom background protection to 3-button navigation or
the status bar, you app should place a composable or view behind the system bar
using WindowInsets.Type#tappableElement()
to get the 3-button
navigation bar height or WindowInsets.Type#statusBars
.
Additional edge-to-edge resources
See the Edge to Edge Views and Edge to Edge Compose guides for additional considerations on applying insets.
Deprecated APIs
The following APIs are now deprecated:
R.attr#enforceStatusBarContrast
R.attr#navigationBarColor
R.attr#navigationBarDividerColor
R.attr#statusBarColor
Window#getNavigationBarColor
Window#getNavigationBarDividerColor
Window#getStatusBarColor
Window#isStatusBarContrastEnforced
Window#setDecorFitsSystemWindows
Window#setNavigationBarColor
Window#setNavigationBarDividerColor
Window#setStatusBarColor
Window#setStatusBarContrastEnforced
稳定配置
如果您的应用以 Android 15 或更高版本为目标平台,Configuration
将不再排除系统栏。如果您在 Configuration
类中使用屏幕尺寸计算布局,则应根据需要将其替换为合适的 ViewGroup
、WindowInsets
或 WindowMetricsCalculator
等更好的替代方案。
从 API 1 开始,Configuration
一直可用。它通常从 Activity.onConfigurationChanged
获取。它可提供窗口密度、方向和大小等信息。从 Configuration
返回的窗口大小的一个重要特征是它之前排除了系统栏。
配置大小通常用于资源选择(如 /res/layout-h500dp
),这仍然是一个有效的用例。不过,我们一直不建议将其用于布局计算。如果这样做,您应该立即离开。您应该根据自己的使用场景,将 Configuration
替换为更合适的代码。
如果您使用其计算布局,请使用适当的 ViewGroup
,例如 CoordinatorLayout
或 ConstraintLayout
。如果您使用它来确定系统导航栏的高度,请使用 WindowInsets
。如果您想知道应用窗口的当前大小,请使用 computeCurrentWindowMetrics
。
以下列表介绍了受此更改影响的字段:
Configuration.screenWidthDp
和screenHeightDp
尺寸不再排除系统栏。Configuration.smallestScreenWidthDp
会受到screenWidthDp
和screenHeightDp
更改的间接影响。- 在近方形设备上,对
screenWidthDp
和screenHeightDp
的更改会间接影响Configuration.orientation
。 Display.getSize(Point)
会受到Configuration
中变更的间接影响。从 API 级别 30 开始,此 API 已被废弃。- 从 API 级别 33 开始,
Display.getMetrics()
就一直以这种方式运行。
UltraTextHeight 속성의 기본값이 true로 설정됩니다.
对于以 Android 15 为目标平台的应用,elegantTextHeight
TextView
属性默认变为 true
,将默认使用的紧凑字体替换为一些具有较大垂直指标的脚本,并且这种字体更易于阅读。紧凑字体的引入是为了防止破坏布局;Android 13(API 级别 33)允许文本布局利用 fallbackLineSpacing
属性拉伸垂直高度,以防止许多此类破坏。
在 Android 15 中,紧凑字体仍保留在系统中,因此您的应用可以将 elegantTextHeight
设置为 false
,以获得与之前相同的行为,但即将在未来版本中提供支持。因此,如果您的应用支持以下文字:阿拉伯语、老挝语、缅甸、泰米尔语、古吉拉特语、卡纳达语、马拉雅拉姆语、奥里亚语、泰卢固语或泰语,请将 elegantTextHeight
设置为 true
,以测试应用。
복잡한 문자 도형의 TextView 너비 변경
在以前的 Android 版本中,一些采用复杂形状的草体字体或语言可能会在上一个或下一个字符区域中绘制字母。在某些情况下,此类字母会在开始或结束位置被截断。从 Android 15 开始,TextView
会分配宽度来为此类字母绘制足够的空间,并允许应用请求左侧添加额外的内边距以防止被裁剪。
由于此变更会影响 TextView
确定宽度的方式,因此如果应用以 Android 15 或更高版本为目标平台,TextView
会默认分配更多宽度。您可以通过对 TextView
调用 setUseBoundsForWidth
API 来启用或停用此行为。
由于添加左侧内边距可能会导致现有布局未对齐,因此默认情况下,系统不会添加内边距,即使对于以 Android 15 或更高版本为目标平台的应用也是如此。不过,您可以通过调用 setShiftDrawingOffsetForStartOverhang
添加额外的内边距以防止裁剪。
以下示例展示了这些更改如何改进某些字体和语言的文本布局。
EditText의 언어 인식 기본 줄 높이
在以前的 Android 版本中,文本布局拉伸了文本的高度,使其适应与当前语言区域匹配的字体的行高。例如,如果内容是日语,由于日语字体的行高比拉丁字体的行高略大,因此文本的高度就略大了。不过,尽管行高存在这些差异,但无论使用何种语言区域,EditText
元素的大小都是一致的,如下图所示:
对于以 Android 15 为目标平台的应用,系统现在会为 EditText
预留最小行高,以匹配指定语言区域的参考字体,如下图所示:
如果需要,您的应用可以通过将 useLocalePreferredLineHeightForMinimum
属性设置为 false
来恢复之前的行为,并且可以通过 Kotlin 和 Java 中的 setMinimumFontMetrics
API 设置自定义最小行业指标。
카메라 및 미디어
Android 15에서는 Android 15 이상을 타겟팅하는 앱의 카메라 및 미디어 동작을 다음과 같이 변경합니다.
오디오 포커스 요청 제한사항
以 Android 15 为目标平台的应用必须是热门应用或运行与音频相关的前台服务,才能请求音频焦点。如果应用在不符合其中任何一项要求时尝试请求焦点,调用会返回 AUDIOFOCUS_REQUEST_FAILED
。
如果前台服务的类型为 mediaPlayback
、camera
、microphone
或 phoneCall
,则会被视为与音频相关。
如需详细了解音频焦点,请参阅管理音频焦点。
업데이트된 비 SDK 제한사항
Android 15 包含更新后的受限非 SDK 接口列表(基于与 Android 开发者之间的协作以及最新的内部测试)。在限制使用非 SDK 接口之前,我们会尽可能确保有可用的公开替代方案。
如果您的应用并非以 Android 15 为目标平台,其中一些变更可能不会立即对您产生影响。不过,虽然您的应用可以访问某些非 SDK 接口(具体取决于应用的目标 API 级别),但使用任何非 SDK 方法或字段始终存在导致应用出问题的显著风险。
如果您不确定自己的应用是否使用了非 SDK 接口,则可以测试该应用进行确认。如果您的应用依赖于非 SDK 接口,则应开始计划迁移到 SDK 替代方案。不过,我们知道某些应用具有使用非 SDK 接口的有效用例。如果您无法为应用中的功能找到无需使用非 SDK 接口的替代方案,则应请求新的公共 API。
<如需详细了解此 Android 版本中的变更,请参阅 Android 15 中有关限制非 SDK 接口的更新。如需全面了解有关非 SDK 接口的详细信息,请参阅对非 SDK 接口的限制。