一种基于容器的多系统移动设备的背光灯控制方法和装置专利检索-内核操作系统系统软件软件计算机系统电脑零配件专利检索查询-专利查询网

一种基于容器的多系统移动设备的背光灯控制方法和装置

阅读：487发布：2024-02-16

专利汇可以提供一种基于容器的多系统移动设备的背光灯控制方法和装置专利检索，专利查询，专利分析的服务。并且本申请公开了一种基于容器的多系统移动设备的背光灯控制方法和装置，其中所述多系统包括前台系统和后台系统，前台系统和后台系统分别在不同容器中运行，所述方法包括：上层服务接收上层应用发出的调节背光灯亮度的请求；确定请求来自前台系统应用还是后台系统应用；对于来自前台系统应用的请求，响应于请求对所述移动设备的背光灯的亮度进行调节；对于来自后台系统应用的请求，忽略该请求。本申请还公开了一种对应的装置。本申请的方法和装置在基于容器的多系统中使背光灯能正常有序地响应于用户需求进行调节。，下面是一种基于容器的多系统移动设备的背光灯控制方法和装置专利的具体信息内容。

权利要求

1.一种基于容器的多系统移动设备的背光灯控制方法，所述多系统包括前台系统和后台系统，前台系统和后台系统分别在不同容器中运行，其特征在于，所述方法包括：
上层服务接收上层应用发出的调节背光灯亮度的请求；
确定请求来自前台系统应用还是后台系统应用；
对于来自前台系统应用的请求，响应于请求对所述移动设备的背光灯的亮度进行调节；对于来自后台系统应用的请求，忽略该请求。
2.根据权利要求1所述的方法，其特征在于，所述方法在确定请求来自前台系统应用还是后台系统应用之前还包括，将请求下发给内核驱动层，之后由背光灯驱动器判断请求是来自前台系统应用还是后台系统应用。
3.根据权利要求2所述的方法，其特征在于，确定请求来自前台系统应用还是后台系统应用基于请求所在进程的属性进行判断。
4.根据权利要求3所述的方法，其特征在于，确定请求来自前台系统应用还是后台系统应用基于请求所在进程的current属性中的nsproxy->dev_ns->active的值进行。
5.根据权利要求1所述的方法，其特征在于，在上层服务接收调节背光灯亮度的请求之前在上层服务中加入一个标签，所述标签标示服务处于休眠或激活状态。
6.根据权利要求5所述的方法，其特征在于，所述标签设置于父子进程的共享空间中，当所述标签的值与容器进程所属系统的值不同时，则确定所述请求来自后台；当所述标签的值与容器进程所属系统的值相同时，则确定所述请求来自前台。
7.一种基于容器的多系统移动设备的背光灯控制装置，所述多系统包括前台系统和后台系统，前台系统和后台系统分别在不同容器中运行，其特征在于，所述装置包括：
亮度调节请求接收单元，用于使上层服务接收上层应用发出的调节背光灯亮度的请求；
请求来源确定单元，用于确定请求来自前台系统应用还是后台系统应用；
请求响应单元，用于在请求来自前台系统应用时，响应于请求对所述移动设备的背光灯的亮度进行调节；及在请求来自后台系统应用时，忽略该请求。
8.根据权利要求7所述的装置，其特征在于，所述装置还包括请求下发单元，用于在请求来源确定单元确定请求来自前台系统应用还是后台系统应用之前将请求下发给内核驱动层；及其中所述请求来源确定单元为背光灯驱动器。
9.根据权利要求8所述的装置，其特征在于，所述背光灯驱动器基于请求所在进程的属性判断请求来自前台系统应用还是后台系统应用。

说明书全文

一种基于容器的多系统移动设备的背光灯控制方法和装置

技术领域

[0001] 本申请涉及电数字数据处理领域，尤其涉及一种在基于容器的多系统移动设备中对背光灯亮度进行控制的方法和装置。

背景技术

[0002] 背光灯主要用来控制液晶显示器亮度、键盘亮度。用户可以按照自己的视觉感受，将背光调整到合理的值，以满足各种不同具体情景的需求，从而提高用户体验。目前，手机系统对于背光灯的调控主要通过在驱动层提供背光设备节点、并进行硬件抽象层(HAL层)的层层抽象封装、上层配合相应的服务(service)管理、接口而进行调控。

[0003] 然而，在基于容器的多系统移动设备中，每个系统分别在不同容器中运行。由于背光灯的设备节点在基于容器的多系统中是唯一的，每个系统对于背光灯的管理策略和实现不同。在系统切换后，前台系统和后台系统对背光灯都可以控制，造成设备节点数据被覆盖，从而背光灯调节出现问题，不能达到预期的效果。发明内容

[0004] 本申请的目标在于提供一种在基于容器的多系统中使背光灯能正常有序的响应用户需求的方法和装置。

[0005] 本申请的目标由一种基于容器的多系统移动设备的背光灯控制方法实现，多系统包括前台系统和后台系统，前台系统和后台系统分别在不同容器中运行，该方法包括：

