一种智能终端悬浮窗权限设置方法与流程

本发明属于智能终端应用领域，涉及一种智能终端悬浮窗权限的设置方法方法。

背景技术：

现有技术中，可以将虚拟返回键，home键，菜单键，各种系统功能的快捷设置集成在智能终端的悬浮窗上，通过悬浮于所有窗口之上的优势，为用户提供方便快捷的操作体验，同时通过悬浮窗实现的虚拟按键功能，替代手机的系统按键的使用，节省手机系统按键被按压的次数，延长系统按键乃至手机的使用寿命。

通过悬浮窗口，可以为用户提供快捷联系人界面，用户通过单手就可以调出常用的联系人信息；也可以提供常用的应用列表，使得用户可以快速的跳转到需要的应用；还可以提供很多系统设置功能，如手电筒，蓝牙开关，wifi，移动网络，调节音量大小，调节屏幕亮度等等。

由于部分Android智能终端机型集成了权限管理软件，默认不给予应用使用悬浮窗权限，使得安装悬浮窗应用后，点击运行时无法弹出悬浮窗，甚至出现程序崩溃的情况，从而无法正常使用悬浮窗应用。

目前市面上已知的，默认不给第三方下载程序悬浮窗权限的智能终端系统包括华为EMUI系统(华为厂商开发的软件系统)手机，小米MIUI系统(小米厂商开发的操作系统)的手机，魅族系列手机等，如果在这些智能终端上安装带有悬浮窗的应用，在应用启动时将报错或者崩溃，从而导致无法正常使用应用的功能。对于广大智能终端用户，由于不具备相关专业知识，往往存在希望开启但又不知如何开启的困惑。因此亟待一种智能终端悬浮窗权限设置方法，使得用户能够开启悬浮窗的权限，且开启悬浮窗权限并不会引起手机安全方面的问题，也不会导致手机变慢或卡顿。

技术实现要素：

为克服上述现有技术的不足，本发明提供了一种智能终端悬浮窗权限设置方法，其特征在于：获取智能终端系统自带的信息，判断其是否为特定的机型；如果是，则判断其是否具有使用悬浮窗的权限，如果没有使用悬浮窗的权限，则在程序运行时自动跳转到权限开启界面，然后在权限开启界面上弹出一个半透明的全屏引导框，引导用户开启此应用的悬浮窗使用权限。

根据本发明的一个优选实施方式，事先将特定机型系统版本划分类别，当使用悬浮窗的权限没有使用权限时，则会根据之前的机型和版本的分类，跳转到相应的权限开启界面。

根据本发明的一个优选实施方式，所述在权限开启界面上弹出一个半透明的全屏引导框，引导用户开启此应用的悬浮窗使用权限进一步包括：半透明的窗口中根据不同的机型的具体情况给予不同的提示信息。

上述说明仅是本发明技术方案的概述，为了能够更清楚了解本发明的技术手段，并可依照说明书的内容予以实施，以下以本发明的较佳实施例并配合附图详细说明如后。

附图说明

图1示出了根据已有发明的一个具体实施方式的引导应用程序跳转的方法流程图；

图2示出了根据本发明一个具体实施方式的悬浮窗按钮示意图；

图3示出了根据本发明一个具体实施方式的权限开启界面示意图；

图4示出了根据本发明一个具体实施方式的悬浮窗权限设置示意图；

图5示出了根据本发明一个具体实施方式的引导用户开启悬浮窗权限的方法流程图；

图6示出了根据本发明一个具体实施方式的特定机型及版本的检测流程图；

图7示出了根据本发明一个具体实施方式的悬浮窗是否开启的检测流程图。

具体实施方式

为更进一步阐述本发明为达成预定发明目的所采取的技术手段及功效,以下结合附图及较佳实施例，对依据本发明提出的一种智能终端悬浮窗权限设置方法其具体实施方式、特征及其功效，详细说明如后。在下述说明中，不同的“一实施例”或“实施例”指的不一定是同一实施例。此外，一或多个实施例中的特定特征、结构、或特点可由任何合适形式组合。

缩略语和关键术语定义

悬浮窗：触发开启之后，屏幕当中出现的一个虚拟窗口，它可以很大，充满整个屏幕；也可以很小，显示为一个圆形或任意形状的按钮，它可以随意拖动或者出现在屏幕上的任意位置，并且可以悬浮于大多数的应用界面之上。

