一种终端设备的root方法、配置方法、终端设备和服务器与流程

本发明涉及智能设备的系统权限管理控制技术，不仅涉及一种提权配置方案反馈方法及装置，还涉及一种提权配置方案匹配方法和装置。

背景技术：

众所周知，Root权限是指Unix类操作系统(包括Linux、Android)的系统管理员权限，类似于Windows(视窗)系统中的Administrator(管理员)权限；Root权限可以访问和修改用户的移动设备中几乎所有的文件(Android系统文件及用户文件，不包括ROM)。但是，由于目前终端设备系统对于Root权限的管理是非常严格的，通常情况下多数应用或程序都不具备Root权限，因此对于某些需要具备Root权限的操作就无法执行，例如安装或卸载应用等操作；同时，此类操作调用进程每次执行相应操作时都需要向系统申请Root权限，但如果此时其他应用进程正在使用Root权限进行相关操作，则此调用进程的Root权限申请便无法成功；更甚者，如果用户在系统中设置了禁用Root权限的操作，则相关调用进程便无法进行相关操作。

用户一般都想获得自身终端设备的更广泛的控制权，有鉴于此，业内提供了多种多样的提权方案用于获取Android系统的Root权限，实现用户权限提升，达致全面控制操作系统的目的。这些提权方案，依提权后权限作用的生命周期来看，包括永久Root权限和临时Root权限，顾名思义，永久Root权限情况下，应用程序一经Root授权，以后可不必再进行Root提权；而临时Root权限情况下，权限作用的生命周期只是操作系统的一次从开机到关机的过程，下次开机依然需要进行Root。

无论采用何种Root方式，提权的基本原理均是通过向系统植入用于接收权限请求的su，再结合SuperUser.apk应用程序实现人机交互，通过su与SuperUser.apk在运行时的相互配合，来实现有效的权限管理。但是，由于终 端设备设备的Android版本号、内核版本号、CPU型号、机型等信息的不同，导致这些不同的原因可能是在系统OTA或者系统升级，进一步往往导致su模块甚至SuperUser的代码、参数甚至原理等也必须做出适应性改变才能实现Root提权，因此，同一种型号的手机因其内核版本号或者系统版本号的不同，

也可能需要不同的Root方案。此类Root方案，实际上便是适应终端设备设备的上述参数的变化而定制的用于对该终端设备获取Root权限以试图实现提权的配置方案。这些配置方案可以是在Root方案所需的文件的基础上，进一步结合相关运行参数配置而得，也可以是直接包含所述方案文件的指向信息如其URL或文件名，不管配置方案的实现形式如何，只要该配置方案能够被使用它的程序正确解析并使用即可。利用好这些配置方案，便能更高效地实现系统提权。

目前市面上推出多种一键Root应用程序，一般安装于个人电脑上，通过USB线与手机建立连接，从云端下载与该手机相适应的配置方案，也即相应的用于实现获取Root权限的方案，强行对该手机进行获取Root的操作，以期获得成功。然而，这种传统的获取Root权限的方式，其成功率较低，非常低效，究其原因在于其所获得的配置方案未经技术识别，手机端获得的配置方案的匹配成功率较低。

技术实现要素：

本发明的目的在于解决上述问题而提供一种终端设备的root方法，该方法包括：获取终端设备的特征信息；基于所述特征信息向服务器发送配置方案获取请求；从服务器获取与所述特征信息相匹配的配置方案，所述配置方案包含用于获取root权限的配置方案；终端设备执行所述配置方案，以获取root权限。

进一步的，所述步骤：从服务器获取与所述特征信息相匹配的配置方案，具体为：从服务器获取与述特征信息相匹配的多个配置方案，所述多个配置方案具有推荐顺序；所述步骤：终端设备执行所述配置方案，以获取root权限，具体为：终端设备按照所述推荐顺序执行配置方案，以获取root权限。

进一步的，该方法还包括：终端设备每执行完一个配置方案后，确定是否成功获取root权限；如果成功获取root权限，则停止执行下一个配置方案。

进一步的，该方法还包括：采集表达终端设备执行所述配置方案后是否成功获取root权限的反馈数据，并将所述反馈数据上报服务器。

本发明还提供了一种终端设备，该终端设备包括：特征信息获取单元，用于获取终端设备的特征信息；

发送单元，用于基于所述特征信息向服务器发送配置方案获取请求；接收单元，用于从服务器获取与所述特征信息相匹配的配置方案，所述配置方案包含用于获取root权限的配置方案；执行单元，用于执行所述配置方案，以获取root权限。

进一步的，该接收单元用于从服务器获取与述特征信息相匹配的多个配置方案，所述多个配置方案具有推荐顺序，所述执行单元按照所述推荐顺序执行所述配置方案，以获取root权限。

进一步的，该终端设备包括：Root权限垂询单元，用于在执行一个配置方案后，查询所述终端设备是否成功获取root权限，如果成功获取root权限，则通知所述执行单元停止执行下一个配置方案。

进一步的，该终端设备包括：

执行反馈单元，用于根据所述Root权限垂询单元的查询结果，记录配置成功的配置方案以及配置失败的配置方案，并将配置方案配置成功与失败的信息发送到服务器。

本发明还提供了一种配置方法，包括：获取包含终端设备的特征信息的请求；依据所述特征信息查找包含用于获取Root权限的配置方案；依据为所述配置方案所保存的历史使用数据对查找到的配置方案进行排序，并形成推荐表，所述推荐表包含查找到的配置方案的内容信息以及查找到的配置方案的排序信息；响应与所述请求推送所述推荐表。

进一步的，所述历史使用数据为终端设备执行所述配置方案的执行结果的 历史记录。

