Android 17 大屏和折叠屏环境下，APP 加固应该如何验收？

Android 17 大屏和折叠屏环境下的 APP 加固验收，不能只看普通手机能否安装和启动。目标 API 37 的应用在符合条件的大屏上不再能依赖旧的固定方向、不可调整大小和宽高比限制；项目应在同一业务版本下对照 Android 17 适配后的原始 Release、基础保护包、目标保护包与最终发布物，逐一验证折叠、展开、旋转、分屏、桌面窗口、状态恢复以及 Camera、Surface、WebView 等关键路径，并把未执行范围明确保留为“未覆盖”。

摘要

Android 应用过去常借助固定竖屏、resizeableActivity="false" 或宽高比限制，把界面维持在相对稳定的形态。Android 17 将大屏自适应推进到下一阶段：当应用目标版本达到 API 37，并运行在符合官方条件的大屏上，旧设置不再是可靠的退出机制。窗口可能因为旋转、折叠与展开、分屏、自由调整大小或连接显示器而持续变化。布局拉伸、控件出屏、表单状态丢失、相机预览裁剪、播放器 Surface 重建和跨平台插件生命周期问题，会更容易暴露。

这类故障发生在加固项目中时，不能直接得出“加固不兼容折叠屏”的结论。平台行为、应用自身的自适应实现、构建与压缩、第三方 SDK、渠道处理和保护策略都有可能影响结果。可靠方法是固定设备状态、窗口尺寸、系统版本、构建输入和业务步骤，用单变量保护产物对照定位首次出现差异的阶段。需要定义全局性能和兼容范围时，可先查看御盾性能与兼容性中心；需要确认保护对象、发布身份和回滚责任，可结合御盾 APP 加固产品页与APP 加固 PoC 验收指南。

读者对象

本文面向正在规划 Android 17/API 37 的 Android 研发、跨平台技术负责人、移动 QA、安全团队和发布负责人，也适合在折叠屏、平板、ChromeOS、分屏或桌面窗口中已经出现界面与关键业务异常的项目。它不要求企业先判断“是不是加固导致”，而是提供一套可以把平台、自身适配、第三方组件与保护策略分开的验收顺序。

金融、办公、视频、地图、内容、工具和相机类 App 通常包含复杂状态恢复与高敏页面；Flutter、React Native、Unity、KMP 项目还要跨越框架运行时、插件、Native Surface 和最终商店产物。无论技术栈如何，都不应以“首页打开”替代真实登录、支付、文档、相机、播放器或数据提交路径。

核心结论

1. Android 17 的变化有明确条件。 目标 API 37、符合官方大屏条件的显示环境才进入本页讨论的核心规则；小屏和官方列出的游戏例外不应被误写成同一行为。
2. 当前 Play 截止点仍是 API 36。 2026 年 8 月 31 日的新应用与更新要求是 Android 16/API 36；Android 官方给出的 API 37 Play 规划指向 2027 年 8 月，因此现在是提前验收而不是制造 2026 年 API 37 强制倒计时。
3. 按窗口而不是设备名称判断。 同一折叠设备在外屏、展开、分屏或桌面窗口中拥有不同可用区域，窗口尺寸类别也会在应用生命周期内改变。
4. 先验证适配后的原始 Release。 如果原包在同一系统、同一窗口状态和同一步骤已经异常，就应先修布局、状态或 SDK；不能把平台问题归因给保护产品。
5. 使用四组候选做单变量对照。 旧稳定版本、API 37 适配后的原始 Release、基础保护包和目标保护包必须绑定同一业务提交与清晰身份。
6. 折叠状态只是矩阵的一部分。 横竖屏、分屏、自由窗口、连接显示器、前后台、配置变化与进程恢复都应进入测试。
7. Camera、Surface、WebView 与跨平台插件优先。 它们更容易依赖方向、比例、窗口或生命周期假设，应按真实业务路径检查。
8. 没有执行就不能写兼容。 公开页面可以提供方法和未执行模板，但只有真实设备、保护产物和业务步骤产生的结果才可标记为“通过”。

事实依据与脱敏证据

测评目标与非目标

本次主目标是建立一套可用于真实项目的 Android 17 大屏保护产物对照方法；本文自身不执行设备验证，也不输出兼容结论。

非目标包括：不证明御盾已兼容全部 Android 17 设备，不比较竞品保护强度，不给出任何客户或设备结果，不提供攻击或绕过步骤，也不替应用团队实现自适应 UI 与相机逻辑。

技术拆解