Android：中文名称为安卓，是一种基于Linux的自由及开放源代码的操作系统，主要用于移动设备，如智能手机和平板电脑，由Google公司和开放手机联盟领导及开发。

Handler：Handler是Android中的一个消息分发对象。而消息分发，有赖于消息循环，也就是Looper。在一个线程中，Looper阻塞线程，等待消息构成循环，有了消息，分配到对应的Handler，让它进一步分发处理。

Intent:“意向、打算”的意思。Android中提供了Intent机制来协助应用间的交互与通讯，Intent负责对应用中一次操作的动作、动作涉及数据、附加数据进行描述，Android则根据此Intent的描述，负责找到对应的组件，将Intent传递给调用的组件，并完成组件的调用。Intent不仅可用于应用程序之间，也可用于应用程序内部的Activity/Service之间的交互。因此，Intent在这里起着一个媒体中介的作用，专门提供组件互相调用的相关信息，实现调用者与被调用者之间的解耦。

Context：可以理解为“上下文”：它贯穿整个应用。也可以理解成“运行环境”。它提供了一个应用运行所需要的信息，资源，系统服务等。同样可以理解成“场景”，用户操作和系统交互这一过程就是一个场景，比如Activity之间的切换，服务的启动等都少不了Context。

Activity：是Android四大组件之一，形象的说就是一个容器，在里面可以放置各种控件(按钮，文本，复选框等)，就形成了软件的界面，Activity是可见的，如果不加任何控件的话，那么就像Windows中的空白窗体一样。

如图1所示，提供了一种在当前应用程序界面，接收从当前应用程序界面跳转到另一应用程序的指定界面的跳转请求，并根据所述跳转请求，将所述当前应用程序界面切换到所述另一应用程序的指定界面；确定所述另一应用程序的指定界面是否已在前台显示，若确定所述另一应用程序的指定界面已在前台显示后，则通知操作系统将预先自定义的Toast覆盖在所述另一应用程序的指定界面上；在所述Toast覆盖在所述另一应用程序的指定界面上之后，在所述Toast中播放引导动画以引导用户操作。根据这一具体实施方式，避免了用户在当前界面想要操作另一个界面时，关闭当前界面，从桌面中或者其它菜单位置选择需要操作的另一个应用程序，然后找到需要设置的界面这样一个复杂、费时的操作过程。但由于Android系统中的Toast播放的时长限制，往往是几秒之内，因此无法在这个时间段内提供为用户提供足够多的信息。另外，采用动画的方式进行引导将耗费较多的系统资源，增大程序出错的风险。

现有技术主要有四个缺点，一是所要启动的另一应用程序往往是一些比较特定的权限设置界面，只有开启了这个权限开关后程序才能继续往下运行，而这样的权限管理程序也会不断更新，拥有不同的版本，对于不同的版本，跳转到的界面路径有可能是不同的，没有给出针对不同的系统版本如何进行处理；且在不同的智能终端上表现形式也有可能不同，调用方法也有不同，当这些不同的条件出现时，如何进行处理并未指出；二是跳转到另一个应用的前提并没有指明，程序是在何种情况下，什么条件下需要跳转的都没有指明。比如，是程序运行于所有设备上时，还是在特定的设备上时。如果应用已经具备了所需要的条件，是否还需要跳转；三是引导中使用Toast的方式，会导致展示信息时间可能不够，因为Toast实际展示只有最多不到4秒的时间；四是使用动画的方式引导用户比较耗费系统资源，并会增加程序复杂度，增大程序出错的风险。

本发明的目的就是在于解决这些问题，采用新方案后，首先可以根据终端自带的系统信息确定出“特定机型”或“特殊机型”，所述“特定机型”或“特殊机型”是指特定的品牌及机器型号，这些品牌的机器型号默认不给第三方下载程序悬浮窗权限。特定机型可事先设置，并可以定期或不定期地进行更新；根据相同机型的不同的软件版本确定不同的权限管理软件版本，根据不同的权限管理软件版本，进而确定权限开关界面所在的路径，这样就能采用不同跳转策略；其次，可以获取到应用程序在此机型上是否具有使用悬浮窗的权限，如果没有权限，需要进行引导开启，如果有，可以不用再引导，直接执行应用的正常功能；最后，我们在确定了应用运行于特定机型上，并查询应用没有获取到悬浮窗权限，将跳转到权限开启界面，并在其上弹出一个全屏半透明的Activity窗口，此窗口中间显示引导性的文字，指明下一步如何进行操作的步骤，引导用户进行开关开启。用户需要参与的步骤只是关闭当前的引导框，然后进入到了权限开启界面，将对应的应用开关开启即可，很方便和省力。