本发明还提供了一种服务器，包括获取单元，用于获取包含终端设备的特征信息的请求；查找单元，被配置为依据所述特征信息查找包含用于获取Root权限的配置方案；排序单元，被配置为依据为保存的历史使用数据对查找到的配置方案进行排序，并形成推荐表，所述推荐表包含查找到的配置方案的内容信息以及查找到的配置方案的排序信息；配置方案推送单元，被配置为响应与所述请求推送所述推荐表。

进一步的，该服务器包括第一存储单元，用于存储配置方案；第二存储单元，用于存储每个配置方案的历史使用数据；学习单元，根据每个配置方案的历史使用数据为所述配置方案计算权重，所述权重作为形成配置方案的推荐列表的因素。

为实现本发明的目的，本发明采取如下技术方案：

相较于现有技术，本发明至少具有如下优点：

1、本发明能够直接获得用于获取Root权限的配置方案，所述配置方案是在基于实际应用的历史数据的基础上进行推荐的，执行所述配置方案直接获取root权限。

2、本发明的历史使用数据，是基于每条配置方案被试Root以后形成的，且关联到终端设备的特征信息，也即机型、系统版本号、内核版本号、CPU型号等数据，因此，利用历史使用数据对云端配置方案进行优选时，可以获得更为精确的优选效果，尤其是在对历史使用数据进行有关成功率和/或权重的统计之后，可以获得更为有效的统计数据，用于配置方案的优选，进一步提高特定终端设备的配置方案的优选效果。

3、本发明通过数据库的方式，通过构造多个数据表来实现配置方案的优选基础，表与表之间通过特征信息、配置方案建立相互关联，而在表中则收集用于实现优选算法的数据，这种方式具有智能可扩展的优点。其中的学习表，利用机型记录表中从请求方发来的原始数据中进行统计，先获得成功率，再在成 功率的基础上，结合一定时间范围统计每个配置方案的总体实施情况，并以此进一步获得该配置方案的权重，由此进一步强化了计算效果，使数据库技术与本发明隐含的算法实现了完美的结合，可以降低服务器的负荷，从而提高服务器的运行效率。

4、本发明的配置方案形成推荐列表被推送到终端设备后，藉由终端设备逐条对其进行有关获取终端设备Root权限的匹配尝试，直至成功获取终端设备的Root权限，完成匹配。基于命中率配置方案已经被优选这一事实，终端设备对终端设备进行配置方案匹配的将大大提高。而且，针对每条已尝试获取Root权限的配置方案，终端设备还能将其是否匹配成功的数据上传到服务器，因此，能够为服务器提供有利于提高配置方案优化效果的基础数据。

5、由于本发明的配置方案，可以灵活设置为包含方案文件或者包含方案文件的指向信息，因此，既可以将用于实施Root提权的方案文件如su、SuperUser.apk等存储于云端服务器，也可以存储于发起请求的终端设备(并不一定是被Root的终端设备)，由此，为本领域提供了多种实现本发明的实施方案，具有高度的灵活性，便于实现。概括而言，实施本发明能够更为高效地获得用于获取终端设备的Root权限的更为有效配置方案，利用该配置方案有利于进一步提高获取终端设备的Root权限的成功率。本发明附加的方面和优点将在下面的描述中部分给出，这些将从下面的描述中变得明显，或通过本发明的实践了解到。

附图说明

本发明上述的和/或附加的方面和优点从下面结合附图对实施例的描述中将变得明显和容易理解，其中：

图1是利用本发明的整体构思所构造的系统的结构原理图；

图2是本发明的终端装置的结构原理图；

图3是本发明的获取提权配置方案方法的原理示意图；

图4是本发明的提供配置方案的服务器的结构原理图；

图5是本发明的提供提权配置方案方法的原理示意图。

具体实施方式

下面详细描述本发明的实施例，所述实施例的示例在附图中示出，其中自始至终相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。下面通过参考附图描述的实施例是示例性的，仅用于解释本发明，而不能解释为对本发明的限制。

本技术领域技术人员可以理解，除非特意声明，这里使用的单数形式“一”、“一个”、“所述”和“该”也可包括复数形式。应该进一步理解的是，本发明的说明书中使用的措辞“包括”是指存在所述特征、整数、步骤、操作、元件和/或组件，但是并不排除存在或添加一个或多个其他特征、整数、步骤、操作、元件、组件和/或它们的组。应该理解，当我们称元件被“连接”或“耦接”到另一元件时，它可以直接连接或耦接到其他元件，或者也可以存在中间元件。此外，这里使用的“连接”或“耦接”可以包括无线连接或无线耦接。这里使用的措辞“和/或”包括一个或更多个相关联的列出项的全部或任一单元和全部组合。

本技术领域技术人员可以理解，除非另外定义，这里使用的所有术语(包括技术术语和科学术语)，具有与本发明所属领域中的普通技术人员的一般理解相同的意义。还应该理解的是，诸如通用字典中定义的那些术语，应该被理解为具有与现有技术的上下文中的意义一致的意义，并且除非像这里一样被特定定义，否则不会用理想化或过于正式的含义来解释。

本技术领域技术人员可以理解，这里所使用的“终端”、“终端设备”既包括无线信号接收器的设备，其仅具备无发射能力的无线信号接收器的设备，又包括接收和发射硬件的设备，其具有能够在双向通信链路上，执行双向通信的接收和发射硬件的设备。这种设备可以包括：蜂窝或其他通信设备，其具有单线路显示器或多线路显示器或没有多线路显示器的蜂窝或其他通信设备；PCS(Personal Communications Service，个人通信系统)，其可以组合语音、数据处理、传真和/或数据通信能力；PDA(Personal Digital Assistant，个人数字助 理)，其可以包括射频接收器、寻呼机、互联网/内联网访问、网络浏览器、记事本、日历和/或GPS(Global Positioning System，全球定位系统)接收器；常规膝上型和/或掌上型计算机或其他设备，其具有和/或包括射频接收器的常规膝上型和/或掌上型计算机或其他设备。这里所使用的“终端”、“终端设备”可以是便携式、可运输、安装在交通工具(航空、海运和/或陆地)中的，或者适合于和/或配置为在本地运行，和/或以分布形式，运行在地球和/或空间的任何其他位置运行。这里所使用的“终端”、“终端设备”还可以是

