发明内容
本发明实施例提供一种对应用数据进行处理的方法和计算节点,用以解决在计算节点不具有root操作权限并且计算节点上的应用软件不提供Provider接口时完成数据备份及恢复。
本发明实施例提供了一种对应用数据进行处理的方法,应用于计算节点,该计算节点包括操作系统,运行在所述操作系统之上的服务进程,备份软件和应用软件,包括:
所述操作系统开启服务进程;
所述操作系统建立所述服务进程与所述备份软件之间的套接字socket连接,所述服务进程具有根root操作权限,且所述服务进程与所述备份软件具有相同的用户标识uid;
所述备份软件通过所述套接字发送针对应用数据的处理请求;
所述服务进程通过所述套接字接收所述备份软件发送的针对应用数据的处理请求;
所述服务进程将所述针对应用数据的处理请求发送给对应的应用软件;
所述服务进程接收所述对应的应用软件返回的应用数据;其中,所述应用数据是针对所述处理请求返回的应用数据;
所述服务进程将所述返回的应用数据通过所述套接字发送给所述备份软件。
本发明实施例提供了一种计算节点,该计算节点包括硬件层以及运行在硬件层上的操作系统,运行在所述操作系统之上的服务进程,备份软件和应用软件,包括:
开启模块,用于所述操作系统开启服务进程;
建立连接模块,用于所述操作系统建立所述服务进程与所述备份软件之间的套接字socket连接,所述服务进程具有根root操作权限,且所述服务进程与所述备份软件具有相同的用户标识uid;
第一发送模块,用于所述备份软件通过所述套接字发送针对应用数据的处理请求;
第一接收模块,用于所述服务进程通过所述套接字接收所述备份软件发送的针对应用数据的处理请求;
第二发送模块,用于所述服务进程将所述针对应用数据的处理请求发送给对应的应用软件;
第二接收模块,用于所述服务进程接收所述对应的应用软件返回的应用数据;其中,所述应用数据是针对所述处理请求返回的应用数据;
第三发送模块,用于所述服务进程将所述返回的应用数据通过所述套接字发送给所述备份软件。
由上述技术方案可知,本发明实施例通过开启服务进程,由于该服务进程具有root操作权限,可以保证该服务进程可以访问计算节点内的各种应用软件,又由于该服务进程与备份软件建立了socket连接且两者具有相同的uid,可以保存服务进程和备份软件之间交互,因此,通过服务进程,备份软件可以与应用软件交互,进而实现备份软件对应用软件内的应用数据的备份或恢复。
具体实施方式
为使本发明实施例的目的、技术方案和优点更加清楚,下面将结合本发明实施例中的附图,对本发明实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例是本发明一部分实施例,而不是全部的实施例。基于本发明中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都属于本发明保护的范围。
图1为本发明对应用数据进行处理的方法一实施例的流程示意图,包括:
步骤11:操作系统开启服务进程。
步骤12:操作系统建立所述服务进程与所述备份软件之间的套接字(socket)连接,所述服务进程具有根(root)操作权限,且所述服务进程与所述备份软件具有相同的用户标识(User Identifier,uid)。
本发明实施例中,以计算节点为Android手机为例,该Andriod手机可以不具有root操作权限,此时该手机内的备份软件不能直接与应用软件交互,从应用软件中获取数据。另外,该Andriod手机也可以不需要应用软件提供Provider接口,此时同样手机内的备份软件不能直接从应用软件中获取数据。
在Andriod手机不具有root操作权限且应用软件不提供Provider接口时,为了实现对应用软件的应用数据的备份和恢复,本发明实施例可以在手机底层开启一个进程,该进程可以称为服务(Service)进程。
该服务进程可以是启动上述备份软件的同时被启动,也可以是启动备份软件中的特定功能后被启动。其中,该服务进程的的具体实现方式是在手机底层可以用C代码实现一个linux进程,通过init.rc启动起来该linux进程,linux进程可以称为Service进程。具体地,可以自定义一个service进程名,并给该service进程指定一个特定的操作权限,让它具有对应用数据的读写删等操作权限,同时给该进程指定一个特殊的UID,以便于备份软件进行通信。该进程与普通的进程的区别在于:指定了特定的操作权限,指定了特殊的UID。
此外,通常来讲,在开启进程的过程中可以设置开启的进程对应的操作权限和进程的uid。本发明实施例中,参见图2,该开启的服务进程的操作权限设置为root操作权限,以及进程的uid与备份软件的uid相同。
通过将服务进程的操作权限设置为root操作权限可以保证服务进程能够与计算节点内的每种应用软件及备份软件进行交互,这样服务进程可以从应用软件内读取应用数据,将读取的应用数据写入备份软件中,也可以将应用数据从备份软件写入应用软件内。通过将服务进程的uid设置为与备份软件的uid相同,可以保证服务进程与备份软件在通过套接字建立连接后能够进行交互,这样服务进程可以将应用数据发送给备份软件,也可以接收备份软件发送的应用数据。例如,可以通过命令socket/dev/socket/fileback来建立服务进程和备份软件的连接。
步骤13:所述备份软件通过所述套接字发送针对应用数据的处理请求;
步骤14:所述服务进程通过所述套接字接收所述备份软件发送的针对应用数据的处理请求;
步骤15:所述服务进程将所述针对应用数据的处理请求发送给对应的应用软件;
步骤16:所述服务进程接收所述对应的应用软件返回的应用数据;
步骤17:所述服务进程将所述返回的应用数据通过所述套接字发送给所述备份软件。
其中,参见图2,备份软件与服务进程可以通过socket连接进行交互,服务进程由于具有root操作权限可以与应用软件交互。
备份软件、服务进程和应用软件之间交互的具体命令、数据等可以根据是要备份数据还是恢复数据有所不同,具体交互流程可以参见后续针对备份、恢复的流程。
进一步地,为了保证安全性,可以将备份软件与服务进程之间的接口,以及服务进程与应用软件之间的接口设置为受签名保护,此时,需要首先对接收的消息进行签名验证,在验证通过后再进行处理。例如,服务进程通过所述套接字接收所述备份软件发送的针对应用数据的处理请求;服务进程对所述处理请求进行签名验证,签名验证通过后,将所述针对应用数据的处理请求发送给对应的应用软件。又例如,应用软件接收到服务进程的处理请求后,先进行签名验证,验证通过后将自身的应用数据发送给服务进程。又例如,备份软件接收到服务进程返回的应用数据时,先进行签名验证,签名验证通过后保存应用数据。
本实施例通过开启服务进程,由于该服务进程具有root操作权限,可以保证该服务进程可以访问计算节点内的各种应用软件,又由于该服务进程与备份软件建立了socket连接且两者具有相同的uid,可以保存服务进程和备份软件之间交互,因此,通过服务进程,备份软件可以与应用软件交互,进而实现备份软件对应用软件内的应用数据的备份以及恢复。
图3为本发明对应用数据进行处理的方法另一实施例的流程示意图,本实施例以备份流程为例。由于备份软件与服务进程交互信息需要首先建立连接,因此,可以理解的是,本实施例包括的如下步骤是在开启服务进程,并建立服务进程与备份之间的套接字连接之后。
针对应用数据的处理请求包括读目录请求或读文件请求,则对应的应用软件返回的应用数据包括读取的目录信息或读取的文件内容,下面针对读取应用数据的整个流程进行详细说明。
参见图3,包括:
步骤31:备份软件通过套接字连接向服务进程发送读目录请求。
其中,备份软件向服务进程发送命令字和参数时,可以首先向服务进程发送命令字和参数的长度,之后再发送命令字和参数的具体内容。
例如,发送读目录请求时,该读目录请求可以表达为opendir+catalogue,这里的“opendir”是命令字,“catalogue”为目录路径参数。此时,可以首先发送“opendir+catalogue”的长度,该长度可以采用16位无符号整数(unsignedshort 16bit)形式表达,之后,再发送“opendir+catalogue”。
步骤32:服务进程根据读目录请求向对应的应用软件发送读目录请求。
其中,服务进程可以根据接收的命令字和参数的长度,读取相应长度的内容确定为命令字和参数的具体内容,也就是确定出读目录请求的具体内容。
例如,读目录请求中会携带目录的信息,如上述的目录路径参数catalogue,服务进程可以根据该目录的信息获取目录的句柄,之后向该句柄指示的应用软件发送读目录请求。
步骤33:应用软件向服务进程返回结果。
其中,返回的结果可以是该目录下所有文件及相关属性。例如,备份软件发送的读目录请求是要读取A应用软件的目录,则A应用软件向服务进程返回A应用软件包括的目录,如目录1包括的文件信息、目录2包括的文件信息、目录3包括的文件信息等。可以理解的是,由于读目录请求通常是每次读取一个目录,因此,返回的结果通常是一个目录的相关信息。
步骤34:服务进程通过套接字连接向备份软件发送读取的内容。
其中,该读取的内容可以就是上述应用向服务进程返回的结果中包含的目录的信息,如目录1包括的文件信息、目录2包括的文件信息、目录3包括的文件信息等。
此外,服务进程可以将读取的内容先存储在缓存(buffer)中,之后再将缓存中存储的数据,也就是读取的内容发送给备份软件。其中,该缓存可以理解为是存储数据的数据区。
另外,服务进程可以首先发送读取的内容的长度,该长度可以采用16位无符号整数(unsigned short 16bit)形式表达,之后再将读取的内容发送给备份软件。备份软件根据读取的内容的长度在读取对应长度的数据,之后备份软件可以对读取的数据进行备份处理。
步骤35:备份软件向服务进程发送读文件请求。
类似于读目录请求,备份软件可以首先发送读文件请求的长度,之后再发送具体的读文件请求的内容。
步骤36:服务进程向对应的应用软件发送读文件请求。
其中,备份软件发送的读文件请求中会携带文件信息,例如,读文件请求为open+文件路径,其中的文件路径可以表明要打开的文件的路径信息。之后,服务进行可以向读文件请求中的文件路径找到对应的应用软件。
步骤37:应用软件向服务进程返回结果。
其中,返回的结果可以包括文件的内容相关信息,例如文件的内容、文件的格式、文件的操作权限等。
步骤38:服务进程向备份软件返回文件的内容。
例如,返回的文件的内容包括:文件的内容、文件的格式、文件的操作权限等。
本实施例通过开启服务进程,可以由服务进程从应用软件内读取数据并发送给备份软件,由备份软件对数据进行备份,实现数据的备份处理。
图4为本发明对应用数据进行处理的方法另一实施例的流程示意图,本实施例以恢复流程为例。由于备份软件与服务进程交互信息需要首先建立连接,因此,可以理解的是,本实施例包括的如下步骤是在开启服务进程,并建立服务进程与备份软件之间的套接字连接之后。
针对应用数据的处理请求包括写目录请求或写文件请求,则对应的应用软件返回的应用数据包括与写目录请求对应的结果或与写文件请求对应的结果,下面针对恢复应用数据的整个流程详细说明。
参见图4,包括:
步骤41:备份软件通过套接字连接向服务进程发送写目录请求。
其中,发送写目录请求时,备份软件可以类似对读目录请求的处理,先发送写目录请求的长度再发送写目录请求的具体内容。
另外,写目录请求的具体内容中可以包括每个目录包括的文件信息,例如,目录包括目录1、目录2、目录3…,目录1包括文件1、文件2,…。可选的,由于写目录通常是每次写一个,因此,上述的写目录请求中通常包含一个目录的信息,例如,写目录请求格式为:writeDir+目录名。另外,也可以将多个目录放到同一个请求中,使用特殊字符分隔开来,例如,写目录请求格式为:writeDir+目录名1;目录名2;目录名3。
步骤42:服务进程根据写目录请求向对应的应用软件发送写目录请求。
其中,服务进程可以根据写目录请求中包含的目录名确定对应的句柄,之后向对以的句柄指示的应用发送写目录请求,其中可以包含目录中包含的文件信息。
例如,向应用A发送写目录请求,写目录请求中携带包括目录1、目录2、目录3…,目录1包括文件1、文件2,…。
步骤43:应用软件向服务进程返回结果。
步骤44:服务进程向备份软件返回结果。
其中,步骤43-44中的结果可以为表明是否写目录成功的信息。
步骤45:备份软件向服务进程发送写文件请求。
其中,写文件请求的格式可以为write+文件名+文件内容。
文件内容可以是备份软件采用图3所示的方式已经备份的数据。
步骤46:服务进程向对应的应用软件发送的写文件请求。
其中,服务进程接收到写文件请求后可以根据文件名确定对应的目录,例如,通过来讲对各目录的操作是串行的,当前只是针对某个目录进行操作,则如果当前对B目录进行写操作,则服务进程向B目录对应的A应用发送写文件请求。可选的,如果各目录的写操作可以并行进行,各目录对应的文件名又可以相同,那么备份软件发送的写文件请求中也可以携带目录的信息,以便向正确的目录中写入对应的文件内容。
步骤47:应用软件向服务进程返回结果。
步骤48:服务进程向备份软件返回结果。
其中,步骤47-48中的结果可以为表明是否写文件成功的信息。在完成恢复之后,可以解除套接字连接,并关闭服务进程。
其中,可以由备份软件确定了恢复操作完成后,去指示服务进程去关闭,例如采用命令close+目录和/或文件路径。
本实施例通过开启服务进程,可以由服务进程接收备份软件备份的数据,并将备份的数据发送给应用软件,实现数据的恢复处理。
图5为本发明计算节点的一实施例的结构示意图,包括开启模块51、建立连接模块52、第一发送模块53、第一接收模块54、第二发送模块55、第二接收模块56和第三发送模块57;开启模块51用于开启服务进程;建立连接模块52用于建立所述服务进程与所述备份软件之间的套接字socket连接,所述服务进程具有根root操作权限,且所述服务进程与所述备份软件具有相同的用户标识uid;第一发送模块53用于所述备份软件通过所述套接字发送针对应用数据的处理请求;第一接收模块54用于所述服务进程通过所述套接字接收所述备份软件发送的针对应用数据的处理请求;第二发送模块55用于所述服务进程将所述针对应用数据的处理请求发送给对应的应用软件;第二接收模块56用于所述服务进程接收所述对应的应用软件返回的应用数据;第三发送模块57用于所述服务进程将所述返回的应用数据通过所述套接字发送给所述备份软件。
需要说明的是,开启模块51、建立连接模块52可以由操作系统完成,第一发送模块53可以由备份软件完成,第一接收模块54、第二发送模块55、第二接收模块56、第三发送模块57可以由服务进程完成。
可选的,参见图6,第一发送模块包括第一发送单元61和第二发送单元62;第一发送单元61用于所述备份软件通过所述套接字发送针对应用数据的处理请求的长度;第二发送单元62所述备份软件通过所述套接字发送与所述长度对应的针对应用数据的处理请求的具体内容。
可选的,参见图7,第三发送模块包括第三发送单元71和第四发送单元72;第三发送单元71用于所述服务进程将所述返回的应用数据的长度通过所述套接字发送给所述备份软件;第四发送单元72所述服务进程将所述返回的应用数据的具体内容通过所述套接字发送给所述备份软件。
可选的,参见图8,第二发送模块包括验证单元81和第五发送单元82;验证单元81用于服务进程对所述处理请求进行签名验证;第五发送单元82用于若通过签名验证,则将所述针对应用数据的处理请求发送给对应的应用软件。
本实施例通过开启服务进程,由于该服务进程具有root操作权限,可以保证该服务进程可以访问计算节点内的各种应用软件,又由于该服务进程与备份软件建立了socket连接且两者具有相同的uid,可以保证服务进程和备份软件之间的交互,因此,通过服务进程,备份软件可以与应用软件交互,进而实现备份软件对应用软件内的应用数据的备份以及恢复。
需要说明的是,上述计算节点可以是移动终端,该移动终端可以完成上述实施例中的备份和恢复功能,在此不再赘述。
本领域普通技术人员可以理解:实现上述方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成,前述的程序可以存储于一计算机可读取存储介质中,该程序在执行时,执行包括上述方法实施例的步骤;而前述的存储介质包括:ROM、RAM、磁碟或者光盘等各种可以存储程序代码的介质。
最后应说明的是:以上实施例仅用以说明本发明的技术方案,而非对其限制;尽管参照前述实施例对本发明进行了详细的说明,本领域的普通技术人员应当理解:其依然可以对前述各实施例所记载的技术方案进行修改,或者对其中部分技术特征进行等同替换;而这些修改或者替换,并不使相应技术方案的本质脱离本发明各实施例技术方案的范围。