本发明提供了一种智能终端悬浮窗权限设置方法，一种在android智能终端上，利用终端系统自带的信息，判断其是否为特定的机型，如果是，接着判断其是否具有使用悬浮窗的权限，如果没有，则在程序运行时自动跳转到权限开启界面，然后在其上弹出一个半透明的全屏引导框，引导用户开启此应用的悬浮窗使用权限。

图2示例性地示出了黑框中的悬浮窗按钮，它就可以看做一个小的悬浮窗口，通过点击这个“小悬浮窗”，可以打开一个更大的悬浮窗，通过此悬浮窗可以实现一系列的虚拟按键，从而节省系统按键的使用，延长手机的使用寿命。但要使此悬浮窗能够显示，则需要应用具有悬浮窗使用权限才可以，而特定机型的终端预置了权限管理软件，对于悬浮窗权限默认都是关闭的，如果在使用应用时，未事先开启这个权限，则不能使用悬浮窗功能的，程序就会出现崩溃或者点击后无反应等各种不正常的情况。而为了应用的正常使用，我们需要对这些机型做适配，需要提前统计出都有哪些机型，以及这些机型的那些系统版本都预置了权限管理软件，每个权限管理软件的版本是否相同等等。例如小米手机，通常都会集成自己研发的MIUI系统，这个系统会不断进行更新，如对于MIUI6这个版本，它需要跳转到权限开启界面路径和界面的名称与其他版本就不同，它对应的权限开启界面为包名是com.miui.securitycenter(小米的“安全中心”应用程序包名)，类名为com.miui.permcenter.permissions.AppPermissionsEditorActivity的一个界面，而低于MIUI6的版本，又会进一步区分Android的系统版本级别是不是大于等于9，即是不是Android 2.3及以上的系统，对于这样的系统，就需要跳转到包名为android.settings.APPLICATION_DETAILS_SETTINGS的系统详情设置界面；而对于2.3以下的系统，则需要跳转到，包名为com.android.settings，类名为com.android.settings.InstalledAppDetails的应用详情界面，所以不同的机型，并且不同的系统所对应的权限开启界面是完全不同的，需要根据情况进行划分和归类。然后根据机型，版本等特性抽离出共性，再根据共性去引导用户进行权限的开启。

根据本发明的一个具体实施方式，将特定机型系统版本划分类别，在这些机型上启动应用时，将首先检测当前应用是否具有了使用悬浮窗的权限，如果没有使用权限，则会根据之前的机型和版本的分类，跳转到相应的权限开启界面，然后在这个界面上再弹出一个全屏的半透明的窗口，窗口中给出了进一步操作的步骤，步骤信息会根据不同的机型的具体情况给予不同的提示信息。根据本发明的优选实施方式，可以设置简短方式进行提示或是详细方式进行提示。

图3示例性地示出了一种权限开启界面，在其上有一个半透明的全屏引导界面。提醒用户如何进行下一步操作，引导的提示文字为--请找到并激活“显示悬浮窗”选项。当我们点击图中的“我知道了”，或者点击系统的返回键后，就会显示后面的权限开启界面，然后在此界面中找到“显示悬浮窗”，如图4所示，选择“显示悬浮窗”菜单，然后点击“允许”，这样应用就具有了使用悬浮窗权限。

