电子设备定制模式的实现方法及电子设备与流程

本申请涉及电子设备的软件设计技术领域，具体涉及一种电子设备定制模式的实现方法及电子设备。

背景技术：

电子设备厂商通常按照客户的要求对电子设备进行不同的定制，有些客户希望同一个电子设备能在某种条件下实现完全不同的定制功能,不同的界面，配置文件及业务逻辑。

例如：某工厂为工人定制了一批手机，但是他们希望在a车间的工人用的手机搭载的功能、界面(userinterface，ui)和应用程序(applicationg，app)等和b车间的不同。

在现有技术中，想要实现上述目的，一种方式是通过设计两套不同的软件系统，即根据客户的需求设计两套只读存储器(read-onlymemory，rom)内的参数来满足上述的定制需求，但这增加了电子设备的生产成本；而且采用这种方式设计的软件系统在电子设备的使用过程中是不能改变的，即如果该手机被定制为a车间所需的模式，就不能在使用的过程中被修改为b车间所需的模式，因此存在着资源浪费的问题。

另外一种方式是通过手机里的应用程序去设置状态值，通过该状态值在包管理器(packagemanagerservice)扫描应用程序包时对应用程序进行过滤和功能定制，通过这种方式仅可以隐藏一些应用程序或有限的改变一些用户界面及业务逻辑；且采用这种方式，由于该状态值一般都是保存在数据库或者文件中，因此当手机在恢复出厂化后，所有的定制会全部重置。

技术实现要素：

鉴于上述问题，提出了本申请以便提供一种克服上述问题或者至少部分地解决上述问题的电子设备定制模式的实现方法及装置。

根据本申请的一方面，提供了一种电子设备定制模式的实现方法，包括：

在满足定制模式触发条件的情况下，从电子设备的非易失性存储区中读取定制模式的属性值；

根据属性值和基础manifest文件生成定制模式的manifest文件；

根据定制模式的manifest文件加载应用程序，以实现定制模式。

优选的，上述方法还包括：

响应于第一应用程序发出的定制模式触发请求，获取通过第一应用程序设置的定制模式的属性值。

优选的，在上述的方法中，属性值为已安装的第二应用程序的属性值，基础manifest文件为第二应用程序的基础manifest文件；

根据定制模式的manifest文件加载应用程序包括：

根据定制模式的manifest文件加载第二应用程序，以使第二应用程序具有与定制模式对应的界面和/或业务逻辑。

优选的，在上述的方法中，从所述电子设备的非易失性存储区中读取定制模式的属性值包括：

调用框架层中的第一属性值读取函数，从电子设备的非易失性存储区中读取定制模式的属性值；

其中，第一属性值读取函数在被调用时，能够根据jni层的第二属性值读取函数调用高通平台提供的非易失性存储区访问接口，以从电子设备的非易失性存储区中读取定制模式的属性值。

优选的，上述方法还包括：

响应于第三应用程序发出的定制模式编辑请求，在电子设备的非易失性存储区内写入多个不同的属性值，其中，多个不同的属性值分别对应不同的定制模式。

优选的，在上述的方法中，在电子设备的属性值存储空间内写入多个不同的属性值包括：

调用框架层中的第一属性值写入函数，在电子设备的非易失性存储区中写入定制模式的属性值；

其中，第一属性值写入函数在被调用时，能够根据jni层的第二属性值写入函数调用高通平台提供的非易失性存储区访问接口，以在电子设备的非易失性存储区中写入定制模式的属性值。

优选的，在上述的方法中，根据所述定制模式的manifest文件加载应用程序包括：

根据定制模式的manifest文件确定需要加载的预装应用程序；

调用安卓包管理服务，对预装应用程序的安装包进行扫描，扫描得到需要加载的预装应用程序的安装包；

根据扫描得到的安装包进行应用程序的加载。

优选的，在上述的方法中，属性值为安卓系统的属性值，根据定制模式的manifest文件加载应用程序，以实现定制模式包括：

根据定制模式的manifest文件加载安卓系统，以实现定制模型的系统界面和/或系统权限。

优选的，在上述的方法中，根据属性值和基础manifest文件生成定制模式的manifest文件包括：

根据属性值，对基础manifest文件的节点信息进行过滤和/或修改，从而得到定制模式的manifest文件。