通信终端、上网终端、音乐/视频播放终端，例如可以是PDA、MID(Mobile Internet Device，移动互联网设备)和/或具有音乐/视频播放功能的移动电话，也可以是智能电视、机顶盒等设备。

本技术领域技术人员可以理解，这里所使用的服务器、云端、远端网络设备等概念，具有等同效果，其包括但不限于计算机、网络主机、单个网络服务器、多个网络服务器集或多个服务器构成的云。在此，云由基于云计算(Cloud Computing)的大量计算机或网络服务器构成，其中，云计算是分布式计算的一种，由一群松散耦合的计算机集组成的一个超级虚拟计算机。本发明的实施例中，远端网络设备、终端设备与WNS服务器之间可通过任何通信方式实现通信，包括但不限于，基于3GPP、LTE、WIMAX的移动通信、基于TCP/IP、UDP协议的计算机网络通信以及基于蓝牙、红外传输标准的近距无线传输方式。

本领域技术人员应当理解，本发明所称的“应用”、“应用程序”、“应用软件”以及类似表述的概念，是业内技术人员所公知的相同概念，是指由一系列计算机指令及相关数据资源有机构造的适于电子运行的计算机软件。除非特别指定，这种命名本身不受编程语言种类、级别，也不受其赖以运行的操作系统或平台所限制。理所当然地，此类概念也不受任何形式的终端所限制。

为了说明本发明的实施，本发明试图结合计算机程序的静态和动态两个方面进行描述，所谓静态方面，是指程序安装包、文件、数据库等存储于媒介的 存储对象；所谓动态方面，是指被调入内存中执行的动态对象，包括但不局限于进程、线程、所用到的数据等。鉴于计算机软件技术的这些特点，不应将本发明所述及的各个方法、步骤、子步骤、装置、单元、模块等，孤立地理解为仅静态或仅动态的方面，本领域技术人员对此应当知晓。故而，本领域技术人员应当能够依据本发明有关静态的表述而将其对应到动态的进程活动，或者依据本发明有关动态的进程活动对应到其静态的表现形式，建立起静态与动态两方面的必然性关联，以此为基础来理解本发明。

本发明将涉及对Android终端设备的Root提权操作，但也不应局限于Android操作系统，本领域技术人员可以合理预见，诸如Ubuntu、Linux之类的操作系统，只要其权限管理破解机制与Android相同，理论上即可适用本发明所构思的所有方案，因此，本领域技术人员应当知晓此一应用上的变通。

涉及Root提权操作的技术原理，也已在背景技术部分介绍，Root的过程其实就是把su文件放到/system/bin/中，把Superuser.apk放到system/app下面，前者用于监听用户的权限请求并与后者通信，后者主要是在与前者通信的基础上实现人机交互，从而允许用户做出相关指示。理论上，如果su可以实现为可以默认通过所有权限请求，则SuperUser.apk甚至可以舍弃。此外还需要设置/system/bin/su可以让任意用户可运行，使其具有有set uid和set gid的权限，具体可通过在android机器上运行命令：adb shellchmod 4755/system/bin/su便可实现。当然，也不排除本领域技术人员利用操作系统的变化例如其新版本或者经人为修改的出厂设定等，而使得破解机制有所变化。然而，不管这些破解机制如何变化，破解过程中所涉的数据，无非借助代码文件及运行这些文件之类的配置参数形成新的破解方案，本领域技术人员完全可以理解，这些破解方案可以被整合并概括为本发明的用于获取Root权限的方案文件。因此，对本发明方案文件的理解，应理解为涵盖所有能够用于获取具有权限管理功能的操作系统的最高权限的破解手段相关的代码文件及其配置参数，以及这些代码文件和配置参数的整合体，而不仅仅局限于上述以“su”、“SuperUser.apk”命名 或实现的个别文件。任何最小化解释本发明的方案文件的企图均应被视为未超脱本发明的精神实质范围。

如前所述，本发明即将采用的概念“配置方案”，可以仅指前述用于获取Root权限的方案文件，也可以是在Root方案文件的基础上，进一步结合相关运行参数配置而得，还可以是仅包含所述方案文件的指向信息如其URL或文件名的数据，不管配置方案的实现形式如何，只要该配置方案能够被使用它的用于实施Root提权操作的程序(进程)对应正确解析正常使用即可。应当知晓，当配置方案包含的是指向信息的文件名时，应当从本机中获取相应的方案文件，当是指向信息的链接时，应当利用相应的URL从远程下载方案文件适用之。也就是说，配置方案的格式，完全可以由本领域技术人员在进程软件实现时，依照一定的协议进行规定，只要在使用的过程中，遵守同一协议进行正向或反向的对应处理即可。利用好这些配置方案，便能更高效地实现系统提权。

本发明以下即将进行的描述，将基于一个网络环境所构造的系统进行，如图1所示，该系统包括终端设备(客户端)和服务器(云端)，终端设备安装有例如“360一键Root”软件，该软件实现了本发明的一个方面即有关匹配方法和装置的构思，服务器上实现了本发明的与该匹配方法相应的反馈方法和装置的构思，而终端设备则可以是即将被Root的对象如运行Android操作系统的手机。终端设备可以通过标准化的线缆如USB线或者无线连接协议与终端设备建立通信连接，为了顺利与该终端设备进行通信，必然会在终端设备中配置有相应的终端设备驱动程序和adb(Android DebugBridge，安卓调试桥)等相关工具性的程序。这些工具程序完全可以由终端设备上的软件自行检测、下载、安装，也可由用户自行配置，当然，依据Android的系统原理，手机端可能需要提前打开调试模式，以便确保终端设备与终端设备之间的正常通信。诸如此类的先验知识，只为后续说明的便利而提出，不属于影响本发明的实施的范围，恕不赘述。