根据本发明的一个具体实施方式，程序启动，检测如果是特定机型，并且没有使用悬浮窗的权限，自动跳转到机型对应权限开启界面，然后弹出一个全屏半透明的引导框，引导用户开启此应用的悬浮窗使用权限；在程序启动时，一般是在程序的首个启动界面中进行处理，我们会在此界面(是一个Activity的类型的窗口界面)的onCreate方法(Activity显示时运行的第一个方法)中进行操作。首先检测出当前机型是否属于特定机型及版本，是否具有使用悬浮窗的权限，如果属于特定机型及版本，并且没有悬浮窗权限，则使用startActivity方法调用出对应这个特定机型的权限开启界面。如，以小米手机，MIUI7系统为例来说明一下方法。小米手机，MIUI7系统的机型，它的悬浮窗权限设置是被一个叫“安全中心”的应用进行管理。如果要调出此应用对应的权限管理界面，需要知道“安全中心”的包名，以及权限管理界面的类名，还有启动这个应用界面的action值(启动Android组件的一种动作值)，最后将本应用的包名信息作为附件值传给系统才可以通过startActivity方法将界面调用出来。

具体方法是，首先创建一个Intent，并且使用miui.intent.action.APP_PERM_EDITOR(一个启动界面的字符串值)作为action值(启动Android组件的一种动作值)来进行创建。然后使用Intent的setClassName方法将包名com.miui.securitycenter(安全中心应用的包名)，类名com.miui.permcenter.permissions.AppPermissionsEditorActivity(安全中心中的一个界面的类名，这个界面用来管理悬浮窗权限)设置给新创建的Intent，然后使用Intent的putExtra方法将"extra_pkgname"作为第一个参数，当前应用包名(可以通过getPackageName()方法获取)作为第二个参数传递给Intent，最后使用startActivity方法启动此Intent，就可以将安全中心的此权限管理界面调用出来。在将界面调出后，通过启动界面新建的Handler对象延迟发送一个N毫秒的消息，比如这个消息叫做TYPE_FLOATWINDOW_MIUI_V6(一个整型常量)，在N毫秒后，如果收到此消息，再使用startActivity方法创建一个全屏半透明的Activity界面，覆盖并显示在之前的权限管理开启界面之上。在创建引导界面时在其显眼的位置设置一些引导性的文字，如小米MIUI7手机就会显示---请找到并激活“显示悬浮窗”选项，这条引导信息。用户在点击了“我知道了”或者按了系统的返回键后，进入到权限开启界面，找到“显示悬浮窗”菜单，然后点击“允许”后，应用就会具有使用悬浮窗的权限了。然后应用将自动往下执行，进入到正常功能运行界面，并将悬浮窗或按钮显示出来(如果应用需要立即显示)。

根据本发明的一个具体实施方式，根据系统提供的品牌名称和自身系统的版本信息，把机型进行归类，判断当前机型属于哪种特定机型。首先使用Build.BRAND(系统预定义的字符串类型的常量，用来表示系统的品牌)常量来判断当前机型是否属于我们要处理的特定机型，如是否是小米，华为，魅族等品牌手机。这些品牌的机型大都预置了管理悬浮窗的软件，并且默认是关闭权限的。如小米的Build.BRAND这个常量，我们通过判断其是否包含“Xiaomi”字样的信息，就可以确定其是否为小米手机了。然后利用java运行时环境，调用Runtime.getRuntime().exec()方法启动一个adb shell指令getprop，并且传递给其MIUI系统的属性ro.miui.ui.version.name，通过读取这个shell指令的输出流返回值，就可以得到MIUI对应的版本号了。如MIUI 7对应的版本号为“V7”。这样有了机型信息，并且知道了对应系统版本，就可以针对不同的机型，不同的版本进行相应处理了。

根据本发明的一个具体实施方式，根据不同的Android系统版本，使用不同的方式来进行判断应用有没有使用悬浮窗的权限。

首先根据系统整型常量Build.VERSION.SDK_INT判断当前系统的版本号是否大于等于19，即是否是Android4.4.2及以上的版本(19代表Android4.4.2系统)，这里有两个处理分支：

其一，如果是Android4.4.2以下的系统；首先，通过当前Context得到包管理器PackageManager，然后调用其getApplicationInfo方法，得到当前应用的信息，然后判断其flags属性与0x8000进行逻辑与的结果是不是等于0x8000，即flags标志的第17位是不是1，如果是1，说明它有使用悬浮窗的权限，否则就没有；