依据本申请的另一方面，提供了一种电子设备，该电子设备包括一个定制模式的实现装置，该装置包括：

读取单元，用于在满足定制模式触发条件的情况下，从电子设备的非易失性存储区中读取定制模式的属性值；

生成单元，用于根据属性值和基础manifest文件生成定制模式的manifest文件；

加载单元，用于根据定制模式的manifest文件加载应用程序，以实现定制模式。

优选的，读取单元，还用于响应于第一应用程序发出的定制模式触发请求，获取通过第一应用程序设置的定制模式的属性值。

优选的，在上述的电子设备中，属性值为已安装的第二应用程序的属性值，基础配置说明(manifest)文件为第二应用程序的基础配置说明文件；

加载单元，还用于根据定制模式的manifest文件加载第二应用程序，以使第二应用程序具有与定制模式对应的界面和/或业务逻辑。

优选的，在上述的电子设备中，读取单元，用于调用框架层中的第一属性值读取函数，从电子设备的非易失性存储区中读取定制模式的属性值；其中，第一属性值读取函数在被调用时，能够根据jni层的第二属性值读取函数调用高通平台提供的非易失性存储区访问接口，以从电子设备的非易失性存储区中读取定制模式的属性值。

优选的，上述电子设备还包括：写入单元，用于响应于第三应用程序发出的定制模式编辑请求，在电子设备的非易失性存储区内写入多个不同的属性值，其中，多个不同的属性值分别对应不同的定制模式。

优选的，在上述的电子设备中，写入单元，用于调用框架层中的第一属性值写入函数，在电子设备的非易失性存储区中写入定制模式的属性值；其中，第一属性值写入函数在被调用时，能够根据jni层的第二属性值写入函数调用高通平台提供的非易失性存储区访问接口，以在电子设备的非易失性存储区中写入定制模式的属性值。

优选的，在上述的电子设备中，加载单元，用于根据定制模式的manifest文件确定需要加载的预装应用程序；调用安卓包管理服务，对预装应用程序的安装包进行扫描，扫描得到需要加载的预装应用程序的安装包；根据扫描得到的安装包进行应用程序的加载。

优选的，在上述的电子设备中，属性值为安卓系统的属性值，加载单元，用于根据定制模式的manifest文件加载安卓系统，以实现定制模型的系统界面和/或系统权限。

优选的，在上述的电子设备中，生成单元，用于根据属性值，对基础manifest文件的节点信息进行过滤和/或修改，从而得到定制模式的manifest文件。

依据本申请的第三方面，提供了一种计算机可读存储介质，其中，所述计算机可读存储介质存储一个或多个程序，所述一个或多个程序当被处理器执行时，实现如上述任一所述的电子设备定制模式的实现方法。

本申请的构思在于，通过读取电子设备的非易失性存储区中的属性值，并根据属性值的不同，生成对应的定制模式的manifest文件，并根据定制模式的manifest文件为电子设备加载特定模式的应用程序；本申请在不改变原有manifest文件及架构的基础上，可以在同一个rom里实现不同模式的深度定制，从而节省了电子设备的软件系统的设计成本，且由于属性值写在电子设备的非易失存储区，在被恢复出厂化后，电子设备的定制模式不会被重置，避免了需要反复设置的麻烦；且在电子设备的使用过程中，能够根据需要实现定制模式动态的切换和加载，提高了电子设备使用的灵活性，使得硬件设备资源得到了更合理的优化配置，节约了硬件设备资源的成本。

由上述可知，本申请的技术方案，上述说明仅是本申请技术方案的概述，为了能够更清楚了解本申请的技术手段，而可依照说明书的内容予以实施，并且为了让本申请的上述和其它目的、特征和优点能够更明显易懂，以下特举本申请的具体实施方式。

附图说明

通过阅读下文优选实施方式的详细描述，各种其他的优点和益处对于本领域普通技术人员将变得清楚明了。附图仅用于示出优选实施方式的目的，而并不认为是对本申请的限制。而且在整个附图中，用相同的参考符号表示相同的部件。在附图中：

图1示出了根据本申请一个实施例的电子设备定制模式的实现方法的流程示意图；

图2示出了根据本申请一个实施例的框架层和jni层的框图；

图3示出了根据本申请另一个实施例的电子设备定制模式的实现方法的流程示意图；

图4示出了根据本申请一个实施例的电子设备的结构示意图；

