目录

快速处理app向系统申请录音与相机权限h5向app申请录音和相机权限

详细解答app权限与h5权限录音与麦克风默许的风险最佳实践

Android webview h5 麦克风权限,摄像头(相机)权限实现与填坑。

快速处理

app向系统申请录音与相机权限

app 必须先具备如下权限(本文只讨论录音与相机) AndroidManifest中添加:

注意:前面两项需要app动态申请

activity.requestPermissions(new String[]{

Manifest.permission.CAMERA,

Manifest.permission.RECORD_AUDIO},1111);

h5向app申请录音和相机权限

懒人快速做法(可直接copy代码)

默许授权(不再确认) 当h5向app申请的时候,重写WebChromeClient的onPermissionRequest 函数,直接授权。

webView.setWebChromeClient(new WebChromeClient(){

@Override

public void onPermissionRequest(PermissionRequest request) {

if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.LOLLIPOP) {

request.grant(request.getResources());

}

}

}

默许弹框的确认(不弹框) 当h5向app申请的时候,重写WebChromeClient的onJsAlert 函数,直接确认。

webView.setWebChromeClient(new WebChromeClient(){

@Override

public boolean onJsAlert(WebView view, String url, String message, JsResult result) {

result.confirm();

return true;

}

}

最后完整的WebChromeClient类至少重写上述两个函数:

webView.setWebChromeClient(new WebChromeClient(){

@Override

public boolean onConsoleMessage(ConsoleMessage consoleMessage) {

Log.w(TAG,"onConsoleMessage " + consoleMessage.messageLevel() + " " + consoleMessage.message());

return super.onConsoleMessage(consoleMessage);

}

@Override

public void onPermissionRequest(PermissionRequest request) {

if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.LOLLIPOP) {

request.grant(request.getResources());

request.getOrigin();

}

}

@Override

public boolean onJsAlert(WebView view, String url, String message, JsResult result) {

result.confirm();

return true;

}

});

详细解答

app权限与h5权限

可以简单这样理解,权限都是向宿主获得,那么app运行中系统中,app权限是向系统申请;h5运行中webview上,webview是app中使用的一个控件,可认为h5的权限是向webview或app申请的。这是要注意的区别,app获得权限不等于h5也获得了权限。

app 权限 这里的app权限,指app部分功需要的系统权限,例如相机/存储/网络权限,是app向系统申请的权限。 6.0之前,只需要把权限配置到AndroidManifest文件中就可以了,到6.0,除了需要在AndroidManifest配置对应全限外,还需要动态申请,也就是通过api调用来让用户确认是否给该app某个权限。用得最多的是存储权限,音视频横行的今天,相机/录音/蓝牙/定位是常见需要动态申请。这种询问申请模式可能会延续很长一段时间甚至一直持续下去。 为隐私数据的安全,app的权限是越来越严格,一方面是技术层面的趋势,一方面是隐私政策以及法规的约束,使得应用各方面的去满足(迎合)合规。 权限就是其中一项,基于系统,app需要向系统申请,同时系统再向使用者申请,最终确定是否具备相关权限。 一般情况下,app为保证功能正常,会在启动的时候一并申请所有的权限(需动态申请的),但在很多合规检测中,这是不合规的,因为存在权限申请了不用的(过多申请,例如申请了相机权限,只在主页停留就退出),也就要求用时申请。同时有些合规还要求在申请前详细提醒用户,这样就出现了一个不好的体验:当需要申请时先弹一个提示框(app),再弹一个授权框(系统),为了合规也得照做。 延伸:当前并没有一个统一的合规标准,很多公司有关系就能够做这块业务,而且做得很,拼命搞app的各种正常的漏洞,且不给具体的说明。app开发方各种抓头。一般会遇到如下几类场景:

上市公司需要软件方面的资质,因此要过级过审上商店,商店也是各种要求,且标准不一本身的数据安全与保护 动态权限申请: 权限检查if(ContextCompat.checkSelfPermission(this,Manifest.permission.CAMERA) != PackageManager.PERMISSION_GRANTED){

activity.requestPermissions(new String[]{

Manifest.permission.CAMERA,

Manifest.permission.RECORD_AUDIO,

Manifest.permission.READ_EXTERNAL_STORAGE},1111);

}else {

//已获得权限

}

请求申请activity.requestPermissions(new String[]{

Manifest.permission.CAMERA,

Manifest.permission.RECORD_AUDIO,

Manifest.permission.READ_EXTERNAL_STORAGE},1111);

申请响应@Override

public void onRequestPermissionsResult(int requestCode, @NonNull String[] permissions, @NonNull int[] grantResults) {

super.onRequestPermissionsResult(requestCode, permissions, grantResults);

if (requestCode == 1111){

if (grantResults.length > 0){

//此处分别判断grantResults 如grantResults[0] == PackageManager.PERMISSION_GRANTED

}

}

}