请参阅图2所示的本发明的获取提权配置方案的终端装置的原理框图，在 终端设备安装例如“360一键Root”软件，从而实现对服务器提供的推荐列表中的配置方案的更有效的利用。该终端装置包括请求单元21、接收单元22、执行单元23以及反馈单元24。

所述的请求单元21，用于发送包含自终端设备采集的特征信息的请求。请求单元21是在终端设备与终端设备建立好前文所称的连接后，用户点击如图5所示的图形用户界面中的“一键ROOT”按键，即触发本请求单元21的执行。用户按键后，该用户界面即切换到所示的效果，在下方显示整个执行过程的状态信息。请求单元21可以从与其连接的终端设备中，获取该终端设备的特征信息，本实施例中，适应上述服务器的实现方案，优选包括机型、CPU型号、系统版本号、内核版本号等专项特征信息，终端设备2软件收信与该终端设备连接的终端设备的特征信息后，将其发送给该服务器。

所述的接收单元22，用于获取响应于该请求的包含用于获取该终端设备的Root权限的配置方案推荐列表20。服务器接收到所述请求单元21的请求后，将按照前述的实现方式，向请求单元21推送推荐列表20。推荐列表20中包含已经由服务器按照权重和/或成功率进行排序的配置方案，接收单元22接收该推荐列表20中，依照与服务器的协议，对配置方案进行解析。例如，如果配置方案包含的是直接的方案文件及其运行时参数，则可作为参数直接调用执行单元23进行处理。又如，如果配置方案包含了方案文件的URL指向信息，接收单元22则应先依照该URL下载相应的方案文件，如果还包含运行时参数，参照前例处理之。再如，如果配置方案包含了已经预存或缓存在本终端设备的指向信息(如文件名)，则也可以相应解析之，调用执行单元23直接进行处理。总之，经过执行单元23的处理，将能够使所述配置方案可以被执行单元23有效利用，从而用于实施提权操作。

所述的执行单元23，被配置为利用至少一条配置方案对所述终端设备实施提权操作。具体而言，所述执行单元23利用配置方案所指向的方案文件，必要时还包括相关运行时配置参数，按照推荐列表20的排列顺序，依次对与 终端设备连接的终端设备进行试Root。表现在软件实现的进程层面，获取终端设备的Root权限的操作步骤，参阅所述，是由终端设备软件加载的adb去实现的。利用adb shell的指令实现提权的实现方案非常普遍，前文已做介绍，此处恕不赘述。执行单元23对一条配置方案的一次试Root，无论成功与否，终端设备软件均能获得试Root的结果数据，这些结果数据将被反馈给服务器。执行单元23在试Root的过程中，按照推荐列表20顺序基于各条解析后的配置方案依次实施对所述终端设备的获取Root权限的提权操作。当然，为了兼顾终端设备的执行效果，如果其中一条配置方案能够成功获取终端设备的Root权限，实现提权，则后续的其余的配置方案将不再被实施提权操作。

所述的反馈单元24，被配置为响应于该推荐列表20而回发已实施的配置方案是否成功提权的数据。如前所述，执行单元23针对每一条已经尝试实施提权操作的配置方案均能获得其是否成功获得终端设备的Root权限的结果数据，本反馈单元24进一步对该结果数据进行格式化，处理成包含所述配置方案、特征信息、成功与否的格式发送给服务器，由服务器利用将这些结果数据记录到机型记录表中以做统计之用。

本发明的匹配装置，显然也隐含了本发明的一种获取提权配置方案的方法，以下结合对该匹配方法做说明，以便以更接近于程序实现的方式介绍本发明的有关利用的实例。

本发明的提权配置方案匹配方法，包括如下步骤：

S21、发送包含自终端设备采集的特征信息的请求。

实施本步骤的前提，是终端设备已经与终端设备建立连接，由此方可获得终端设备的包括机型、CPU型号、系统版本号、内核版本号在内的各种专项的特征信息，将这此特征信息依照与服务器的协议而封装成请求，将该请求发送至云端服务器，以便服务器从相应的监听端口接收该请求。

S22、获取响应于该请求的包含用于获取该终端设备的Root权限的配置方案推荐列表20。

结合前文可知，服务器获取该请求后，将利用自身的实现架构，首先查找到与该些特征信息相对应的一个或多个配置方案，当为多个配置方案时，进一步利用其排序规则，对这些配置方案进行排序，形成排序后的配置方案推荐列表20。将该推荐列表20推送给发送该请求的请求方终端设备。由此，本步骤接收到这一推荐列表20，依照与服务器的协议对该推荐列表20进行解析，获得其中的配置方案及其排序信息，其中的配置方案不管是直接包含方案文件，还是包含方案文件的指向信息，甚至进一步包含方案文件用以执行试Root时的运行时参数等，均能被本接收单元22依照所述协议进行解析，还是后续步骤对配置方案进行直接利用。

S23、利用至少一条配置方案对所述终端设备实施提权操作。

本步骤的实施，默认情况下，是按照所述推荐列表20中配置方案的排序进行的。

通过逐条测试所述配置方案是否可以成功获取终端设备的Root权限来实现对所述配置信息的利用。在这一过程中，只要有一条配置方案能够成功获取终端设备的Root权限，即终止后续其余配置方案的试Root实施。同时，对终端设备实施提权操作的过程，请参阅前文所述，此处从略。

S24、响应于该推荐列表20而回发已实施的配置方案是否成功提权的数据。

每条配置方案被用于实施提权操作是否能成功，均能如前所述格式化成结果数据，将这一结果数据再次发送给云端服务器，可以辅助服务器进行有关配置方案的历史使用数据的采集，从而可以提高云端服务器的配置方案优选效率。至于确定配置方案是否已成功获取系统Root权限，可以通过调用su指令来实现，本领域技术人员知晓此一原理。