图5示出了根据本申请一个实施例的计算机可读存储介质的结构示意图。

具体实施方式

下面将参照附图更详细地描述本申请的示例性实施例。虽然附图中显示了本申请的示例性实施例，然而应当理解，可以以各种形式实现本申请而不应被这里阐述的实施例所限制。相反，提供这些实施例是为了能够更透彻地理解本申请，并且能够将本申请的范围完整的传达给本领域的技术人员。

本申请的构思在于，本发明的目的是使安卓(android)厂商能够根据属性值动态生成不同的manifest文件，动态切换不同界面显示，加载不同的应用程序。进一步的，每个应用程序都可以根据这个属性值的切换而实现不同的业务逻辑加载不同的界面，从而实现编译一个rom满足不同定制的要求。

但是，电子设备的恢复出厂设置功能可能使得属性值丢失，导致定制模式失效，为了解决这一问题，本申请提出了将属性值存放到nv(non-volatile，非易失性)存储区的方式，为了简便描述，本申请中的属性值也可以称为nv值。

图1示出了根据本申请一个实施例的电子设备定制模式的实现方法的流程示意图，从图1可以看出，包括：

步骤s110，在满足定制模式触发条件的情况下，从电子设备的非易失性存储区中读取定制模式的属性值。

本申请主要用于在具有android操作系统的电子设备中，android是一种基于linux的自由及开放源码的操作系统，主要用于智能手机和平板电脑，由google公司和手机开放手机联盟领导及开发，中文名多为“安卓”。

具有安卓操作系统的电子设备，包括但不限于手机、平板电脑(pad)等，的软件开发框架是以高通平台为基础(base)，软件开发框架由上至下主要包括以下几层结构：应用层(applications)、应用框架层(applicationframework)、系统运行库层(androidruntime)、linux内核层(linuxkernel)；为了实现本申请，在应用框架层的下层设置了jni(javanativeinterface)层。jni层可通过高通属性值应用程序接口(applicationprogramminginterface,api)与电子设备的rom实现数据交互。

在满足定制模式触发条件的情况下，如在手机出厂第一开机时，或手机被恢复出厂再次开机时，从电子设备的非易失性存储区中读取属性值。第一次启动后电子会保存第一次启动涉及的应用程序的各种信息，以及初始化设定等，再次启动后不会更改；恢复出厂化设置就是清空手机的所有信息，等同于第一次启动。

一般地，非易失性存储区中的数据被称为nv文件，用于记录一些电子设备相关的一些信息，保存了系统运行过程中各个模块可能用到的一些参数值。系统掉电后，存储在非易失性存储性区中的数据也不会丢失。本申请基于这一点，将属性值记录在非易失性存储区中，从而保证属性值的稳定性，不会因恢复出厂设置或是系统故障而丢失。

本申请中电子设备的非易失性存储性区中包括多个不同的nv值，每个nv值对应着一个定制模式，并能够基于nv值生成定制模式的manifest文件。这里的nv值是提前写入电子设备的非易失性存储性区中的。

步骤s120，根据属性值和基础manifest文件生成定制模式的manifest文件。

基础manifest文件及应用程序包的配置信息是在第一次开机或恢复出厂化设置再次开机时，被扫描后并保存在电子设备里的。manifest文件即androidmanifest.xml，它在framework的res目录下，为framework-res.apk的java软件包命名。android的所有配置文件都在这里定义，它描述应用的各个组件，包括构成的activity组件、service组件、广播接收器和内容提供程序。它还为实现每个组件的类命名并发布其功能，确定托管应用组件的进程，声明系统广播，运行时权限组，运行时权限和其他权限等等，manifest文件以节点方式存在。

本申请中，基础manifest文件是一个通用manifest文件，它具有一般manifest文件的内容；而定制模式的manifest文件是根据客户的特殊需求设计的manifest文件，它具有与定制模式对应的特定内容。

在电子设备的非易失性存储性器包含多个不同的属性值，如为01、02、03，分别能够对应生成a模式的manifest文件、b模式的manifest文件、c模式的manifest文件。

如在读取到属性值为01时，将基础manifest文件通过改写、过滤等操作，转化成a模式的manifest文件。

步骤s130，根据定制模式的manifest文件加载应用程序，以实现定制模式。