其二，如果是Android4.4.2及以上的系统；首先通过Context的getSystemService方法，传递appops参数得到AppOpsManager应用程序使用情况管理器对象，然后通过java反射程序使用情况管理器对象的方法checkOp，判断其的返回值是否为MODE_ALLOWED(系统预置的整型常量，值为0),如果相等，说明应用具有了使用悬浮窗的权限，否则没有此权限。

为实现上述目的，本发明提供了详细的根据特定机型及版本来弹出不同类别的权限管理界面，以及全屏半透明的引导框，引导用户开启悬浮窗权限的引导流程，如示例图5，其实现的步骤如下：

S501：应用程序启动：启动应用程序，应用是带有悬浮窗功能的应用程序。

S502：进入程序的启动界面：带有悬浮窗功能的应用往往需要程序一启动就显示悬浮窗，所以需要在启动应用的第一个界面时就要进行权限的判断。当然如果启动应用后不需要立即启动悬浮窗，也可以将判断权限和引导流程放到需要的时候再调用。

S503：创建一个Handler对象用于处理消息：引导流程需要进行消息处理，所以预先定义一个Handler对象，使用new Handler()方式创建一个Handler对象。

S504：在启动界面的onCreate()方法中开始处理引导流程：启动界面是一个Activity类型的窗口界面，onCreate()方法是界面生成时第一个要调用的方法，所以需要将引导流程放到此方法中执行最合适。

S505：进入特定机型及版本检测流程：进入到特定机型及版本检测流程中判断当前的机型是否满足需要特定处理的条件。

S506：判断当前机型及版本是否需要特定处理：通过特定机型及版本检测流程的返回值，确定当前机型及版本是否需要继续进行引导，还是直接跳过引导流程。如果判断结果为否，则执行S5507；如果判断结果为是，则执行S5508；

S507：不属于特定机型及版本：如果经过检测当前机型不属于特定机型及版本，那就跳过引导流程，程序执行正常的启动流程。继续执行S507；

S508：进入悬浮窗是否开启检测流程：进入到悬浮窗是否开启检测流程，检测当前的悬浮窗权限是否开启了。

S509：判断悬浮窗权限是否开启：根据权限检测流程的返回值，判断当前悬浮窗权限是否开启了，如果已经开启，跳过引导流程，如果未开启，则进入引导流程。如果判断为是，则执行S5010；如果判断为否，则执行S5011；

S5010：悬浮窗权限已经开启：如果权限检测流程返回true，说明悬浮窗权限已经开启，那就跳过引导流程，程序执行正常的启动流程。继续执行S5021；

S5011：根据特定机型及版本进行分类，使用不同的启动参数来启动引导流程：悬浮窗权限未开启，并且属于需要特定处理的机型及版本，那就根据机型及版本进行分类，不同类别的情况使用不同的引导处理流程。

S5012：由不同的分类信息构造合适的Intent，使用Context的startActivity方法先启动权限管理窗口：不同的分类信息指的是需要跳转到的权限管理界面的类名以及包名不同，并且有的权限开启界面还要传递当前的包名信息，或者带有其他不同参数，总之跳转的界面不同需要构造的Intent就不同，最后使用Context的startActivity方法启动权限管理窗口。如以小米手机，MIUI7系统为例来说明一下方法。小米手机，MIUI7系统的机型，它的悬浮窗权限设置是被一个叫“安全中心”的应用进行管理。如果要调出此应用对应的权限管理界面，需要知道“安全中心”的包名，以及权限管理界面的类名，还有启动这个应用界面的action值(启动Android组件的一种动作值)，最后将本应用的包名信息作为附件值传给系统才可以通过startActivity方法将界面调用出来。具体方法是，首先创建一个Intent，并且使用miui.intent.action.APP_PERM_EDITOR(一个启动界面的字符串值)作为action值(启动Android组件的一种动作值)来进行创建。然后使用Intent的setClassName方法将包名com.miui.securitycenter(安全中心应用的包名)，类名com.miui.permcenter.permissions.AppPermissionsEditorActivity(安全中心中的一个界面的类名，这个界面用来管理悬浮窗权限)设置给新创建的Intent，然后使用Intent的putExtra方法将"extra_pkgname"作为第一个参数，当前应用包名(可以通过getPackageName()方法获取)作为第二个参数传递给Intent，最后使用startActivity方法启动此Intent，就可以将安全中心的此权限管理界面调用出来。

