uni-app targetSdkVersion填30时云打包后相册权限异常

uni-app targetSdkVersion填30时云打包后相册权限异常

操作步骤:

  • targetSdkVersion填30后云打包

预期结果:

  • uni.chooseImage能正常使用

实际结果:

  • 调用uni.chooseImage后出来的相册是空的

bug描述:

targetSdkVersion填30,云打包后,将APP安装到安卓14手机上,在app内允许相册权限,调用uni.chooseImage,打开的相册是空的。 plus.navigator.checkPermission(‘android.permission.READ_MEDIA_IMAGES’) 返回是authored,但实际上是禁止的。 代码里有判断,安卓13及以上用的是READ_MEDIA_IMAGES权限,安卓13以下用的是READ_EXTERNAL_STORAGE权限。 后来targetSdkVersion填34,重新打云包后。功能就正常了。而且看起来,存储权限那里也不一样,只有一个照片与视频(最后一张图片跟第三张图比较)。 但是真机运行到标准基座,还是不行(targetSdkVersion填34打包的自定义基座,功能正常)

图片

Image 1 Image 2 Image 3 Image 4


更多关于uni-app targetSdkVersion填30时云打包后相册权限异常的实战教程也可以访问 https://www.itying.com/category-93-b0.html

26 回复

急求解惑

更多关于uni-app targetSdkVersion填30时云打包后相册权限异常的实战教程也可以访问 https://www.itying.com/category-93-b0.html


我这边验证没问题,说一下你这边的复现流程吧,还有这个权限申请是在什么情况下触发的;或者提供一个安装包,说明一下复现步骤

回复 DCloud_Android_zl: 你好,安装包下载地址和操作流程录屏都放在机密信息里了,请看下

回复 梁飞鸿: manifest.json 发一下吧

回复 DCloud_Android_zl: 附件里发了

回复 梁飞鸿: 你用4.14重新打包试一下呢,我这边各种环境下目前无法复现这个问题,你看一下用最新的打包有没有问题。

回复 梁飞鸿: 麻烦升级到最新之后用传统打包重新提交一次,我这边现在环境无法复现,我这边测试的云打包也是没问题的

回复 DCloud_Android_zl: 用4.14传统打包重新提交一次,还是一样的,相册是空的。好像必须是安卓14才有这问题

回复 DCloud_Android_zl: 我这手机是vivo的,系统是安卓14

回复 梁飞鸿: 好的,我再看一下

回复 DCloud_Android_zl: 我这边实在是复现不了你这个问题,你要不把这个图片选择拆出来个示例发给我,我看一下。

回复 DCloud_Android_zl: 你好项目在附件里,请看下

问题已经定位到了,因为android13上存储权限已经被废弃,高于android13的设备应该申请android.permission.READ_MEDIA_IMAGES。我看代码是因为你们自己实现了图片选择,在处理android 权限申请时,需要区分不同的android 版本申请不同的权限。或者可以使用我们提供的图片选择。

你好,我代码里有判断啊,高于android13的申请的就是android.permission.READ_MEDIA_IMAGES

permission.js文件里300多行有判断代码

之所以没直接用uni.chooseImage,是因为应用市场要求调用权限之前要有权限说明。相机和相册是两个不同的权限,我们之前放在一起说明,上架时被拒审了。

回复 梁飞鸿: 我是直接替换的u-avatar-cropper.vue文件里的IMAGES_STORAGE,替换成android.permission.READ_MEDIA_IMAGES就正常请求权限了,你看一下是不是permission.js判断逻辑出了问题。

回复 DCloud_Android_zl: 我试了,完全不行啊。你是不是之前先用android.permission.READ_EXTERNAL_STORAGE授权的啊,这个授权过了,那肯定是没问题啊

回复 DCloud_Android_zl: 将u-avatar-cropper.vue文件里的IMAGES_STORAGE,替换成android.permission.READ_MEDIA_IMAGES,手机上app删掉,然后自定义基座真机运行。还是不行啊

回复 DCloud_Android_zl: targetSdkVersion填34打包,功能就是正常,这种又是什么原因呢?

回复 DCloud_Android_zl: 这个问题的bug描述我有更新,请看下

回复 梁飞鸿: 重新看了一下,如果应用targetSDK低于33的话,android.permission.WRITE_EXTERNAL_STORAGE也需要同时申请。也就是调用plus.android.requestPermissions需要传入两个权限。[“android.permission.READ_MEDIA_IMAGES”,“android.permission.WRITE_EXTERNAL_STORAGE”] https://developer.android.com/reference/android/Manifest.permission#READ_EXTERNAL_STORAGE

回复 DCloud_Android_zl: 好的,感谢

请问解决了吗

如果应用targetSDK低于33的话,android.permission.WRITE_EXTERNAL_STORAGE也需要同时申请。也就是调用plus.android.requestPermissions需要传入两个权限。[“android.permission.READ_MEDIA_IMAGES”,“android.permission.WRITE_EXTERNAL_STORAGE”]

在 UniApp 中,当你将 targetSdkVersion 设置为 30 时,可能会遇到相册权限异常的问题。这是因为 Android 11(API 30)引入了一些新的权限管理机制,特别是对存储权限的更改。

问题原因

在 Android 11 中,Google 引入了 Scoped Storage(分区存储)机制,对应用访问外部存储的方式进行了限制。默认情况下,应用只能访问自己的文件和公共媒体文件(如照片、视频、音频等)。如果你需要访问其他文件,可能需要额外的权限或使用特定的 API。

解决方案

  1. 检查权限声明: 确保在 AndroidManifest.xml 中正确声明了所需的权限。对于访问相册,通常需要以下权限:

    <uses-permission android:name="android.permission.READ_EXTERNAL_STORAGE" />
    <uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE" />
    
  2. 动态请求权限: 在 Android 11 及以上版本,即使你在 AndroidManifest.xml 中声明了权限,仍然需要动态请求权限。你可以在 UniApp 中使用 uni.authorizeuni.requestAuthorization 来请求权限。

    uni.authorize({
        scope: 'scope.writePhotosAlbum',
        success() {
            console.log('授权成功');
        },
        fail() {
            console.log('授权失败');
        }
    });
    
  3. 适配 Scoped Storage: 如果你的应用需要访问外部存储中的非媒体文件,你可能需要适配 Scoped Storage。你可以通过以下方式处理:

    • 使用 MediaStore API 来访问媒体文件。
    • 使用 Storage Access Framework (SAF) 来访问其他文件。
  4. 修改 targetSdkVersion: 如果你暂时无法适配 Scoped Storage,可以将 targetSdkVersion 降级到 29 或更低版本。但这只是一个临时解决方案,因为 Google Play 要求新应用和应用更新必须至少以 Android 11(API 30)为目标平台。

    {
        "app-plus": {
            "distribute": {
                "android": {
                    "targetSdkVersion": 29
                }
            }
        }
    }
回到顶部