[0006] 上层服务接收上层应用发出的调节背光灯亮度的请求；

[0007] 确定请求来自前台系统应用还是后台系统应用；

[0008] 对于来自前台系统应用的请求，响应于请求对所述移动设备的背光灯的亮度进行调节；对于来自后台系统应用的请求，忽略该请求。

[0009] 优选地，在确定请求来自前台系统应用还是后台系统应用之前还包括，将请求下发给内核驱动层，之后由背光灯驱动器判断请求是来自前台系统应用还是后台系统应用。

[0010] 进一步优选地，确定请求来自前台系统应用还是后台系统应用基于请求所在进程的属性进行。

[0011] 本申请的目标还由一种基于容器的多系统移动设备的背光灯控制装置实现，多系统包括前台系统和后台系统，前台系统和后台系统分别在不同容器中运行，该装置包括：

[0012] 亮度调节请求接收单元，用于使上层服务接收上层应用发出的调节背光灯亮度的请求；

[0013] 请求来源确定单元，用于确定请求来自前台系统应用还是后台系统应用；

[0014] 请求响应单元，用于在请求来自前台系统应用时，响应于请求对所述移动设备的背光灯的亮度进行调节；及在请求来自后台系统应用时，忽略该请求。

[0015] 在基于容器的多系统下，多系统共用同一个内核(kernel)。为了减少切换系统重新启动service的开销及满足用户可以同时查看前后台系统的一些即时事件如来电信息、短消息等的需求，后台service是运行的，各种事件可以正常上报。本发明通过在处理中对各种事件的来源尤其是调节背光灯亮度的请求的来源加以区分，对于后台service发来的请求，不做任何操作，即不对背光灯的设备节点做写入操作；而对于来自前台系统的请求进行正常的处理流程，从而实现背光灯被前台实时控制的目的。而且，通过在kernel查看当前进程的属性，从而得知当前进程处在前或后台进程，可确保对后台系统service发来的请求完全不做处理。

[0016] 除非明确指出，在此所用的单数形式“一”、“该”均包括复数含义(即具有“至少一”的意思)。应当进一步理解，说明书中使用的术语“具有”、“包括”和/或“包含”表明存在所述的特征、步骤、操作、元件和/或部件，但不排除存在或增加一个或多个其他特征、步骤、操作、元件、部件和/或其组合。如在此所用的术语“和/或”包括一个或多个列举的相关项目的任何及所有组合。除非明确指出，在此公开的任何方法的步骤不必精确按照所公开的顺序执行。附图说明

[0017] 本发明将在下面参考附图并结合优选实施例进行更完全地说明。

[0018] 图1为根据本发明方法的一实施例的流程图。

[0019] 图2为根据本发明方法的另一实施例的流程图。

[0020] 图3为根据本发明装置的一实施例的结构示意图。

[0021] 图4为根据本发明装置的另一实施例的结构示意图。

[0022] 为清晰起见，这些附图均为示意性及简化的图，它们只给出了对于理解本发明所必要的细节，而省略其他细节。

具体实施方式

[0023] 通过下面给出的详细描述，本发明的适用范围将显而易见。然而，应当理解，在详细描述和具体例子表明本发明优选实施例的同时，它们仅为说明目的给出。

[0024] 在基于容器的多系统移动设备如手机中，容器作为操作系统环境内设备可以独立运行的一个子操作系统，子操作系统拥有自己的主界面、启动程序、应用程序以及各种小部件。当各个操作系统即前台系统和后台系统都提出调节背光灯亮度的请求时，就会造成系统冲突从而导致背光灯无法正常使用。本发明方法在系统切换时，被置为前台的service根据配置，更新一下背光灯的亮度。之后，通过区分背光灯的操作请求来源于前台还是后台而实现背光灯调节的有序控制。

[0025] 图1示出了本发明方法的一实施例，其开始于步骤S10，上层应用发出调节背光灯亮度的请求，上层服务接收上层应用发出的调节背光灯亮度的请求。如果前台系统的多个应用同时请求调节背光灯亮度，设备在驱动层有自旋锁，只有最先拿到锁的进程可以操作设备，当拿锁进程操作背光灯完成后释放该锁，其他应用可以拿锁进行相应的其他操作。之后，处理进行到步骤S20，无论请求是来自于前台系统应用还是后台系统应用，走正常流程，对请求进行正常的HAL层(硬件抽象层)和Framework层(框架层)处理。之后，处理进行到步骤S30，将经过上层处理的请求下发给内核驱动层。之后，处理进行到步骤S40，在背光灯驱动器中判断请求是来自前台系统应用还是后台系统应用。在实施例中，请求来源的判断基于请求所在进程的属性进行。由于每个容器的子系统所处的命名空间不同，进程的current属性中的nsproxy->dev_ns->active的值不同，处于前台时该值为1，处于后台时该值为零，从而从该值判断出当前的进程是属于前台还是后台。如果调节背光灯亮度的请求来自于前台系统应用，则处理进行到步骤S50，走正常的流程，对背光灯设备节点拥有正常的读写权限，即响应于请求对移动设备的背光灯的亮度进行调节。否则，如果调节背光灯亮度的请求来自于后台系统应用，处理进行到步骤S60，忽略该请求，即绕开后面的处理流程，不对设备做任何操作，并使处理返回到步骤S10。在步骤S50之后，处理结束。这样，避免了前台系统应用和后台系统应用同时要求调节背光灯亮度时的冲突，也避免了后台系统应用干扰前台系统应用所需背光灯亮度的问题。通过在kernel查看当前进程的属性，从而得知当前进程处在前或后台进程，可确保对后台系统service发来的请求完全不做处理。