S5013：判断启动过程有无异常发生：在使用Context的startActivity方法启动权限管理窗口时需要调用java的try--catch机制对执行情况进行监控，如果有异常抛出，就需要进行异常情况的处理，否则程序有可能出现崩溃情况。如果判断为有异常发生，则执行S5014；如果没有异常发生，则执行S5015；

S5014：构造一个更安全的Intent，确保startActivity方法执行后能够跳转过去：如果抛出异常，说明需要跳转到Activity窗口不存在或者权限有问题，或者参数构造的不对，这种情况是很有可能发生的，此时需要对捕获的异常进行处理。通过构造一个大众化的，确保能够跳转过去的Intent对象，然后使用startActivity方法启动这个窗口。比如，普通的设置界面，大多数的机型基本都有这个界面。继续执行S5015；

S5015：调用创建好的Handler对象，并延迟N毫秒发送一个针对此机型及版本的消息：调用之前创建的Handler对象，使用其sendEmptyMessageDelayed方法发送一个针对此机型及版本的消息，此消息是针对此机型及版本定义好的适配消息，只针对此机型及版本作处理。延迟N毫秒发送的目的是确保之前调用startActivity方法启动权限管理界面的流程能够执行完毕，将权限管理界面调用出来。

S5016：Handler收到消息后，创建一个全屏半透明的Activity窗口作为引导窗口，并将消息传递给此窗口：Handler不仅将消息发送给消息队列，完成消息分发，同时它会将消息从消息队列中取出，进行处理。Handler从消息队列取出消息后，根据消息类型，创建一个全屏半透明的Activity窗口，并显示在权限管理窗口之上，如图3所示，同时将消息一并传递给此窗口，此窗口作为引导窗口。

S5017：然后调用finish()方法将当前启动窗口结束，等待权限开启的结果：启动引导窗口后，调用自身的finish()方法将当前启动窗口结束掉，等待权限开启的结果。

S5018：引导窗口根据传递来的参数，确定显示的引导内容，并在此界面显示一个确认按钮：引导窗口显示时，会根据传递来的消息，来显示引导内容，不同的消息对应不同的显示内容，内容主要是下一步操作的详细步骤，下一步操作简单，步骤就很精简；如果下一步操作的复杂，则步骤就会相对详细一些。此引导界面还会显示一个确认按钮，用户点击后可以关闭此引导界面。

S5019：用户点击了确认按钮或者系统返回键，退出引导界面，进入到后面的权限开启界面，用户进行操作，并退出此界面：如果用户查看过了引导界面，他可以通过点击确认按钮或者系统的返回键，来关闭当前的引导界面，然后进入到后面的权限开启界面。最后用户进行下一步操作，打开菜单，启动悬浮窗按钮权限或者退出。

S5020：判断用户是否开启了悬浮窗权限：判读用户是否开启了悬浮窗权限，如果开启则进入正常的启动流程；如果没有开启，用户重新启动应用后，需要重新开始检测和引导用户进行开启权限。如果判断结果为否，则返回S501；如果判断结果为是，则执行S5022；

S5021：程序执行正常启动流程：应用真正开启了悬浮窗权限后，才能执行正常启动流程。

S5022：应用进入待机状态：如果应用获取到权限，并且执行了正常的启动流程，将进入待机状态，此时用户可以使用悬浮窗功能了。

以上是属于特定机型及版本，并且未获取悬浮窗权限时引导用户开启权限的处理流程，图6示出了特定机型及版本的检测流程，详细的步骤如下所示，

S601：进入特定机型及版本检测流程：进入特定机型及版本检测流程，需要对机型和机型所属的版本等信息进行判断。此类情况说明此机型的机器安装了带有悬浮窗权限管理的软件，并且默认是关闭权限的，需要对其进行特定处理。

S602：获取机型的品牌信息：首先通过系统自带的字符串常量Build.BRAND来进行判断，这个常量代表了机型的品牌信息。如小米手机的这个值包含"Xiaomi"字样的字符串，如果出现此字符串，就代表当前机型为小米手机。

S603：判断此品牌是否为需要特定处理的机型：通过得到的字符串常量Build.BRAND来判断当前属于哪一类特定的机型，如是小米，还是华为，还是魅族，或者三星等。如果判断为否，则执行S606；如果判断为否，则执行S604；