可以看出，本发明的提权配置方案匹配方法和装置，在本质上是对本发明在服务器实现的提权配置方案反馈方法和装置在终端设备的相对应的利用。终端设备逐条利用推荐列表中的配置方案进行尝试获取终端设备的Root权限的尝试，直至成功获取。

对于每条已经实施提权操作的配置方案，终端设备将表征其是否成功获取权限的数据，连同终端设备的特征信息与该配置方案打包成结果数据上传给服务器，以便进一步优化服务器的成功率、权重等关键数据。本发明的这两个方面互相配合，可以实现一个更为有效的用于获取终端设备的Root权限的系统。以下再简要说明本发明两方面的相关方法和装置如何相互配合使本发明的所述的系统充分发挥其作用。

具体而言，服务器数据表中的配置方案来源于终端设备所提供的试用配置方案的结果数据，该结果数据将被加工为成功率、权重等数据表中的统计数值，利用该些统计数值可以进一步得出包含排序后的配置方案推荐列表20，而该推荐列表20又提供给终端设备进行利用。对于终端设备的用户而言，首先向服务器请求该推荐列表20，服务器查询配置方案表获得配置方案，然后依据固有规则进行排序，形成优化了的配置方案推荐列表20推送给终端设备。终端设备据该推荐列表20中的各条配置方案对终端设备实施提权操作，直至终端设备提权成功，获取Root权限为止。终端设备对于每条配置方案的试Root结果，均格式化成服务器可以识别的结果数据反馈给服务器进行前述的利用。

利用本发明的系统所实现的终端设备软件，可以进一步结合到其它软件中，或者将其它软件的功能结合到其中。例如，本发明可以在终端设备获取Root权限之后，通过植入基于Root权限运行的服务进程来实现权限请求的管理(类似于所述的SuperUser.apk所实现的功能)和权限管理后的后续指令执行。当本发明实现权限管理的相关服务进程为应用的权限请求开放系统Root权限后，即可由用户程序进程向该服务进程发送指令，例如：执行预置应用的卸载、执行应用程序的安装或卸载、执行应用数据的备份或还原、执行应用程序的启用或禁用等、执行内存或缓存清理功能等。进一步通过在服务进程中构造用于执行这些功能的函数，便可通过服务进程解析用户进程的指令，调用与用户目标功能相应的函数，实现相应的功能，从而解决用户进一步的需求。

综上所述，本发明能够为用户提供更为有效的终端设备系统最高权限获取方案。

进一步，揭示本发明在该系统的云端服务器的具体实现，藉此揭示本发明的一种配置方案提供方法和装置的实施例。本发明的提权配置方案反馈方法及本发明的提权配置方案装置，具有一一对应性，后者是前者的模块化实现，因此，为说明的简化，以下部分文字结合融合了该方法和装置进行说明。本领域技术人员应当理解这种文字上的变通，不应视以下的描述为限制了方法和装置的独立性。

请参阅图4所示的本发明的提供提权配置方案的服务器的原理框图，该图揭示该装置包括获取单元11、查找单元12、排序单元13、推送单元14、采集单元15以及更新单元16。

所述的获取单元11，用于获取包含终端设备的特征信息的请求。所述的终端设备，是指该请求中包含的特征信息所在的终端设备，而不应理解为如图1所示的手机终端。当然，设若在一个实施例中可以在手机终端中安装所述的一键Root安装软件，建立手机终端与云端服务器之间的直连关系，则理论上，可以推知该终端设备是指手机终端。本发明为使叙述的结构更有序，仅以图1所揭示的实施例为准进行说明。

所述的特征信息，包括机型、系统版本号、内核版本号、CPU型号中一种或任意多种。终端设备具有诸多特征信息，并不局限于这里所列的几种。本实施例选定特征信息的标准，是以利用这些信息可以识别终端设备的用于获取其系统的Root权限的配置方案为准。因此，特征信息的选定是非常灵活的，譬如，利用终端设备的SN号和IMEI号识别其出厂时指向的状态(如厂商、产地、销售区域等)，利用终端设备的机型可以识别厂商及其具体系列，利用系统版本号和内核版本号可以识别该终端设备的软件环境，以及利用CPU型号可以进一步判定机型的正确性等。本发明重点优选机型、系统版本号、内核 版本号以及CPU型号等专项，主要是考虑到利用这几种型号中的一种或多种，便可在某种范围内确定其终端设备所使用的ROM(即其除引导程序之外的整个系统软件环境)，据此可以选择相应的用于获取Root权限的方案文件。以上专项通常会记载在Android系统中，从系统的设置页面可以看到相关信息，也可以借助本发明的软件用指令直接读取。实施本发明时，所采用的专项数目越多，理论上确定所述方案文件的范围就越小，效果便越精确，计算量也就越少。例如，如果仅以手机的机型来选择方案文件，则由于该手机可能经过系统升级，导致系统版本号和内核版本号都发生了变化，刚好升级后的Root权限的破解方式与升级前不一致，这种情况下，仅以机型选择出大量的方案文件，其中绝大部分或者全部可能是无效的，无论对于终端设备还是云端服务器，其计算量均是较大的。如果选中以上三个(例如机型、系统版本号及CPU)或者四个专项，则其指向的方案文件便更精确，方案文件数量越少，则计算量也就越低，运行效率就更高。当然，也便会对软件实现提出更多细节要求。

对本发明的查找单元12与排序单元13的进一步揭示，需要结合本发明在云端服务器中所构建的数据库来进行，故以下通过一个具体实例先对本发明所实现的数据库10结构进行说明。

本发明在一个数据库10中构建有三个数据表，分别是配置方案表、学习表，以及机型记录表。所述配置方案表的结构请参阅下方表1所示：