根据定制模式的manifest文件可以决定加载哪些apk,或者不加载哪些apk，比如设置黑白名单，在黑名单中的apk不予加载，在白名单中的apk予以加载，从而实现对apk的过滤，进一步的而实现了电子设备的软件系统的定制模式。

由图1所示的方法可以看出，本申请在不改变原有manifest文件及架构的基础上，可以在同一个rom里实现不同模式的深度定制，从而节省了电子设备的软件系统的设计成本，且由于属性值写在电子设备的非易失存储区，在被恢复出厂化后，电子设备的定制模式不会被重置，避免了需要反复设置的麻烦；且在电子设备的使用过程中，能够根据需要实现定制模式动态的切换和加载，提高了电子设备使用的灵活性，使得硬件设备资源得到了更合理的优化配置，节约了硬件设备资源的成本。

在本申请的一些实施例中，用户可以根据自己的需求指定为电子设备加载何种定制模式。具体读取用户在应用层的应用程序中的设定属性值该设定属性值可以是用户通过在应用程序中弹出的界面进行填写或选择来加以设定，该设定属性值为写在电子设备非易失性存储区中的属性值中的任意一个；根据设定属性值和基础manifest文件生成定制模式的manifest文件。

具体的，读取用户在应用层的应用程序中的设定属性值；将设定属性值与属性值进行比较，确定出设定属性值是属性值中的哪一个，并确定出对应的模式，根据设定属性值对基础manifest文件进行调整，得到与设定属性值对应的manifest文件。

如属性值中包括01，02和03，分别对应着a模式的manifest文件、b模式的manifest文件、c模式的manifest文件。如果用户想要加载a定制模式，则可以在应用程序中填写01来实现a定制模式的加载。

如对于同一车间的工人，一部分工人负责货物的录入，另一部分工人负责货物的分类，在一部分工人的电子设备上只显示录入界面，另一部分工人的电子设备上只显示分类界面。一个工人的工作由录入转为了分类，此时，该工人可以通过在应用程序填写nv值来实现模式的切换。由于此时仅涉及到特定应用程序的定制，而非操作系统的定制，可以不需要恢复出厂设置，能够仅通过应用层来实现定制模式的切换。

在本申请的一些实施例中，在上述的方法中，属性值为已安装的第二应用程序的属性值，基础manifest文件为第二应用程序的基础manifest文件，因此，用户还可以通过设定属性值来对第二应用程序实现不同的界面、功能、业务逻辑等。

需要说明的是，第二应用程序的属性值也是提前写入电子设备的非易失性存储区中，可以是前述的属性值中的一部分。

第二应用程序包括维持电子设备运行的基础应用程序，也包括一些安装在应用层的一些应用程序，即第三方应用程序。电子设备的软件系统包括一个manifest文件，该manifest文件负责基础应用程序的加载，而每个第三方应用程序也包括一个manifest文件，各应用程序的manifest文件负责每个第三方应用程序的加载，在本申请中，第二应用程序主要指这里说明的第三方应用程序，这里将第三方应用程序简称为app。

根据各app的属性值和各app的基础manifest文件生成各app的定制模式的manifest文件。通过设置第二应用程序的属性值，即app的属性值，通过对app的基础manifest文件的修改、过滤等，将app的基础manifest文件转化为app的定制模式的manifest文件，根据app的定制模式的manifest文件加载该app，这时，该app就具有与app的定制模式的manifest文件中限定的界面和/或业务逻辑。

如一个app的属性值包括2个值，分别为01和02，01对应a定制模式，a定制模式需要增加动态权限a1、a2；02对应b定制模式，b定制模式需要增加动态权限b1、b2。

如读取到的app的属性值为01，则对app基础manifest文件进行调整，得到与a定制模对应的app的定制模式的manifest文件。

为电子设备加载第二应用程序，第二应用程序具有与app的定制模式的manifest文件对应的界面、功能菜单以及业务逻辑，这样用户可以通过app调用不同的属性值去显示不同的界面等来实现不同的功能，能够满足客户的个性化需求。也就是说，用户可以通过在app中填写属性值，以此来控制app实现不同的界面、功能菜单以及业务逻辑。

如对于同一车间的工人，一部分工人负责货物的录入，另一部分工人负责货物的分类，就可以通过调用不同的属性值，在一部分工人的电子设备上只显示录入界面，另一部分工人的电子设备上只显示分类界面，免去工人切换界面的麻烦，也节省电子设备的缓冲空间。