S604：判断当前机型的版本信息是否是需要特定处理的版本：通过执行一个getprop命令的shell指令，并且传递给它当前系统的一个属性值名称，如小米的属性值名称为ro.miui.ui.version.name，就会得到对应系统的版本号，根据此版本号就可以区分此机型的不同版本，如，小米的MIUI6系列对应的值为V6，MIUI7系列对应的值为V7，V6和V7可以分别作为一种类型进行处理。如果判断为否，则执行S606；如果判断为是，则执行S605；

S605：结束判断，确定当前为特定机型及版本，需要特定处理，返回true：如果当前机型属于特定机型，以及特定机型中的某个需要处理的版本，返回true。继续执行607；

S606：当前不需特定处理，跳出检测，返回false：经过检测当前不属于特定机型及版本，不需特定处理，跳出检测，返回false。继续执行S607；

S607：结束特定机型及版本检测流程：结束特定机型及版本检测流程，将返回值传递给引导流程。

图7示出了根据本发明具体实施方式的悬浮窗是否开启的检测流程，具体步骤如下，

S701：进入悬浮窗是否开启检测流程：进入悬浮窗是否开启检测流程，需要对当前的应用进行检测，判断其是否已经获取到了悬浮窗使用权。

S702：获取当前系统的版本号整型值Build.VERSION.SDK_INT：首先获取系统的版本号整型值--Build.VERSION.SDK_INT，这是一个整型的常量值，代表系统的版本号。

S703：判断Build.VERSION.SDK_INT是否大于等于19：判断Build.VERSION.SDK_INT是否大于等于19，19表示当前的系统版本为Android4.4.2，即判断当前系统版本是否为Android4.4.2以上的系统。如果判断结果为是，则执行S709；如果为否，则执行S704；

S704：根据当前Context的getPackageManager()方法得到系统的包管理器PackageManager对象：如果Build.VERSION.SDK_INT小于19，说明当前为Android4.4.2以下的系统。那么根据当前Context的getPackageManager()方法获取到系统的包管理器PackageManager对象。

S705：由当前应用程序的包名，调用PackageManager对象的getApplicationInfo()方法，得到当前应用程序的详情信息ApplicationInfo：获得PackageManager对象后，调用其getApplicationInfo()方法，并将当前的包名作为方法的第一个参数，执行后得到当前应用程序的详情信息ApplicationInfo。

S706：ApplicationInfo中的属性flags和0x8000进行逻辑与操作：返回的ApplicationInfo类型的变量是一个类对象，包含有当前应用的详细信息，如包名，类名，主题，显示的lebel等信息，其中有一个flags属性，是一个32位的整型值。它的每一位都表示当前Activity窗口有不同的特性，其中第27位，如果为1则表示有悬浮窗权限；为0，则表示没有权限，所以需要与0x8000(1向左移动27位后的值，即1<<27)进行逻辑与操作，检查返回值是否为0x8000。

S707：判断以上过程是否有异常发生：以上步骤S704-S706过程很可能会出现异常情况，需要使用try--catch进行包装，如果一旦抛出异常，直接返回false，并退出。如果有异常发生，则执行S7013，如果没有异常发生，则执行S708；

S708：判断结果是否等于0x8000：如果以上过程没有异常情况发生，则判断属性flags和0x8000进行逻辑与的结果，如果等于0x8000，说明第27位为1，表示有权限，否则为无权限。如果判断结果为否，则执行S7013；如果判断结果为是，则执行S7014；

S709：根据当前Context的getSystemService()方法以及参数"appops"得到系统的应用程序使用情况管理器AppOpsManager对象：如果大于等于19，说明当前为Android4.4.2及以上的系统。需要使用不同于Android4.4.2以下系统的判断方法进行判断。首先将"appops"字符串传递给Context的getSystemService()方法，得到系统的应用程序使用情况管理器AppOpsManager对象。继续执行S7010；

S7010：利用反射技术得到AppOpsManager对象中的checkOp方法，并传递给它当前应用的uid和包名，调用执行此方法：然后利用反射技术得到AppOpsManager对象中的checkOp方法，并传递给它当前应用的uid(当前应用的用户ID)和包名，uid可以通过Binder(Android的一种特定类型，用来实现不同程序的通讯)的静态类方法getCallingUid()方法得到，包名可以通过Context的getPackageName()方法得到。执行checkOp方法后，将得到一个整型返回值，返回值表示是否有权限。继续执行S7011；