机型系统版本号CPU型号内核版本号配置方案

Note 3 4.0.4 骁龙800 3.0.3-abc URL 1

Note 3 4.2.0 骁龙800 3.1.0-xyz URL 2

Xshot 710 4.3 骁龙801 四核3.04-pert URL 3

Note 3 4.3 骁龙800 3.1.0-xyz URL 3

表1主要用于示出配置方案表的表结构，需要说明的是，所述配置方案虽然以URL的形式示出其存储内容，但本领域技术人员应当理解，如果配置方案包括多个并列的数据域，也可以为其设置相应个数的字段来横向扩展配置方 案表。这样的变通属于数据库10的公知技术，恕不赘述。表1还可以根据实际需要附加其它有利于提高程序实现效率的字段，而不应受本实施例的限制。

下方表2是本发明的学习表：

配置方案权重

URL 1 50

URL 2 70

URL 3 90

学习表中仅示出本发明最为关注的两个字段，即配置方案以及权重，同理，本领域技术人员可以为此附加其它可以优化程序效率的相关字段。其中的权重，数值越高，其重要性也就越高，反之则越低。权重的计算依据是来源于机型记录表。

以下表3揭示本实施例的机型记录表的表结构：

配置方案机型成功次数失败次数成功率

URL 1 Note 3 3 7 30％

URL 2 Note 3 6 4 60％

URL 3 Xshot 710 7 3 70％

URL 3 Note 3 5 5 50％

机型记录表，主要是映射出特定配置方案在某种机型上进行过Root尝试的成功次数与失败次数，并将这些原始的历史使用数值采集并记录到该表中，且统计每条配置方案对于某个机型的历史尝试的成功率。诚然，在其他实施例中，本领域技术人员为了追求精确效果，还可以为该表增加诸如CPU型号、系统版本号等字段，使得每条记录所记载的信息更加细化，但是，本实施例相对于其他变化实施例，体现了系统运算量、简洁性与精确性的更优的平衡效果。

如前所述，学习表中的权重是由机型记录表的成功率得出的，这是对统计学的应用。利用终端设备的结果数据统计出机型记录表中的成功率，以及利用机型记录表中的成功率数据统计出学习表中的权重数值并相应更新学习表的权重数值的过程，可由本发明附加的更新单元16实现。作为第一统计数值， 机型记录表中的成功率，可以依据特定配置方案与特定机型为依据，直接计算它们所在的记录的成功次数相对于总尝试次数的百分比而得出。机型记录表的数据是由云端不断采集用户产生的尝试Root的数据而记录生成的，

因此，所述的权重，可以依据一定时间内例如一周内，利用简单算法，定期对所述的机型记录表中的数据进行加工而得出，作为第二统计数值使用。具体例如前述各表中的数据所揭示，配置方案URL 3由于在机型记录表中对不同机器分别产生70％、50％的成功率，因此，赋予较高的权重90，而URL 2仅在一种机型上取得过60％的成功率，因此，可赋予其70的权重，URL 1由于其成功率最低而赋予其50的权重。依据机型记录表统计学习表的权重的具体算法，可以由本领域技术人员灵活设定，例如，可以设定当同一配置方案适用于一个机型时，其权重值为基数100与其成功率的乘积，当其同时适用于第二个机型时，则其权重提升20个单位，以此类推。当然，以上仅为说明示例，有关算法的描述数据与前述各表的数据不需对应，实现权重计算的具体算法不应构成对本发明的限制。

相信通过揭示本实施例运用数据库10技术实现的配置方案表、学习表以及机型记录表，便可领略本发明的实现思路的概貌。以下再结合各具体单元进行更详细的说明。

所述的查找单元12，被配置为依据所述特征信息查找包含用于获取Root权限的配置方案。在本单元中，由获取单元11接收的特征信息请求被解析后，便可获得其中的具体专项，例如结合表1，可以获得其中的机型、CPU型号、系统版本号、内核版本号等专项的特征信息。利用这些特征信息在表1中进行数据库10查找，便可获得相应的配置方案。为说明的便利，本实施例中，设若只以特征信息中包含的机型“Note 3”为关键词进行检索，由此便可检索到一个配置方案列表如表4所示：

序号配置方案

1 URL 1

2 URL 2

3 URL 3

请注意，其中URL3既适用于机型Note 3也适用于机型XShot 710，但在本次查找过程中，由于仅以机型进行查找，因此查找时本不会涉及XShot 710相关的记录。本发明中，将上述配置方案列表发送给发起请求的终端设备之前，将经排序优化。

所述的排序单元13，即用于对前述查找单元12得出的配置方案列表进行排序，排序的依据即是前述的历史使用数据，排序后形成即将推送给请求方的包含查找到的配置方案的推荐列表。

对此处所称的历史使用数据的利用，包含三个层次，第一个层次是机型记录表中的原始数据，即每条配置方案在每种机型上的尝试成功与否所得的有关成功次数、失败次数的初步统计数据，这些原始数据可以通过本发明的采集单元15向终端设备采集而得，当然也可以人工添加和修改，特别是在初次提供表数据需要赋予部分初始值或者测试时，可以提供部分人工原始数据。第二个层次即是对前述的第一统计数值的利用，也就是说，通过对每条配置方案在相同机型情况下的成功次数和失败次数加总，以成功次数与总尝试次数之百分比作为成功率，将成功率视为历史使用数据之一，用做本发明排序的基础。第三个层次是对前述第二统计数值的利用，具体而言，是在一定时间范围内通过进一步统计所述的成功率，来获得每个方案的权重数值。本发明依赖于这三个层次上的历史使用数据，但在具体程序实现排序时，则具体以第二、第三层次的历史使用数据为基础，即以所述第一统计数值所指的成功率和第二统计数值所指的权重为基础进行排序。这一思路将体现为本发明的排序单元13的三个实施例，请参阅以下进一步的说明。