在本申请的一些实施例中，为了实现从电子设备的非易失性存储区中读取定制模式的属性值设置了下列函数，具体的，本发明是以高通为基础(base)的，高通平台提供了对nv值读写的api，但是该api位于的层为c语言层，上层的java语言层直接读取的话速度很慢，甚至是无法直接进行调用，因此，这里设置一个中间层去完成呈上启下这个调用过程，即本申请中的jni层；并且在框架层与jni层写入相应的函数来完成调用过程。图2示出了根据本申请一个实施例的框架层和jni层的框图，从图2中可以看出，在框架层中，定义了一个静态的java类nvcontroller.java，在这个类中，定义了两个函数，分别为第一属性值读取函数(readnv())和第一属性值写入函数(writenv())，作为外部读写nv值的对外接口。

在jni层中，定义一个c++的类com_custom_nvcontroller.cpp，在这个类里添加两个函数，分别为第二属性值读取函数(native_readflag_nv)和第二属性值写入函数(native_writer_nv)，这两个函数分别作为调用高通的对nv值的读写函数。

读取过程可以简述如下，调用框架层中controller.java中的readnv()，从所述电子设备的非易失性存储区中读取定制模式的属性值；其中，第一属性值读取函数在被调用时，架层中controller.java中的readnv()控制jni层的com_custom_nvcontroller.cpp中的native_readflag_nv通过高通api接口从电子设备的非易失性存储区读取nv值。

在本申请的一些实施例中，上述的方法还包括属性值的写入过程，具体的，响应于第三应用程序发出的定制模式编辑请求，在电子设备的非易失性存储区内写入多个不同的属性值，其中，多个不同的属性值分别对应不同的定制模式的manifest文件。

请再次参考图2，响应于第三应用程序发出的定制模式编辑请求，将多个不同的属性值写入框架层的第一属性值写入函数(writenv())中，框架层的第一属性值写入函数(writenv())将属性值传递至jni层的第二属性值写入函数(native_writer_nv)中，然后由jni层的第二属性值写入函数(native_writer_nv)执行第一属性值写入函数(writenv())的指令，通过高通属性值应用程序接口(nv值api)将属性值写入电子设备的非易失性存储区。

需要说明的是，在本申请中，对nv值的写入过程，可以由写在应用框架层、jni层、系统运行库层中的方法执行，而对于读取过程，可以由写在应用框架层、jni层、系统运行库层中的方法执行，也可以由第三应用程序来实现。

在本申请的一些实施例中，根据不同的定制模式的manifest文件来加载应用程序，包括：根据定制模式的manifest文件，控制包管理器(packagemanagerservice)扫描预装应用程序，并加载与定制模式的manifest文件对应的指定应用程序。

首先，根据定制模式的manifest文件扫描预装应用程序，过滤掉不需要的应用程序，保留指定的应用程序。

然后，调用安卓包管理服务(packagemanagerservice)，对上述已经确定下来的指定的应用程序的安装包(androidapplicationpackage，apk)进行扫描，扫描得到需要加载的预装应用程序的安装包；

最后，根据扫描得到的安装包进行应用程序的加载，在加载过程中，应用程序的配置参数在定制模式的manifest文件中有限定，因此，加载的应用程序具有与定制模式的manifest文件对应的功能。

packagemanagerservice俗称包管理器，它主要功能是解析androidmanifest.xml，主要包括manifest中节点信息的解析、扫描本地文件以及应用程序包(androidapplicationpackage，apk)，系统应用、本地安装应用等等。

android系统启动过程中解析manifest文件的流程是通过packagemanagerservice来实现的，然后将解析得到的配置信息保存到系统中。具体的，可以调用scanpackageli(目前业内没有统一中文名)方法来对扩展名为apk的文件进行扫描，最终通过packageparser.java类中的parsebaseapkcommon(目前业内没有统一中文名)方法去解析manifest文件。

当解析完manifest文件后，根据不同类别分别的将得到的配置信息保存到手机中，例如系统所需要的运行时权限，权限组等。

在解析定制模式的manifest文件后，可以根据定制模式的manifest文件对apk进行过滤，决定对哪些apk进行加载，哪些不加载；也可以根据app定制模式的manifest文件，决定一个app加载哪些界面、功能等，哪些界面、功能不加载。