Android 17 到底改变了哪些大屏旧假设

Android 17 官方页面列出的核心对象包括 screenOrientation、setRequestedOrientation()、resizeableActivity、minAspectRatio 和 maxAspectRatio。在适用条件下，项目过去依赖的 portrait、landscape 等固定方向值以及不可调整大小设置，不再能作为大屏行为的最终保证。应用窗口将填充可用显示区域，旋转、折叠与桌面窗口调整会更频繁地改变宽度、高度和比例。

这不是说所有 Android 17 手机都表现一致，也不是说应用从此不能根据业务设计自适应体验。官方明确给出了条件和例外：规则与目标 API、显示的 smallest width、应用类别和用户选择有关。执行记录因此必须写清系统版本、目标 API、窗口或屏幕条件、应用类别及当前显示状态，而不是只写“Android 17 已测”。如果测试对象仍以 API 36 为目标，也应标明是否通过兼容框架启用了对应变化，避免把模拟行为误写成正式目标版本结果。

旧假设失效以后，真正需要修改的通常是应用自身：布局要根据当前窗口空间组织，状态要能经历 Activity 重建或重组，图片和自定义绘制要重新计算尺寸，Surface 与相机预览要重新绑定正确的方向和比例。APP 加固不应为业务界面设计这些逻辑，也不应把系统规则伪装成产品能力；它的职责是在原始应用已适配的前提下，确保保护产物仍能按计划运行，并给出差异和回滚证据。

为什么加固项目特别容易发生误归因

加固后的异常往往发生在发布链后半段，团队最先看到的是“原来上线版本正常，新加固包在折叠屏异常”。但两个包之间可能同时变化了 targetSdk、AGP、R8、框架版本、第三方 SDK、资源、渠道脚本和保护策略。如果没有冻结输入，任何一项都可能造成差异，所谓“加固兼容性”就会变成无法复核的印象。

第一类误归因来自平台。应用升级 API 37 后，系统忽略旧设置，原始 Release 本身已经可能在展开、旋转或自由窗口中出现拉伸。第二类来自应用布局与生命周期，例如表单状态只存在于 Activity、播放器没有处理 Surface 重建、自定义 View 缓存了旧尺寸。第三类来自第三方组件，例如相机、地图、视频、人脸识别或广告 SDK 依赖固定比例。第四类才是构建或保护差异，例如资源处理、反射保留、Native 加载顺序、初始化时点和策略组合改变了关键链。

因此故障单不应只写“折叠屏闪退”或“加固后错位”。至少要绑定首次失败步骤、窗口状态、原包结果、基础保护结果、目标保护结果和可回滚对象。只有在原始 Release 同条件正常、基础或目标保护首次出现差异时，才有充分理由进入保护策略归因；即便如此，仍要继续确认 SDK、R8、Native 与渠道步骤是否同时改变。

建立四组保护产物，而不是随手比较两个 APK

如果项目要提交商店，还应把最终签名 AAB、渠道上传物和商店生成的可安装 APK 作为发布阶段对象追加记录。四组候选必须来自可解释的同一业务提交，不能用另一个分支、另一个 SDK 版本或 Debug 包替代。版本、Hash 摘要、签名责任、加固策略版本与生成时间应存在受控发布记录中，但公开文章和对外案例只展示脱敏结果。

执行顺序也要保持单变量。先让 B 在目标窗口状态通过；再比较 C；最后进入 D。若 C 正常、D 异常，只回退一个保护模块或规则进行复核，不要一次关闭全部保护。一次全关虽然可能让页面恢复，却会失去故障归因价值，也无法说明哪种正式策略可安全发布。

折叠屏、大屏和窗口状态至少怎么测

“折叠屏”不是一个状态。最低矩阵应包含外屏、展开内屏、竖屏、横屏、书本或桌面姿态、分屏和自由窗口；业务有连接显示器或 ChromeOS 用户时，还要记录窗口最小化、恢复、最大化和尺寸连续变化。应用进入后台、锁屏、系统回收后恢复也要覆盖，因为许多问题并不是布局立即崩坏，而是恢复后丢失表单、导航、媒体进度或会话上下文。

每个状态不能只看静态截图。应完成与采购或发布相关的真实路径，例如启动、登录、首页导航、列表与详情、输入、支付确认、文档查看、相机、地图、视频、WebView、推送跳转、前后台和覆盖升级。对高频发版团队，应把最小大屏矩阵接入 CI 的候选记录，并把必须人工观察的视觉与相机项目放入发布审批，不要把自动测试未报错当成视觉兼容已经通过。