本发明的排序单元13的第一实施例中，可以直接依赖于所述机型记录表中的成功率，对查找单元12所获得的配置方案列表中的各条配置方案进行排序，获得如下表5：

序号配置方案

1 URL 2

2 URL 3

3 URL 1

本发明的排序单元13的第二实施例中，可以直接依赖于所述机型记录表中的权重，对查找单元12所获得的配置方案列表中的各条配置方案进行排序，获得如下表6：

序号配置方案

1 URL 3

2 URL 2

3 URL 1

在本发明的排序单元13的第三实施例中，可以同时依据权重和成功率进行排序，例如，先以权重排序获得表6所示的结果，如果遇到权重相值的数值，则可以进一步利用机型记录表中的成功率对具有相同权重的配置方案进行二次排序。由于上述各表中未给出权重相同的配置方案示例，故实施本实施例而获得的配置方案列表也将如表6所示。

排序单元13对查找到的配置方案列表进行排序后获得的结果，即为本发明的用于发送给发起请求的终端设备的配置方案推荐列表。

所述的推送单元14，被配置为响应于该请求而推送包含排序后的配置方案的推荐列表。这里所称的被响应的请求，是指发起包含特征信息的请求，因此，响应于该请求进行的推送，也即响应本发明示例的系统中的终端设备进行的推送，以作为针对该请求的应答。推送单元14的目的在于将排序单元13处理获得的最终的配置方案推荐列表发送给终端设备，以便终端设备获取该推荐列表后，可以将该推荐列表进行解析，提取其所包含的配置方案的方案文件，以此对与该终端设备连接的终端设备实施Root提权操作。终端设备获得的推荐列表是经过排序的，有更强的针对性，因此，获得Root权限的成功率理论上将得以提高。此外，如果本发明的查找单元12并未找到有效的可用于Root 的配置方案时，也可由该推送单元14直接向发起请求的终端设备返回表征无配置方案的应答内容。

前文述及，所述的机型记录表的来源方式有两种，其一是可以人工添加，其二是采集终端设备的数据。为适应后一种情况，本发明进一步通过提供采集单元15来辅以实现。

所述的采集单元15，用于采集并保存表征被推送后的所述推荐列表所包含的配置方案是否成功获取Root权限的结果数据，将该结果数据作为所述历史使用数据。

具体而言，本实施例中，终端设备上的一键Root软件在获取推荐列表并以其中的配置方案对与其连接的终端设备8试Root的过程中，如果以一条配置方案所指向的方案文件(必要时包括相关运行参数)，通过调用adb指令对终端设备进行获取其Root权限的尝试，如果成功获取，则向为其提供所述的推荐列表的云端服务器反馈一条结果数据，在该结果数据中除包含该配置方案外，可以包含本发明的特征信息和表示Root成功的

数据；同理，如果获取权限失败，向该云端服务器反馈一条结果数据，在该结果数据中除包含特征信息外，还包含表示Root失败的数据。其中的特征信息，主要是因应机型记录表的需要而提供不同的特征信息专项，当然也可更为详尽地提供更多特征信息专项以供服务器完善各表数据之用，但是，适应表3所揭示的机型记录表的表结构，可以看出，配置方案、机型这两个专项在本发明所揭示的前述实施例中是关键的。采集单元15，调用一更新单元16，根据接收到的结果数据，在机型记录表中查找到与结果数据中的特征信息相符的记录，然后对其相关联的成功次数或失败次数，以及成功率做适应性的更新。对相应的成功次数或失败次数，进行累加或累减，对所述的成功率，则仍依据相应的成功次数和失败次数计算而得。由此也可以看出，相对于权重，所述成功率是更为实时的数据。

通过采集单元15的作用，便可采集终端设备的用户结果数据，并将该些 结果数据作为实施本发明所需的历史使用数据进行使用。

需要指出的是，本实施例的所述更新单元16，实现两方面的功能，即利用终端设备结果数据统计机型记录表中的成功率，以及利用机型记录表中的成功率统计出学习表中的权重。在其他实施例中，这两部分功能可以细分为两个子模块，并分别独立实现。例如，用于统计权重的模块可以定时独立运行，用于统计成功率的模块可以直接在所述采集单元15中实现，由此可知，所述更新单元16只是对本发明所要实现的统计功能的概括，对其理解，不应限制本发明的实施例的灵活实现。

由于云端服务器能够实时地接收互联网上的多个用户的结果数据，所以，云端服务器上的数据库10中的数据将具有大数据优势，根据这些结果数据进行的前述的深挖掘所形成的权重、成功率等数值，有助于进一步提高优选用于终端设备的配置方案的智能化程度。

为了说明本发明的提权配置方案反馈装置的运作过程，以下借助本发明的提权配置方案反馈方法做进一步的说明。

本发明的提权配置方案反馈方法，请参阅图5所示，包括如下步骤：

S11、获取包含终端设备的特征信息的请求。

云端服务器在其监听端口监听互联网终端设备发起的有关获取配置方案推荐列表的请求，这些请求显然是配置有诸如所述的“360一键Root”的软件发起的，该请求中的特征信息，在本实施例中，是与终端设备连接的终端设备的本机信息，包含机型、CPU型号、系统版本号以及内核版本号。

S12、依据所述特征信息查找包含用于获取Root权限的配置方案。

本步骤主要是在前述表1中检索出与所述特征信息相关的配置方案。如前所述，依据程序设计的实际精度需要，提取特征信息中的有关专项，例如机型和系统版本号，以这些专项在前述的配置方案中进行检索，将获得所述表4的未经排序的结果。

S13、依据为所述配置方案所保存的历史使用数据对查找到的配置方案进 行排序后，形成包含查找到的配置方案的推荐列表。