S7011：判断以上过程是否有异常发生：以上步骤S7010过程很可能会出现异常情况，需要使用try--catch进行包装，如果一旦抛出异常，直接返回false，并退出。如果判断有异常发生，则执行S7013；如果判断无异常发生，则执行S7012；

S7012：判断执行的结果是否等于MODE_ALLOWED(0)：判断checkOp方法的执行结果是否等于MODE_ALLOWED，这个值是系统预定义的一个整型常量，表示整型值为0。如果等于此值表示当前应用具有了悬浮窗权限，否则没有。如果判断结果为是，则执行S7014；

S7013：返回false，表示当前应用无权限：如果经过检测应用没有悬浮窗使用权限，则返回false。继续执行S7015；

S7014：返回true，表示当前应用有权限：如果经过检测应用具有悬浮窗使用权限，则返回true。继续执行S7015

S7015：退出悬浮窗是否开启检测流程：退出悬浮窗是否开启检测流程，并将检测的返回值传递给引导流程。

通过以上图5，6，7所示的具体实施方式，实现了在特定机型上，启动具有悬浮窗功能的应用时，通过判读是否为特定机型及版本，以及是否具有悬浮窗使用权限等检测结果，自动引导用户进行悬浮窗权限开启的方法，从而为具有悬浮窗功能的应用在特定机型上能够顺利运行提供了一套解决方案。

针对有悬浮窗功能的应用来说，如果所在的智能终端默认安装了限制应用使用悬浮窗权限的软件时，应用是无法正常使用的，要不报错，要不就是崩溃或者无响应。只有在赋予了应用悬浮窗使用权限后，它才能正常的运行。

首先，确定哪些机型预置了悬浮窗权限管理软件，并且是默认不给予应用权限的预置软件，确保应用在这些机型上不出现崩溃或无响应；其次，自动引导用户开启悬浮窗权限的，全程由程序控制，用户只需要点击确认键和开关即可，不需用户过多的选择页面然后跳转，提高了用户操作的便利性；再次，引导框有如何开启的详细步骤，方便用户操作，增加了权限开启的透明度，方便用户操作；然后，开启悬浮窗权限不会带来安全方面的问题，也不会消耗系统的内存和电量等资源；最后，此功能解决了应用在这些特定机型上无法运行的问题，用户不用自己查找那个软件限制了悬浮窗的权限，从而避免自己去费时费力进行重新设置，解决了用户的实际问题，提高了用户对此应用的用户体验度。

根据本发明的一个具体实施方式，检测智能终端品牌还有其他的实现方法，除了使用Build.BRAND(系统预定义的字符串类型的常量，用来表示系统的品牌)来区分外，还可以使用Build.MODEL(系统预定义的字符串类型常量，用来表示系统品牌的某个产品，通常会带有品牌名称)来进行更细致的区分，当然也可以通过它确认终端的品牌信息。

根据本发明的一个具体实施方式，全屏半透明的引导页窗口使用Activity组件实现的，也可以使用Dialog对话框的方式实现，或者采用自定义View的方式实现。

通过应用本发明在android智能终端上，针对某些限制了悬浮窗使用权限的机型，在程序运行时，自动跳转到权限开启界面，然后弹出一个全屏半透明的引导框，引导用户开启此应用的悬浮窗使用权限；区分特定机型的不同版本需要跳转到的权限开启界面有可能不同，区分特定机型的不同版本分别进行相应的处理；并实现了在android智能终端上，判断应用是否具有了使用悬浮窗的权限。

以上所述，仅是本发明的较佳实施例而已，并非对本发明作任何形式上的限制，虽然本发明已以较佳实施例揭露如上，然而并非用以限定本发明,任何熟悉本专业的技术人员，在不脱离本发明技术方案范围内,当可利用上述揭示的技术内容作出些许更动或修饰为等同变化的等效实施例,但凡是未脱离本发明技术方案的内容，依据本发明的技术实质对以上实施例所作的任何简单修改、等同变化与修饰，均仍属于本发明技术方案的范围内。