Android在Android 8.0上略微更改了他们的权限政策：
在Android 8.0（API级别26）之前，如果某个应用请求了权限 在运行时并且授予了权限，系统也是错误的 授予应用程序其他属于同一权限的权限 权限组，以及在清单中注册的。
对于定位到Android 8.0的应用，此行为已得到纠正。该 应用程序仅被授予其明确请求的权限。 但是，一旦用户授予应用程序权限，所有后续操作 该权限组中的权限请求是自动的 理所当然的。
例如，假设某个应用列出了READ_EXTERNAL_STORAGE和 其清单中有WRITE_EXTERNAL_STORAGE。应用程序请求 READ_EXTERNAL_STORAGE，用户授予它。如果该应用针对API 级别25或更低，系统还授予WRITE_EXTERNAL_STORAGE 同时，因为它属于同一个STORAGE权限组 并且也在清单中注册。如果该应用针对的是Android 8.0 （API级别26），系统仅授予READ_EXTERNAL_STORAGE 时间;但是，如果应用程序稍后请求WRITE_EXTERNAL_STORAGE，则 系统会在不提示用户的情况下立即授予该权限。
此类变更的好处是什么？它们似乎达到了同样的目的。以前新方法修复的方法可能出现什么问题？
答案 0 :(得分：3)
新版修复的先前方法可能出现什么问题？
嗯，你知道，有这个错误......
引用the research paper，重点补充：
首先，对手创建了一个应用程序 在其清单文件中包含自定义权限声明 具有保护级别
normal要么signature并设置此 自定义权限是系统权限组的一部分 （例如，存储，相机等）。然后，他们更新定义 这个自定义权限，以便保护级别 变成dangerous然后继续推送更新 他们在相应的应用市场上的应用...期望是 因为自定义权限是级别的dangerous， 将在运行时提示用户做出是否的决定 在运行时权限中授予或拒绝此权限 模型。但是，恶意应用程序会自动获得授权 许可。另外，由于运行时权限 模型以群组为基础授予dangerous权限，应用 还自动获得所有其他要求的危险 原始系统权限组的权限 权限属于。可以遵循相同的程序 攻击 任何 系统权限组;因此，对手可以 默默地获得 所有 系统权限同时。在Android清单中请求危险权限构成 对于对手没有任何问题，作为许可要求 从那时起，应用程序不会直接呈现给用户 Android 6.0。因此，用户将完全不知道 所有这些系统权限都授予应用程序。
AFAICT，此Android 8.0更改是此错误的缓解策略的一部分。这只会有所帮助，因此我假设其他更改也是如此。但是，考虑到本文中提到的bug的性质以及Android 8.0的性质，我不得不假设这两者至少有些相关。