Android6.0运行时权限

github传送门

使用方式:

Step1.

allprojects {
    repositories {
        ...
        maven {
            url 'https://jitpack.io'
        }
    }
}

Step2.

implementation 'com.github.qyxghcl:WPermission:v1.0'

Step3.

PermissionManager.getDefault().requestPermission(this
        , new PermissionManager.OnRequestPermissionListener() {
            @Override
            public void onGranted() {
                Toast.makeText(MainActivity.this, "权限通过", Toast.LENGTH_SHORT).show();
            }

            @Override
            public void onDeny(boolean isSystemShow) {
                if (isSystemShow){
                    Toast.makeText(MainActivity.this, "权限被拒绝,但是没有选择不再询问" +
                            ",下次重新请求依旧会有系统弹窗", Toast.LENGTH_SHORT).show();
                }else {
                    Toast.makeText(MainActivity.this, "" +
                            "权限被拒绝,选择不再询问,下次重新请求不会有系统弹窗", Toast.LENGTH_SHORT).show();
                }
            }
        }, Permissions.STORAGE);

运行时权限简介:
Android6.0开始添加了运行时权限,至此,权限可以分为两类:

//分类
运行时权限分类 {
    1.Normal Permissions -> {
           不涉及个人隐私,不需要用户额外授权(例如:访问网络,手机震动等)
      }
         
    2.Dangerous Permissions -> {
          涉及个人隐私,需要用户额外授权(例如:读取sd卡,访问通讯录)
     }
}
因为有了Dangerous Permissions的存在,所以我们需要与用户交互,以获取到这些危险但在一定业务需求下必要的权限

Dangerous Permissions的权限状态(可以分为三类):

//权限状态
Dangerous Permissions {
    1.已授权 -> {
          用户已经授权的权限,即可以直接执行业务逻辑
      }
         
    2.未知授权状态 -> {
          需要展示交互界面,从而确定用户是否愿意给于这项权限
     }

    3.已拒绝 -> {
          用户已经拒绝此项权限,因此,我们的业务无法执行
     }
}

那么,当我们碰到需要危险权限的业务时,就需要知道当前权限是处于什么样的状态,从而决定我们下一步怎么做.

权限状态判定(此处为伪代码):

//listener是请求失败与否的回调,
权限状态判定 (Listener listener){
      //1.如果小于6.0则表示并不需要运行时权限,判定为成功
      if (Build.VERSION.SDK_INT < Build.VERSION_CODES.M) {
              listener.onGranted();
              return;
      }
      
      //2.判定所有请求的权限状态是否均为通过,如果全通过,判定为成功
       if (hasAllPermissions(activity, permissions)) {
            listener.onGranted();
            return;
       }
       
       //3.筛选出所有状态不属于通过的权限
       String[] unPassPermissions = screenOutUnPassedPermissions(activity, permissions);
        //此处为进一步预防检测,如果状态不属于通过的权限数量为0,
        //那么也算作通过,不过经过第二步的判断,一般情况下不会走到这里
        if (unPassPermissions.length == 0) {
            listener.onGranted();
            return;
        }
        
        //此处借助了RxPremission的思想,通过一个fragment去请求权限
        //4.开始对那些不是通过状态的权限进行询问(未知,未通过)
        //开始询问的那一刻即弹出系统的权限请求框
        //注意:  接收回调的结果为用户选择的结果
        //(也就是说,这是接收的选择框选择的结果,已经和步骤1,2,3判定的结果无关了)
       new RequestPermissionActivity(activity).requestPermissions(REQ_PER_CODE, unPassPermissions, new RequestPermissionActivity.Callback() {
            //接收到回调,这里最主要做的事情就是,将未知状态的权限交由用户处理,将其再次划分,则只剩下了通过,未通过两种状态
            @Override
            public void onRequestPermissionResult(int requestCode, @NonNull String[] permissions, @NonNull int[] grantResults) {
                //1.筛选出用户此次选择后被拒绝的权限
                List<String> denied = new ArrayList<>();
                for (int i = 0; i < permissions.length; i++) {
                    String perm = permissions[i];
                    if (grantResults[i] != PackageManager.PERMISSION_GRANTED) {
                        denied.add(perm);
                    }
                }
                //2.被拒绝的权限为0,表示通过
                if (denied.size() == 0) {
                    listener.onGranted();
                    return;
                }
                //此处剩余的都是未通过的权限,
                //shouldShowRequestPermissionRationale(activity, denied)
                //(1)false 代表勾选了不再询问,则需要提示用户去自主开启,即用户此次想执行业务逻辑是不准许的,并且下次请求执行的时候,不会弹出系统的选择框
                //(2)true 代表拒绝,但未勾选不再询问,即用户此次想执行业务逻辑是不准许的,但下次请求执行的时候,仍旧会弹出系统的选择框,让客户选择此次是否给于通过
                Activity weakActivity = mWeakActivity.get();
                if (weakActivity != null) {
                    if (!shouldShowRequestPermissionRationale(weakActivity, denied)) {
                        listener.onDeny(false);
                    }else {
                        listener.onDeny(true);
                    }
                }
            }
        });
}
最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 218,386评论 6 506
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 93,142评论 3 394
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 164,704评论 0 353
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 58,702评论 1 294
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 67,716评论 6 392
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 51,573评论 1 305
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 40,314评论 3 418
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 39,230评论 0 276
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 45,680评论 1 314
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 37,873评论 3 336
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 39,991评论 1 348
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 35,706评论 5 346
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 41,329评论 3 330
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 31,910评论 0 22
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 33,038评论 1 270
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 48,158评论 3 370
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 44,941评论 2 355

推荐阅读更多精彩内容