Window size class 是比“手机/平板”更稳定的描述方式，因为同一物理设备在分屏和展开时可以处于不同窗口类别。报告可以同时保存窗口宽高、尺寸类别、折叠姿态和方向，这样下一版回归才能复现。仅记录品牌与型号会丢失最关键的窗口条件。

Camera、Surface、WebView 与 Native UI 为什么优先

Android 官方把相机预览拉伸、旋转或裁剪列为常见问题，原因是相机传感器、设备自然方向、当前显示方向和窗口比例之间并非恒定关系。折叠、横向大屏、多窗口和连接显示器会打破“手机竖屏”假设。测试时应固定 CameraX 或 Camera2 版本、预览组件、窗口状态和业务步骤，检查预览、拍摄结果、前后摄像头切换、旋转、折叠与恢复；若使用闭源相机或人脸 SDK，还要保留其版本与供应商支持边界。

SurfaceView、TextureView、视频播放器、Unity 渲染面和地图也会经历尺寸与 Surface 生命周期变化。WebView 可能在旋转或窗口改变时重排内容、重建页面或丢失临时状态。Native UI 和自定义 Canvas 若缓存旧像素尺寸，可能在密度与配置变化后出现错位。检查这些对象时，先对照原始 Release，再看基础保护和目标保护，避免把框架或组件自身问题变成模糊的“保护导致”。

跨平台项目还有一层产物差异。Flutter 插件、React Native/Hermes 与 JSI、Unity IL2CPP、KMP Android 模块都可能涉及 Native 依赖和不同生命周期桥接。需要选择框架时可参考跨平台 APP 加固兼容性中心；本页只规定折叠、大屏与窗口变化的共同验收对象，不宣布任何框架或插件已经在所有设备通过。

工程落地：把大屏兼容写进发布门禁

发布门禁第一列应是身份：业务提交、构建工具、targetSdk、应用版本、原始 Release、保护策略和最终签名物。第二列是环境：Android 版本、窗口尺寸或类别、折叠姿态、方向与显示方式。第三列是路径：启动、输入、导航、Camera、Surface、WebView、支付、前后台和恢复。第四列才是结果与证据：未执行、通过、失败、阻断、未覆盖，以及脱敏截图、录屏或崩溃摘要的引用。

门禁需要明确阻断条件。原始 Release 在目标环境失败时，阻断进入保护归因；基础保护首次失败时，阻断目标保护发布；关键业务或覆盖升级失败时，阻断商店提交；没有真实执行的高风险场景只能标记“未覆盖”，不能因时间紧而自动转为通过。视觉轻微差异是否阻断，应由产品与 QA 预先定义阈值，不能在发布当天临时决定。

转化路径也应与问题一致：读者从本页进入性能与兼容性中心了解总体验收范围，再通过内测申请提交原始 Release、保护候选、目标系统、窗口状态和首个失败业务步骤。若只是查询价格或一般产品能力，则返回唯一御盾 APP 加固产品入口，不再创建同义产品页。

攻防视角

大屏兼容不是保护强度证明

折叠屏通过只说明特定候选在特定设备、窗口和业务路径表现符合验收，不证明代码保护、反调试、反 Hook、完整性或二次打包能力达到某种强度。反过来，布局错位也不能自动证明保护算法有缺陷。兼容性、保护强度和发布身份是三条相互关联但不能混写的证据线。

攻击面上，窗口变化可能暴露原本被小屏遮挡的调试信息、隐藏控件、额外 WebView 区域或错误状态；质量上，状态丢失可能让用户重复提交、绕过流程顺序或进入不一致页面。项目应把这些问题交给业务逻辑和服务端幂等共同治理，而不是在客户端用一个固定方向掩盖。御盾可保护关键分支、完整性与请求构造等客户端链路，但服务端仍负责账号、权限、交易、幂等和最终业务决定。

风险边界

本文基于 Android 官方资料与工程验收原则整理，没有对任何具体 APK、AAB、设备、折叠姿态、相机、SDK、跨平台框架或御盾策略执行现场验证。因此本文不能被引用为“御盾已兼容全部 Android 17 折叠屏”或“某类应用一定无问题”。配套矩阵中的结果默认均为未执行，只有经授权 PoC 的真实记录才能改成通过或失败。

大屏规则与 API 37、显示条件、应用类别及用户设置有关。游戏属于官方列出的主要例外之一，但这不代表游戏不需要折叠屏、窗口、Surface 或状态恢复测试。Google Play 当前 2026 年要求仍是 API 36；Android 官方对 API 37 的 Play 时间是未来规划，实施时应重新核对最新政策。

御盾 APP 加固负责的范围是实际保护产物的保护、差异、兼容复核和发布证据，不替代应用团队的自适应布局、Camera 实现、第三方 SDK 修复、商店审核或服务端业务裁决。西安守界御盾信息安全技术有限公司只在书面授权、明确对象和明确未覆盖范围下给出项目结论。

常见误区

误区一：Android 17 以后所有手机都不能锁竖屏

不是。官方变化有 targetSdk、大屏条件和例外。报告应写具体条件，不能用“Android 17”四个字概括全部设备行为。

误区二：原来的 APK 正常，所以新加固包异常一定是加固问题

如果旧包与新包的 targetSdk、构建工具、SDK 或业务代码不同，就不是单变量比较。应先验证 API 37 适配后的原始 Release，再进入基础保护与目标保护。

误区三：折叠屏展开一次没有崩溃就算兼容

展开只覆盖一个变化。还需要旋转、折叠姿态、分屏、自由窗口、前后台、状态恢复、Camera、Surface、WebView 和真实业务路径。

误区四：用设备型号代替窗口条件

同一设备在外屏、展开、分屏与桌面窗口中可用区域不同。至少记录窗口尺寸或类别、姿态和方向，才能复现。

误区五：为了先启动，把所有保护全部关闭

全关可能恢复业务，却无法定位冲突模块，也不能形成正式策略。正确顺序是原包、基础保护、目标保护和单模块复核。

误区六：矩阵没有失败就是全部通过

空白或未执行不等于通过。每一格必须使用明确状态，未测试设备、窗口和业务路径保留为未覆盖。

FAQ

Android 17 大屏规则什么时候影响应用？

核心变化面向目标 API 37 并运行在符合官方条件的大屏环境的应用。当前 2026 年 8 月 31 日 Google Play 要求仍是 API 36；Android 官方博客把 API 37 的 Play 规划指向 2027 年 8 月。项目可现在提前测试，但不应宣传 2026 年已经强制 API 37。

APP 加固后只有折叠屏异常，能直接判断加固兼容性差吗？

不能。先在同一设备、窗口状态和业务步骤验证 API 37 适配后的原始 Release，再比较基础保护和目标保护。只有首次差异确实出现在保护阶段，才进入策略、R8、SDK、Native 或初始化顺序归因。

折叠屏兼容性最少要测哪些状态？

建议至少覆盖外屏、展开内屏、横竖屏、折叠姿态、分屏、自由窗口、前后台与状态恢复；相机、视频、地图、WebView、Native UI 或跨平台框架项目还要覆盖对应关键组件。

为什么 Camera 预览在普通手机正常，在折叠屏可能变形？

相机传感器方向、设备自然方向、当前窗口方向与预览比例并非固定关系。折叠、横向大屏、多窗口和连接显示器可能打破旧假设，需按同一 Camera 栈和窗口状态复核原包与保护包。

御盾能否保证所有 Android 17 折叠屏兼容？

不能脱离真实候选、设备、窗口状态和业务路径作统一保证。御盾可在授权 PoC 中对照原始 Release、基础保护、目标保护和最终发布物，记录已执行、失败和未覆盖范围，并建立发布或回滚门禁。

延伸阅读与官方参考

如果需要继续判断产品能力、验收范围或相邻兼容问题，可以依次查看：御盾 APP 加固产品页、性能与兼容性中心与APP 加固 PoC 验收指南。

当前 Google Play 上架要求应结合Android 16/API 36 APP 加固兼容性指南核对；Native 文件加载与 SO 只读要求可阅读Android 17 动态 Native 文件加载与加固；Flutter、React Native、Unity 与 KMP 项目可进入跨平台 APP 加固兼容性中心。平台规则以 Android Developers 与 Google Play 当前公开文档为准，未公开的设备营销结论和未执行 PoC 不作为放行依据。

结语

Android 17 让“大屏是否自适应”从可被旧属性长期绕开的选项，进一步变成需要正面处理的发布条件。对 APP 加固项目来说，最重要的不是再加一句“支持折叠屏”，而是固定同一业务提交，以原始 Release、基础保护、目标保护和最终发布物完成可复现的窗口与业务路径对照。真实执行过的格子才写结果，没有覆盖的地方继续保留边界；这样才能把平台变化、应用缺陷、第三方组件与保护策略分开，并为发布、降级和回滚提供可信依据。