[0026] 图2示出了本发明方法的另一实施例，其开始于步骤S05，在上层服务中加入一个标签，该标签标示服务(service)当前的状态即休眠或激活状态。由于多容器系统是处于一个父进程的命名空间，在父子进程的共享空间设置一个公共变量标签，各容器进程(子进程)都可通过读取该共享标签确定当前的前台是哪个系统，是否是进程本身所属的系统，从而自身决定是否可以下发对背光的请求操作。如果标签的值与进程所属系统的值不同则说明其属于后台，保持静默，否则处在前台，正常下发请求。当系统切换时，即将进入后台的service的标签置为休眠状态值，即将进入前台的service把标签置为激活状态值。之后，处理进行到步骤S10，上层应用发出调节背光灯亮度的请求，上层服务接收上层应用发出的调节背光灯亮度的请求。之后，处理进行到步骤S15，根据service的标签的值确定调节背光灯亮度的请求的来源。在服务的标签处于休眠状态时，确定请求来自后台系统；及在服务的标签处于激活状态时，确定请求来自前台系统。之后，如果调节背光灯亮度的请求来自于前台系统应用，则处理进行到步骤S50，走正常的流程，对背光灯设备节点拥有正常的读写权限，即响应于请求对移动设备的背光灯的亮度进行调节。否则，如果调节背光灯亮度的请求来自于后台系统应用，处理进行到步骤S60，忽略该请求，即绕开后面的处理流程，不对设备做任何操作，并使处理返回到步骤S10。在步骤S50之后，处理结束。

[0027] 图3示出了本发明装置的一实施例，其用于在基于容器的多系统移动设备中对背光灯亮度进行控制，所述多系统包括前台系统和后台系统，前台系统和后台系统分别在不同容器中运行，该装置包括：亮度调节请求接收单元10，用于使上层服务接收上层应用发出的调节背光灯亮度的请求；请求下发单元20，用于将请求下发给内核驱动层；请求来源确定单元30，在此为背光灯驱动器，用于基于请求所在进程的属性确定请求来自前台系统应用还是后台系统应用；请求响应单元40，用于在请求来自前台系统应用时，响应于请求对所述移动设备的背光灯的亮度进行调节；及在请求来自后台系统应用时，忽略该请求。

[0028] 图4示出了本发明装置的一实施例，其用于在基于容器的多系统移动设备中对背光灯亮度进行控制，所述多系统包括前台系统和后台系统，前台系统和后台系统分别在不同容器中运行，该装置包括：服务状态赋值单元05，用于在系统切换时，使即将进入后台的service的状态标签赋值为休眠状态值，及使即将进入前台的service的状态标签赋值为激活状态值。亮度调节请求接收单元10，用于使上层服务接收上层应用发出的调节背光灯亮度的请求；请求来源确定单元30’，用于基于服务的状态标签值确定请求来自前台系统应用还是后台系统应用；请求响应单元40，用于在请求来自前台系统应用时，响应于请求对所述移动设备的背光灯的亮度进行调节；及在请求来自后台系统应用时，忽略该请求。

[0029] 一些优选实施例已经在前面进行了说明，但是应当强调的是，本发明不局限于这些实施例，而是可以本发明主题范围内的其它方式实现。

标题	发布/更新时间	阅读量
一种中断处理方法、系统及计算机可读存储介质	2020-05-25	1
通过云文件系统实现云存储接入的方法和装置	2020-08-14	2
具有变斜率全浓度梯度的锂离子电池正极材料及其合成方法	2020-12-19	1
一种基于ARM9的海底观测网节点电路	2021-03-13	1
内存分配方法和装置	2022-05-01	0
一种粗粒度可重构层次化的阵列寄存器文件结构	2022-12-28	0
numa架构下的报文转发方法、装置、存储介质及电子设备	2021-02-07	1
一种分布式实时存储装置及其数据传输方法	2020-08-05	2
基于哈希算法的千万级网络会话表管理方法、系统、介质和设备	2020-09-24	1
一种旅游随身健康终端	2021-10-12	1

一种基于容器的多系统移动设备的背光灯控制方法和装置

一种基于容器的多系统移动设备的背光灯控制方法和装置

技术领域

背景技术

具体实施方式

该功能需要专业版企业版VIP权限，您可以：