在本申请的一些实施例中，生成定制模式的manifest文件的过程包括不限于对基础manifest文件的节点信息进行过滤和/或修改等。如不需要加载某个应用程序，则可以过滤掉该应用程序对应的节点信息；或者某个应用程序的功能是不需要的，则可以过滤或者采用将其他节点信息替换掉该功能对应的节点信息。

在本申请的一些实施例中，如果上述的属性值为安卓系统的属性值，基础manifest文件为安卓系统的manifest文件，则可以根据不同的属性值，加载不同模式的安卓系统，即根据定制模式的manifest文件加载安卓系统，就实现定制模型的系统界面和/或系统权限。加载过程与上述实施例一致，在此，不再赘述。

图3示出了根据本申请另一个实施例的电子设备定制模式的实现方法的流程示意图；从图3可以看出，本实施例应用于手机第一次开机。

读取电子设备中的非易失存储区中的nv值，确定与nv值对应的定制模式，确定与nv值对应的定制模式,修改基础manifest文件，生成a定制模式的manifest文件,加载与定制模式的manifest文件对应的应用程序。

获取用户在第三方应用程序中填写的app设定nv值，比较app设定nv值与nv值，确定app设定nv值是nv值中的哪一个，生成与app设定nv值对应的app定制模式的manifest文件。

加载app，该app与比较设定nv值与nv值对应的界面、功能菜单以及业务逻辑，从而实现了定制模式。

图4示出了根据本申请一个实施例的电子设备的结构示意图，该电子设备400包括一个定制模式的实现装置410；该实现装置410包括：

读取单元411，用于在满足定制模式触发条件的情况下，从电子设备的非易失性存储区中读取定制模式的属性值。

本申请主要用于在具有android操作系统的电子设备中，android是一种基于linux的自由及开放源码的操作系统，主要用于智能手机和平板电脑，由google公司和手机开放手机联盟领导及开发，中文名多为“安卓”。

具有安卓操作系统的电子设备，包括但不限于手机、平板电脑(pad)等，的软件开发框架是以高通平台为基础(base)，软件开发框架由上至下主要包括以下几层结构：应用层(applications)、应用框架层(applicationframework)、系统运行库层(androidruntime)、linux内核层(linuxkernel)；为了实现本申请，在应用框架层的下层设置了jni(javanativeinterface)层。jni层可通过高通属性值应用程序接口(applicationprogramminginterface,api)与电子设备的rom实现数据交互。

在满足定制模式触发条件的情况下，如在手机出厂第一次开机时，或手机被恢复出厂再次开机时，从电子设备的非易失性存储区中读取属性值。第一次启动后电子会保存第一次启动涉及的应用程序的各种信息，以及初始化设定等，再次启动后不会更改；恢复出厂化设置就是清空手机的所有信息，等同于第一次启动。

一般地，非易失性存储区中的数据被称为nv文件，用于记录一些电子设备相关的一些信息，保存了系统运行过程中各个模块可能用到的一些参数值。系统掉电后，存储在非易失性存储性区中的数据也不会丢失。本申请基于这一点，将属性值记录在非易失性存储区中，从而保证属性值的稳定性，不会因恢复出厂设置或是系统故障而丢失。

本申请中电子设备的非易失性存储性区中包括多个不同的nv值，每个nv值对应着一个定制模式，并能够基于nv值生成定制模式的manifest文件。

生成单元412，用于根据属性值和基础manifest文件生成定制模式的manifest文件。

基础manifest文件及应用程序包的配置信息是在第一次开机或恢复出厂化设置再次开机时，被扫描后并保存在电子设备里的。manifest文件即androidmanifest.xml，它在framework的res目录下，为framework-res.apk的java软件包命名。android的所有配置文件都在这里定义，它描述应用的各个组件，包括构成的activity组件、service组件、广播接收器和内容提供程序。它还为实现每个组件的类命名并发布其功能，确定托管应用组件的进程，声明系统广播，运行时权限组，运行时权限和其他权限等等，manifest文件以节点方式存在。

本申请中，基础manifest文件是一个通用manifest文件，它具有一般manifest文件的内容；而定制模式的manifest文件是根据客户的特殊需求设计的manifest文件，它具有与定制模式对应的特定内容。