上述是多个一起申请,实际可单独申请或其他组合进行申请。h5权限 如果h5运行在app中webview中,那么需要进一步授权,前提是app获得的权限一定要包含h5所申请的权限。值得注意的是,h5的权限定义与app的权限定义不完全吻合。 h5作为一个应用,也和app一样需要获取相关的权限。

重写WebChromeClient类的 onPermissionRequest函数授权(接受申请)request.grant(request.getResources())拒绝request.deny()接着重写WebChromeClient类的 onJsAlert,实现弹框以及弹框的确认 源码的实现 默认情况下h5权限申请,webview是拒绝的(默认是没有授权),这点我们可从源码中看出来,不重写onPermissionRequest,默认实现就是request.deny():/**

* Notify the host application that web content is requesting permission to

* access the specified resources and the permission currently isn't granted

* or denied. The host application must invoke {@link PermissionRequest#grant(String[])}

* or {@link PermissionRequest#deny()}.

*

* If this method isn't overridden, the permission is denied.

*

* @param request the PermissionRequest from current web content.

*/

public void onPermissionRequest(PermissionRequest request) {

request.deny();

}

再来看看PermissionRequestpublic abstract class PermissionRequest {

/**

* Resource belongs to video capture device, like camera.

*/

public final static String RESOURCE_VIDEO_CAPTURE = "android.webkit.resource.VIDEO_CAPTURE";

/**

* Resource belongs to audio capture device, like microphone.

*/

public final static String RESOURCE_AUDIO_CAPTURE = "android.webkit.resource.AUDIO_CAPTURE";

/**

* Resource belongs to protected media identifier.

* After the user grants this resource, the origin can use EME APIs to generate the license

* requests.

*/

public final static String RESOURCE_PROTECTED_MEDIA_ID =

"android.webkit.resource.PROTECTED_MEDIA_ID";

/**

* Resource will allow sysex messages to be sent to or received from MIDI devices. These

* messages are privileged operations, e.g. modifying sound libraries and sampling data, or

* even updating the MIDI device's firmware.

*

* Permission may be requested for this resource in API levels 21 and above, if the Android

* device has been updated to WebView 45 or above.

*/

public final static String RESOURCE_MIDI_SYSEX = "android.webkit.resource.MIDI_SYSEX";

/**

* Call this method to get the origin of the web page which is trying to access

* the restricted resources.

*

* @return the origin of web content which attempt to access the restricted

* resources.

*/

public abstract Uri getOrigin();

/**

* Call this method to get the resources the web page is trying to access.

*

* @return the array of resources the web content wants to access.

*/

public abstract String[] getResources();

/**

* Call this method to grant origin the permission to access the given resources.

* The granted permission is only valid for this WebView.

*

* @param resources the resources granted to be accessed by origin, to grant

* request, the requested resources returned by {@link #getResources()}

* must be equals or a subset of granted resources.

* This parameter is designed to avoid granting permission by accident

* especially when new resources are requested by web content.

*/

public abstract void grant(String[] resources);

/**

* Call this method to deny the request.

*/

public abstract void deny();

} ``` 进一步看出其权限定义是隶属于android.webkit,而且定义出了4个RESOURCE_VIDEO_CAPTURE,//相机 RESOURCE_AUDIO_CAPTURE,//mic RESOURCE_PROTECTED_MEDIA_ID, RESOURCE_MIDI_SYSEX。 一般常见的h5是权限是前面两个。

录音与麦克风

为什么会将录音麦克风分开?主要是因为app和h5的定义不一样,以及范围不一样。就app来讲采集声音/录制音频文件,只需要麦克风(mic)就可以了。如果h5在直播/会议场景中连麦,请求权限的时候,除了要麦克风权限(android.permission.RECORD_AUDIO)外,还需android.permission.MODIFY_AUDIO_SETTINGS权限,该权限不需要动态申请,但需要添加到AndroidManifest文件中,此时的权限不单是麦克风权限,因此整体叫“录音权限”。 对于h5的录音,app 需要向系统申请两个权限:

android.permission.RECORD_AUDIOandroid.permission.MODIFY_AUDIO_SETTINGS

多看下日志输出就知道需要的权限了。

默许的风险

我们草草以“默许”解决h5的权限,可能面临的问题是合规审核,被通告整改。 其次也不符合api的设计思想和安全机制。使用场景中存在自动被录音或录像的风险。app过度申请权限。

最佳实践

最好的解决办法是: app 在onPermissionRequest被调用的时候,弹框让用户确认为h5授权,接着判断app是否具备对应的权限,如果没有则继续向系统申请,申请响应后再为h5授权,流程稍微复杂一点,但不讲究时机同时也是需要时候获取。默许授权存在问题是过度申请,因为时机不确定而需要优先申请。

参考文章

评论可见,请评论后查看内容,谢谢!!!
 您阅读本篇文章共花了: