伪造更高Android Target SDK版本是否安全？存在哪些潜在风险？

我使用Delphi 10.4开发Android应用（该问题适用于所有开发环境，如ADS Jetpack Compose、React Native等），其自带Android SDK 29/NDK 21。我曾尝试升级至SDK 31但未成功，而Google Play自2022年12月起要求所有应用必须以Target SDK 31发布。

有Delphi开发者建议我手动编辑AndroidManifest.xml，将Target SDK伪造成31，同时继续使用SDK 29编译。我的核心问题是：伪造更高的Target SDK API版本是否可行？这么做会引发哪些问题？

Target SDK相关特性的核心逻辑 #

我研究过Target SDK的具体含义，核心结论如下：
Android应用的特性分为两类：

• 依赖特定API版本的特性：这类特性的实现会随SDK版本变化。设置min-SDK和target-SDK后，编译时理论上会包含从min-SDK到target-SDK的所有版本实现；但如果compile-SDK < target-SDK（官方不推荐该配置，推荐compile-SDK ≥ target-SDK），最终APK仅包含[min-SDK, compile-SDK]区间的实现，编译器无法获取(compile-SDK, target-SDK]区间的实现。应用运行时，设备系统会根据自身SDK版本，从APK中选取最接近的特性版本。
• 无SDK依赖的特性：这类特性的实现不会随SDK版本变化，不存在兼容性问题。

假设我的配置为：

min-SDK: 23
compile-SDK: 29
target-SDK: 31

假设有特性X存在v23、v24……v29、v30、v31版本的实现，使用compile-SDK 29编译的APK仅包含v23至v29的实现。

核心疑问：Android系统的处理逻辑 #

我想知道，Android系统会如何处理标注target-SDK=31但仅包含v23-v29特性实现的APK？

我设想了两种可能的处理逻辑（假设设备SDK版本为30或31）：

1. Android系统尝试读取v30/v31版本的特性实现，若未找到则立即报错，提示特性不支持；
2. Android系统尝试读取v30/v31版本的特性实现，若未找到则依次尝试v29、v28……直至min-SDK版本的实现，找到后使用该旧版本实现，仅在Logcat中输出警告，应用可正常运行，无中断或错误提示。

哪种场景符合实际情况？我猜测是第二种，因为我从未见过此类应用安装后运行时出现兼容性报错。此外，我了解到部分维护良好的代码库会刻意使用compile-SDK < target-SDK的配置，以保留旧SDK版本的特性行为，仅将target-SDK设为更高版本以通过Google Play审核。

内容的提问来源于stack exchange，提问作者TomR