在电子设备的非易失性存储性器包含多个不同的属性值，如为01、02、03，分别能够对应生成a模式的manifest文件、b模式的manifest文件、c模式的manifest文件。

如在读取到属性值为01时，将基础manifest文件通过改写、过滤等操作，转化成a模式的manifest文件。

加载单元413，用于根据定制模式的manifest文件加载应用程序，以实现定制模式。

根据定制模式的manifest文件可以决定加载哪些apk,或者不加载哪些apk，比如设置黑白名单，在黑名单中的apk不予加载，在白名单中的apk予以加载，从而实现对apk的过滤，进一步的而实现了电子设备的软件系统的定制模式。

由图4所示的电子设备可以看出，本申请在不改变原有manifest文件及架构的基础上，可以在同一个rom里实现不同模式的深度定制，从而节省了电子设备的软件系统的设计成本，且由于属性值写在电子设备的非易失存储区，在被恢复出厂化后，电子设备的定制模式不会被重置，避免了需要反复设置的麻烦；且在电子设备的使用过程中，能够根据需要实现定制模式动态的切换和加载，提高了电子设备使用的灵活性，使得硬件设备资源得到了更合理的优化配置，节约了硬件设备资源的成本。

在本申请的一些实施例中，读取单元411，还用于读取用户在应用层的应用程序中的设定属性值；生成单元，还用于根据设定属性值和基础manifest文件生成定制模式的manifest文件。

在本申请的一些实施例中，在上述的装置中，属性值包括app属性值；加载单元430，用于根据app属性值和app基础manifest文件生成app定制模式的manifest文件；为电子设备加载应用程序，该应用程序具有与app定制模式的manifest文件对应的界面、功能菜单以及业务逻辑。

在本申请的一些实施例中，在上述的装置中，读取单元411，用于读取框架层中的第一属性值读取函数中的属性值，属性值是由jni层的第二属性值读取函数通过高通属性值应用程序接口从电子设备的非易失性存储区中读取并传递至第一属性值读取函数的。

在本申请的一些实施例中，上述的装置还包括：写入单元，用于在电子设备的非易失性存储区内写入多个不同的属性值，其中，所述多个不同的属性值分别对应不同的定制模式的manifest文件。

在本申请的一些实施例中，在上述的装置中，写入单元，用于将多个不同的属性值写入框架层的第一属性值写入函数中，以使框架层的第一属性值写入函数将属性值传递至jni层的第二属性值写入函数中，并控制jni层的第二属性值写入函数通过高通属性值应用程序接口将属性值写入电子设备的非易失性存储区。

在本申请的一些实施例中，在上述的装置中，加载单元413，用于根据定制模式的manifest文件，控制包管理器扫描预设应用程序，并加载与定制模式的manifest文件对应的指定应用程序。

在本申请的一些实施例中，在上述的装置中，生成单元412，用于根据属性值，对基础manifest文件的节点信息进行过滤和/或修改，从而得到定制模式的manifest文件。

需要说明的是，上述各装置实施例的具体实施方式可以参照前述对应方法实施例的具体实施方式进行，在此不再赘述。

综上所述，本申请在不改变原有manifest文件及架构的基础上，可以在同一个rom里实现不同模式的深度定制，从而节省了电子设备的软件系统的设计成本，且由于属性值写在电子设备的非易失存储区，在被恢复出厂化后，电子设备的定制模式不会被重置，避免了需要反复设置的麻烦；且在电子设备的使用过程中，能够根据需要实现定制模式动态的切换和加载，提高了电子设备使用的灵活性，使得硬件设备资源得到了更合理的优化配置，节约了硬件设备资源的成本。

需要说明的是：

在此提供的算法和显示不与任何特定计算机、虚拟装置或者其它设备固有相关。各种通用装置也可以与基于在此的示教一起使用。根据上面的描述，构造这类装置所要求的结构是显而易见的。此外，本申请也不针对任何特定编程语言。应当明白，可以利用各种编程语言实现在此描述的本申请的内容，并且上面对特定语言所做的描述是为了披露本申请的最佳实施方式。

在此处所提供的说明书中，说明了大量具体细节。然而，能够理解，本申请的实施例可以在没有这些具体细节的情况下实践。在一些实例中，并未详细示出公知的方法、结构和技术，以便不模糊对本说明书的理解。