参阅前述说明，可以理解，本步骤包含多种实施方式，具体包括：通过读取学习表中的权重，以权重对表4进行排序获得表6的结果；通过读取学习表中的成功率，以成功率对表4进行排序获得表5的结果；以及，通过读取学习表中的权重作为第一排序字段，通过读取机型学习表中的成功率作为第二排序字段，以此为依据对表4进行排序，对于权重相同的配置方案，适应其成功率进行二次排序，从而获得如表6所示的配置方案推荐列表。

S14、响应于该请求而推送包含排序后的配置方案的推荐列表。

本步骤如前所述，用于将所述排序后的推荐列表发送给终端设备，以供终端设备进行用户Root权限获取的尝试。

S15、采集并保存表征被推送后的所述推荐列表所包含的配置方案是否成功获取Root权限的结果数据，将该结果数据作为所述历史使用数据。

如前所述，云端服务器进一步在其监听端口监听终端设备试用推荐列表中的配置方案后而返回的结果数据，然后将该结果数据应用到机型记录表中。在上述揭示的部分实施例中，针对每条结果数据所包含的与一条配置方案有关的结果数据，可以直接利用该结果数据计算机型记录表的成功次数或失败次数，并且直接统计出其相关的成功率且更新之。在上述揭示的另外的实施例中，统计成功率的运算过程，可以通过调用外部函数来实现。因此，本步骤显然也可按需分离为两个子步骤，分别是实现对结果数据的采集的步骤和在已采集数据的基础上的统计子步骤。

S16、利用机型记录表中的成功率统计出学习表中的权重。

本步骤并非实时触发的步骤，也就是说，步骤S15并不必然导致S16的运行。具体而言，可以借助一个计时器来触发本步骤的运行，该计时器是为了确保本步骤在以一定的时间例如一天或一周来间隔运行，通过运行本步骤，应用相关约定算法，实现前述有关权重的统计，从而实现所述学习表数据的更新。

可以理解，在某些情况下，步骤S15中有关成功率的统计的子步骤与本步 骤是可以相继触发的。

观察本方法的上述各个步骤，实质上揭示了由本发明所实现的一个服务器程序实例的运行流程，该运行流程显然，以配置方案为基础，构成了闭环的信息流关系，配置方案是否有效的数据来源于终端设备，最终也为终端设备服务，只是基于云技术原理，利用该结果数据的终端设备可能并非提供该结果数据的终端设备。

以上所述仅是本发明的部分实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应落在本发明的保护范围内。

本发明提供A1、一种终端设备的root方法，该方法包括：

获取终端设备的特征信息；

基于所述特征信息向服务器发送配置方案获取请求；

从服务器获取与所述特征信息相匹配的配置方案，所述配置方案包含用于获取root权限的配置信息；

终端设备执行所述配置方案，以获取root权限。

A2、根据A1所述的方法，

所述步骤：从服务器获取与所述特征信息相匹配的配置方案，具体为：从服务器获取与述特征信息相匹配的多个配置方案，所述多个配置方案具有推荐顺序；

所述步骤：终端设备执行所述配置方案，以获取root权限，具体为：终端设备按照所述推荐顺序执行配置方案，以获取root权限。

A3、根据A2所述的方法，该方法还包括：

终端设备每执行完一个配置方案后，确定是否成功获取root权限；

如果成功获取root权限，则停止执行下一个配置方案。

A4、根据A1或A所述的方法，该方法还包括：

采集表达终端设备执行所述配置方案后是否成功获取root权限的反馈数 据，并将所述反馈数据上报服务器。

B5、一种终端设备，该终端设备包括：

特征信息获取单元，用于获取终端设备的特征信息；

发送单元，用于基于所述特征信息向服务器发送配置方案获取请求；

接收单元，用于从服务器获取与所述特征信息相匹配的配置方案，所述配置方案包含用于获取root权限的配置信息；

执行单元，用于执行所述配置方案，以获取root权限。

B6、根据B5所述的终端设备，其特征还在于，该接收单元用于从服务器获取与述特征信息相匹配的多个配置方案，所述多个配置方案具有推荐顺序，所述执行单元按照所述推荐顺序执行所述配置方案，以获取root权限。

B7、根据B6所述的终端设备，该终端设备包括：

Root权限垂询单元，用于在执行一个配置方案后，查询所述终端设备是否成功获取root权限，如果成功获取root权限，则通知所述执行单元停止执行下一个配置方案。

B8、根据B7所述的终端设备，该终端设备包括：

执行反馈单元，用于根据所述Root权限垂询单元的查询结果，记录配置成功的配置方案以及配置失败的配置方案，并将配置方案配置成功与失败的信息发送到服务器。

C9、一种配置方法，包括：

获取包含终端设备的特征信息的请求；

依据所述特征信息查找包含用于获取Root权限的配置方案；

依据为所述配置方案所保存的历史使用数据对查找到的配置方案进行排序，并形成推荐表，所述推荐表包含查找到的配置方案的内容信息以及查找到的配置方案的排序信息；

响应与所述请求推送所述推荐表。

C10、根据C9所述的方法，所述历史使用数据为终端设备执行所述配置 方案的执行结果的历史记录。

D11、一种服务器，包括

获取单元，用于获取包含终端设备的特征信息的请求；

查找单元，被配置为依据所述特征信息查找包含用于获取Root权限的配置方案；

排序单元，被配置为依据为保存的历史使用数据对查找到的配置方案进行排序，并形成推荐表，所述推荐表包含查找到的配置方案的内容信息以及查找到的配置方案的排序信息；

配置方案推送单元，被配置为响应与所述请求推送所述推荐表。

D12、根据D11所述的服务器，该服务器包括

第一存储单元，用于存储配置方案；

第二存储单元，用于存储每个配置方案的历史使用数据；

学习单元，根据每个配置方案的历史使用数据为所述配置方案计算权重，所述权重作为形成配置方案的推荐列表的因素。