类似地，应当理解，为了精简本申请并帮助理解各个发明方面中的一个或多个，在上面对本申请的示例性实施例的描述中，本申请的各个特征有时被一起分组到单个实施例、图、或者对其的描述中。然而，并不应将该公开的方法解释成反映如下意图：即所要求保护的本申请要求比在每个权利要求中所明确记载的特征更多的特征。更确切地说，如下面的权利要求书所反映的那样，发明方面在于少于前面公开的单个实施例的所有特征。因此，遵循具体实施方式的权利要求书由此明确地并入该具体实施方式，其中每个权利要求本身都作为本申请的单独实施例。

本领域的普通技术人员可以理解，可以对实施例中的设备中的模块进行自适应性地改变并且把它们设置在与该实施例不同的一个或多个设备中。可以把实施例中的模块或单元或组件组合成一个模块或单元或组件，以及此外可以把它们分成多个子模块或子单元或子组件。除了这样的特征和/或过程或者单元中的至少一些是相互排斥之外，可以采用任何组合对本说明书(包括伴随的权利要求、摘要和附图)中公开的所有特征以及如此公开的任何方法或者设备的所有过程或单元进行组合。除非另外明确陈述，本说明书(包括伴随的权利要求、摘要和附图)中公开的每个特征可以由提供相同、等同或相似目的的替代特征来代替。

此外，本领域的技术人员能够理解，尽管在此所述的一些实施例包括其它实施例中所包括的某些特征而不是其它特征，但是不同实施例的特征的组合意味着处于本申请的范围之内并且形成不同的实施例。例如，在下面的权利要求书中，所要求保护的实施例的任意之一都可以以任意的组合方式来使用。

本申请的各个部件实施例可以以硬件实现，或者以在一个或者多个处理器上运行的软件模块实现，或者以它们的组合实现。本领域的技术人员应当理解，可以在实践中使用微处理器或者数字信号处理器(dsp)来实现根据本申请实施例的电子设备定制模式的实现装置中的一些或者全部部件的一些或者全部功能。本申请还可以实现为用于执行这里所描述的方法的一部分或者全部的设备或者装置程序(例如，计算机程序和计算机程序产品)。这样的实现本申请的程序可以存储在计算机可读介质上，或者可以具有一个或者多个信号的形式。这样的信号可以从因特网网站上下载得到，或者在载体信号上提供，或者以任何其他形式提供。

例如，图4示出的电子设备400还包括处理器和被安排成存储计算机可执行指令(计算机可读程序代码)的存储器。存储器可以是诸如闪存、eeprom(电可擦除可编程只读存储器)、eprom、硬盘或者rom之类的电子存储器。存储器具有存储用于执行上述方法中的任何方法步骤的计算机可读程序代码的存储空间。例如，用于存储计算机可读程序代码的存储空间可以包括分别用于实现上面的方法中的各种步骤的各个计算机可读程序代码。计算机可读程序代码可以从一个或者多个计算机程序产品中读出或者写入到这一个或者多个计算机程序产品中。这些计算机程序产品包括诸如硬盘，紧致盘(cd)、存储卡或者软盘之类的程序代码载体。这样的计算机程序产品通常为计算机可读存储介质。图5示出了根据本申请一个实施例的一种计算机可读存储介质的结构示意图。该计算机可读存储介质500存储有用于执行根据本申请的方法步骤的计算机可读程序代码，可以被电子设备400的处理器读取，当计算机可读程序代码由电子设备400运行时，导致该电子设备400执行上面所描述的方法中的各个步骤，具体来说，该计算机可读存储介质存储的计算机可读程序代码可以执行上述任一实施例中示出的方法。计算机可读程序代码可以以适当形式进行压缩。

应该注意的是上述实施例对本申请进行说明而不是对本申请进行限制，并且本领域技术人员在不脱离所附权利要求的范围的情况下可设计出替换实施例。在权利要求中，不应将位于括号之间的任何参考符号构造成对权利要求的限制。单词“包含”不排除存在未列在权利要求中的元件或步骤。位于元件之前的单词“一”或“一个”不排除存在多个这样的元件。本申请可以借助于包括有若干不同元件的硬件以及借助于适当编程的计算机来实现。在列举了若干装置的单元权利要求中，这些装置中的若干个可以是通过同一个硬件项来具体体现。单词第一、第二、以及第三等的使用不表示任何顺序。可将这些单词解释为名称。