著录项信息
专利名称 | 系统恢复方法和系统恢复装置 |
申请号 | CN201310753474.9 | 申请日期 | 2013-12-31 |
法律状态 | 授权 | 申报国家 | 中国 |
公开/公告日 | 2014-04-02 | 公开/公告号 | CN103699420A |
优先权 | 暂无 | 优先权号 | 暂无 |
主分类号 | G06F9/445 | IPC分类号 | G;0;6;F;9;/;4;4;5查看分类表>
|
申请人 | 海信集团有限公司 | 申请人地址 | 山东省青岛市崂山区株洲路151号
变更
专利地址、主体等相关变化,请及时变更,防止失效 |
权利人 | 海信集团有限公司 | 当前权利人 | 海信集团有限公司 |
发明人 | 刘承龙 |
代理机构 | 北京友联知识产权代理事务所(普通合伙) | 代理人 | 尚志峰;汪海屏 |
摘要
本发明提供了一种系统恢复方法和一种系统恢复装置,其中所述系统恢复方法包括:获取启动的应用程序的包名;判断所述应用程序是否是安装之后第一次运行;在确定所述应用程序是安装之后第一次运行时,将所述应用程序的包名保存在清除列表中;在接收到恢复出厂设置的指令时,根据所述清除列表中包含的应用程序包名,清除相应应用程序的用户数据。本发明能够动态跟踪应用程序运行,生成需要清理数据的应用程序列表,以在恢复出厂设置时清除应用程序使用的痕迹和用户数据,不需要重新启动系统,也不需要格式化数据分区,就可以完成恢复出厂设置,减少了恢复出厂设置的消耗时间。
1.一种系统恢复方法,其特征在于,包括:
获取启动的应用程序的包名;
判断所述应用程序是否是安装之后第一次运行;
在确定所述应用程序是安装之后第一次运行时,将所述应用程序的包名保存在清除列表中;
在接收到恢复出厂设置的指令时,根据所述清除列表中包含的应用程序包名,清除相应应用程序的用户数据。
2.根据权利要求1所述的系统恢复方法,其特征在于,在获取所述应用程序的包名之后,还包括:
调用系统日志,根据所述系统日志判断所述应用程序是否是当日首次运行,若是当日首次运行,则判断所述应用程序是否是安装之后第一次运行。
3.根据权利要求1所述的系统恢复方法,其特征在于,所述判断所述应用程序是否是安装之后第一次运行的步骤包括:
判断所述应用程序的包名是否保存在所述清除列表中,若未保存在所述清除列表中,则确定所述应用程序是安装之后第一次运行。
4.根据权利要求3所述的系统恢复方法,其特征在于,还包括:
获取预设的第一名单,将所述第一名单中的应用程序的包名加入所述清除列表中,其中,所述第一名单保存有会产生用户数据的应用程序的包名;
获取预设的第二名单,将所述第二名单中的应用程序包名与所述清除列表中的应用程序包名进行匹配,从所述清除列表中删除与所述第二名单中的应用程序包名相匹配的应用程序包名,其中,所述第二名单保存有不会产生用户数据的应用程序的包名。
5.根据权利要求1至4中任一项所述的系统恢复方法,其特征在于,在接收到所述恢复出厂设置的指令时,还包括清除外设的设置数据;
为清除所述相应应用程序的用户数据的任务和清除所述外设的设置数据的任务分配相应的清除线程。
6.一种系统恢复装置,其特征在于,包括:
获取单元,用于获取启动的应用程序的包名;
第一判断单元,连接至所述获取单元,用于判断所述应用程序是否是安装之后第一次运行;
清除列表生成单元,用于在所述第一判断单元确定所述应用程序是安装之后第一次运行时,将所述应用程序的包名保存在清除列表中;
系统恢复单元,用于在接收到恢复出厂设置的指令时,根据所述清除列表中包含的应用程序包名,清除相应应用程序的用户数据。
7.根据权利要求6所述的系统恢复装置,其特征在于,还包括:
第二判断单元,用于在所述获取单元获取所述应用程序的包名之后,调用系统日志,根据所述系统日志判断所述应用程序是否是当日首次运行,若是当日首次运行,则判断所述应用程序是否是安装之后第一次运行。
8.根据权利要求6所述的系统恢复装置,其特征在于,所述第一判断单元还用于判断所述应用程序的包名是否保存在所述清除列表中,若未保存在所述清除列表中,则确定所述应用程序是安装之后第一次运行。
9.根据权利要求8所述的系统恢复装置,其特征在于,还包括:
第一更新单元,用于获取预设的第一名单,将所述第一名单中的应用程序的包名加入所述清除列表中,其中,所述第一名单保存有会产生用户数据的应用程序的包名;
第二更新单元,用于获取预设的第二名单,将所述第二名单中的应用程序包名与所述清除列表中的应用程序包名进行匹配,从所述清除列表中删除与所述第二名单中的应用程序包名相匹配的应用程序包名,其中,所述第二名单保存有不会产生用户数据的应用程序的包名。
10.根据权利要求6至9中任一项所述的系统恢复装置,其特征在于,所述系统恢复单元在接收到所述恢复出厂设置的指令时,还用于清除外设的设置数据;
所述系统恢复单元包括:
线程分配单元,用于为清除所述相应应用程序的用户数据的任务和清除所述外设的设置数据的任务分配相应的清除线程。
系统恢复方法和系统恢复装置\n技术领域\n[0001] 本发明涉及计算机技术领域,具体而言,涉及一种系统恢复方法和一种系统恢复装置。\n背景技术\n[0002] 在使用电子设备过程中,由于人机交互会产生一系列的使用痕迹,该使用痕迹包括但不限于系统设置(包括系统语言、亮度、音量、网络设置等)、账号信息、下载的文件和资源、业务相关的数据(如联系人、通话记录、相片、电视频道列表等)、应用程序的设置、下载安装的非预置应用程序。对电子设备进行出厂设置是指在不重新烧写或安装系统软件的情况下,通过软件操作,清理上述使用痕迹,使电子设备的状态与在第一次安装系统软件时的状态一致。\n[0003] 在使用Android操作系统的终端设备上,由分区管理机制和应用管理机制决定,产生的使用痕迹一般都存储在data分区,每个应用的数据被分别存放在data分区下,以“com/com/”加“程序包名”为名称的目录下。Android操作系统提供了一种MasterClear方法,重启系统进入Recovery模式,并格式化data分区,进而将使用痕迹全部清空。此方法需要重启终端设备,并且将程序解析和链接库优化后的正常信息文件也一并删除,其清理工作耗时比较长,而清理完成后的第一次启动时间更加漫长。根据在几款Android产品上的实测,此方法恢复出厂设置的时间约为15秒到20秒,清理后第一次启动的时间约为40秒到两分钟,然后系统才能正常使用。\n[0004] 因此,如何缩短电子设备恢复出厂设置的时间成为亟待解决的技术问题。\n发明内容\n[0005] 本发明正是基于上述技术问题,提出了一种新的系统恢复技术,动态生成产生使用痕迹的应用程序列表,根据应用程序列表来清除应用程序的使用痕迹,缩短了恢复出厂设置时间。\n[0006] 有鉴于此,根据本发明的一个方面,提供了一种系统恢复方法,包括:获取启动的应用程序的包名;判断所述应用程序是否是安装之后第一次运行;在确定所述应用程序是安装之后第一次运行时,将所述应用程序的包名保存在清除列表中;在接收到恢复出厂设置的指令时,根据所述清除列表中包含的应用程序包名,清除相应应用程序的用户数据。\n[0007] 通过该技术方案,将安装之后第一次启动的应用程序包名加入到清除列表中,在接收到恢复出厂设置指令时,根据清除列表中包含的应用程序包名,清除相应应用程序的用户数据(包括卸载非预装应用程序,以及删除使用应用程序时产生的数据),就可实现恢复出厂设置,对于不在该应用程序列表中的应用程序就可以在恢复过程中被忽略,以节省处理时间,并且无需重新启动系统以及对系统中的数据分区进行格式化,从而使恢复出厂操作的时间被大大减少。除此之外,在应用程序在第一次被运行时就将该应用程序的包名加入清除列表,无需在应用程序每次运行时都进行一次写入操作,也简化了清除列表的生成过程,并且不会使应用程序的包名在清除列表中重复出现,从而避免了在恢复出厂设置时的重复操作。\n[0008] 根据本发明的另一方面,还提出了一种系统恢复装置,包括:获取单元,用于获取启动的应用程序的包名;第一判断单元,连接至所述获取单元,用于判断所述应用程序是否是安装之后第一次运行;清除列表生成单元,用于在所述第一判断单元确定所述应用程序是安装之后第一次运行时,将所述应用程序的包名保存在清除列表中;系统恢复单元,用于在接收到恢复出厂设置的指令时,根据所述清除列表中包含的应用程序包名,清除相应应用程序的用户数据。\n[0009] 通过该技术方案,将安装之后第一次启动的应用程序包名加入到清除列表中,在接收到恢复出厂设置指令时,根据清除列表中包含的应用程序包名,清除相应应用程序的用户数据(包括卸载非预装应用程序,以及删除使用应用程序时产生的数据),就可实现恢复出厂设置,对于不在该应用程序列表中的应用程序就可以在恢复过程中被忽略,以节省处理时间,并且无需重新启动系统以及对系统中的数据分区进行格式化,从而使恢复出厂操作的时间被大大减少。除此之外,在应用程序在第一次被运行时就将该应用程序的包名加入清除列表,无需在应用程序每次运行时都进行一次写入操作,也简化了清除列表的生成过程,并且不会使应用程序的包名在清除列表中重复出现,从而避免了在恢复出厂设置时的重复操作。\n附图说明\n[0010] 图1示出了根据本发明的一个实施例的系统恢复方法的示意图;\n[0011] 图2示出了根据本发明的一个实施例的清除列表生成方法的流程图;\n[0012] 图3示出了根据本发明的一个实施例的系统恢复装置的框图。\n具体实施方式\n[0013] 为了能够更清楚地理解本发明的上述目的、特征和优点,下面结合附图和具体实施方式对本发明进行进一步的详细描述。需要说明的是,在不冲突的情况下,本申请的实施例及实施例中的特征可以相互组合。\n[0014] 在下面的描述中阐述了很多具体细节以便于充分理解本发明,但是,本发明还可以采用其他不同于在此描述的其他方式来实施,因此,本发明的保护范围并不受下面公开的具体实施例的限制。\n[0015] 图1示出了根据本发明的一个实施例的系统恢复方法的示意图。\n[0016] 如图1所示,根据本发明的实施例的系统恢复方法可以包括以下步骤,步骤102:获取启动的应用程序的包名;步骤104:判断所述应用程序是否是安装之后第一次运行;步骤\n106:在确定所述应用程序是安装之后第一次运行时,将所述应用程序的包名保存在清除列表中;步骤108:在接收到恢复出厂设置的指令时,根据所述清除列表中包含的应用程序包名,清除相应应用程序的用户数据。\n[0017] 将安装之后第一次启动的应用程序包名加入到清除列表中,在接收到恢复出厂设置指令时,根据清除列表中包含的应用程序包名,清除相应应用程序的用户数据(包括卸载非预装应用程序,以及使用应用程序时产生的数据),就可实现恢复出厂设置,对于不在该应用程序列表中的应用程序就可以在恢复过程中被忽略,以节省处理时间,并且无需重新启动系统以及对系统中的数据分区进行格式化,从而使恢复出厂操作的时间被大大减少。\n除此之外,在应用程序在第一次被运行时就将该应用程序的包名加入清除列表,无需在应用程序每次运行时都进行一次写入操作,也简化了清除列表的生成过程,并且不会使应用程序的包名在清除列表中重复出现,从而避免了在恢复出厂设置时的重复操作。\n[0018] 在上述技术方案中,优选的,在获取所述应用程序的包名之后,还可以包括:调用系统日志,根据所述系统日志判断所述应用程序是否是当日首次运行,若是当日首次运行,则判断所述应用程序是否是安装之后第一次运行。\n[0019] 当系统调用应用程序界面时,系统日志会记录下应用程序被调用时的时间和应用界面名称等信息,而系统日志只能存储当天的应用程序运行记录,当日期发生变更时,会直接删除前期记录重新开始记录,因此如果直接使用目前的系统日志将不能得到准确的清除列表。为了解决这个问题,在本实施例中,在获取到启动的应用程序的包名时,利用该系统日志,与系统日志中记录的当天运行过的应用程序进行比对,如果所述应用程序本日已经运行过,则说明所述应用程序包名已经加入清除列表,无需将该应用程序的包名传递给清除列表。这样就可以减少重复调用,加快程序运行速度。如果所述应用程序本日首次运行,则将该应用程序包名传递给清除列表,由列表管理服务来决定是否将该应用程序包名加入清除列表。虽然应用程序为当日首次运行,但其也可能在当日之前运行过,那么就需要查询所述应用程序是否安装之后第一次运行,以确定所述应用程序是否需要加入清除列表中。\n[0020] 在上述任一技术方案中,优选的,所述判断所述应用程序是否是安装之后第一次运行的步骤包括:判断所述应用程序的包名是否保存在所述清除列表中,若未保存在所述清除列表中,则确定所述应用程序是安装之后第一次运行。\n[0021] 由于清除列表中记录着调用过的应用程序的包名,故判断当日首次运行的应用程序是否为安装之后第一次运行,需要查询清除列表中有无所述应用程序的包名。如果清除列表中包含所述应用程序包名,则说明该应用程序在本日之前运行过,不是安装之后第一次运行,则无需将所述应用程序包名加入清除列表;相反的,如果清除列表中不包含所述应用程序包名,则说明该应用程序为安装之后第一次运行,需要将所述应用程序包名加入清除列表中。\n[0022] 通过清除列表判断调用的应用程序是否为安装之后第一次运行,可保证清除列表中相同的应用程序不会被重复记录,当收到恢复出厂指令执行清除操作时,无需做重复检查工作,减少恢复出厂设置的时间。\n[0023] 本领域的技术人员应当理解的是,清除列表不能使用系统日志代替,而只能通过判断应用程序是否为安装之后第一次运行来建立清除列表。首先,一个应用程序可以包含一个到无数个程序界面,那么在系统日志里面就会有相应数量的应用程序包名和调用时间,如果直接使用系统日志中的记录,过多的重复的应用程序包名会增加执行清除工作时的工作量。再者,系统日志依赖于系统时钟,而嵌入式设备由于成本、体积等原因常常没有主板时钟电路和板载电池,系统电力有限经常中断,造成系统时钟不可靠,因此系统日志记录不可靠,不能直接使用系统日志生成恢复出厂设置时的应用程序列表。通过上述技术方案建立的清除列表,只有应用程序安装之后第一次运行时,才会记录并保存其应用程序包名,当进行恢复出厂设置时,从保存的信息中获取应用列表进行清理,而且此清除列表的建立不需要记录时间信息,将信息的记录与系统时间成功解耦,生成的清除列表稳定可靠。\n[0024] 在上述任一技术方案中,优选的,还可以包括:获取预设的第一名单,将所述第一名单中的应用程序的包名加入所述清除列表中,其中,所述第一名单保存有会产生用户数据的应用程序的包名;获取预设的第二名单,将所述第二名单中的应用程序包名与所述清除列表中的应用程序包名进行匹配,从所述清除列表中删除与所述第二名单中的应用程序包名相匹配的应用程序包名,其中,所述第二名单保存有不会产生用户数据的应用程序的包名。\n[0025] 由于系统日志中只能记录有前台界面的应用程序的运行情况,而一些无前台界面但会产生用户使用痕迹和数据的预装应用程序将会被遗漏。而在恢复出厂设置时,该被遗漏的应用程序的用户数据也需要被删除,为了使本发明提出的清除列表也包括这些没有前台界面的应用程序的包名,在一种优选的实施方式中,预设第一名单,在该第一名单中包含没有前台界面但有用户数据的应用程序包名,无论这些应用程序是否在前台运行过都将该第一名单中的应用程序包名添加至清除列表中,无需判断操作,从而加快清除列表的生成速度。在恢复出厂设置时,直接进行数据清理,保证清除列表的完整无遗漏。同时,将已知其不会产生用户数据的应用程序包名作为第二名单与清除列表进行匹配,并从清除列表中去除此部分应用程序包名,无论此部分应用程序是否运行过都将其从清除列表中去除,减少整体清除工作量。\n[0026] 在上述任一技术方案中,优选的,在接收到所述恢复出厂设置的指令时,还包括清除外设的设置数据;为清除所述相应应用程序的用户数据的任务和清除所述外设的设置数据的任务分配相应的清除线程。\n[0027] 通过上述技术方案,在清除列表中记录了全部产生用户使用痕迹或数据的应用程序包名,在接收到恢复出厂设置指令时,需要将清除列表中全部应用程序的使用痕迹进行清除,其中非预装应用程序包括卸载和清除用户数据,预装应用程序包括清除用户设置数据和用户信息。恢复出厂设置的工作任务多且复杂,且每项任务之间基本上没有顺序执行关系而且单一的任务工作量不大,清除用户数据和外设的设置数据时可以采用多线程并发的清除方式,将多项工作分配到多个线程中进行,清除所有清除列表中应用程序后直接关机即可,无需重新启动系统,从而缩短恢复出厂设置的时间。\n[0028] 图2示出了根据本发明的一个实施例的清除列表生成方法的流程图。\n[0029] 如图2所示,根据本发明的一个实施例的清除列表生成方法步骤如下:\n[0030] 步骤202:应用程序启动。系统调用应用程序,应用程序启动,系统日志记录调用时间及应用程序包名。\n[0031] 步骤204:将启动的应用程序的包名与系统日志中记录的应用程序运行记录进行比对,判断其是否为当日首次运行,若是当日首次运行,则转向步骤206,否则转向步骤208。\n[0032] 步骤206:将该应用程序包名与清除列表中的应用程序包名进行比对,判断其是否为安装之后第一次运行(若在清除列表中没有该应用程序包名,则确定该应用程序为安装之后第一次运行),若是安装之后第一次运行,则转向步骤210,否则转向步骤208。\n[0033] 步骤208:不将该应用程序包名保存至清除列表。所述应用程序虽然是当日首次运行但不是安装之后第一次运行,则不保存至清除列表。\n[0034] 步骤210:将该应用程序包名保存至清除列表。所述应用程序是当日首次运行且是安装之后第一次运行,则将该应用程序包名保存至清除列表。\n[0035] 在Android系统中,通过每个应用程序唯一的包名进行标识和管理,安装在同一个终端设备中的应用程序,不会有重复的包名。包名信息包含在应用程序的AndroidManifest.xml中。在安装应用程序时,PackageManager会解析此程序,以包名为标识结合其他信息生成数据结构,以用于应用管理。在本实施例中要获取和记录的,即为运行过的应用程序的包名。当用户启动一个应用程序时,Android会在应用界面显示在前台后,通知日志记录服务(UsageStatsService.noteResumeComponent()),通知中包含了应用程序包名和界面的类名。\n[0036] 系统日志只能存储当天的应用运行记录,当日期发生变更时,会直接删除前期记录重新开始。其次,其以程序界面为单位进行记录,一个应用程序可以包含一个到无数个程序界面,过多的信息会增加获取应用列表的工作量。再次,其依赖于系统时钟,而嵌入式系统由于成本、体积等原因常常没有主板RTC时钟电路和板载电池,系统电力有时经常中断,造成系统时钟不可靠,因此导致日志记录的不可靠。因此,依赖传统的日志记录机制保存的信息也是不可靠的,不能直接用来生成恢复出厂设置时的程序列表。因此,在本发明中,对日志记录服务(UsageStatsService)进行了改进,首先将应用程序包名与日志记录服务中已保存的当日运行记录进行比对,如果此应用程序本日已经运行过,则不做处理。若确认此程序无运行记录,则通过广播形式将该应用程序包名跨进程发送给后台服务(FactoryService)。\n[0037] 后台服务(FactoryService)是为出厂设置工作专门开发的服务类,用来接收此广播,将该应用程序包名保存至清除列表,并提供应用程序接口(API)来返回保存的清除列表,以及其他API供进行出厂设置的相关工作。FactoryService在终端开机后会自动启动运行。其注册了广播接收器,能够接收日志记录服务发送的上述广播,将应用程序包名保存在内部数据库中。\n[0038] 由于Android系统的日志记录服务机制只保存当日的运行记录,所以发送广播里包含的应用程序包名很可能在当日之前已经运行过,因此FactoryService会首先查询已经保存的清除列表,重复的包名不会被记录。\n[0039] 因此,当应用程序第一次运行时,记录并保存其包名信息,当进行出厂设置时,从保存的信息中获取应用列表进行清理。此方法不需要记录时间信息,将信息的记录与系统时间成功解耦,生成的程序列表稳定可靠。\n[0040] 上述基于日志记录服务的系统恢复算法,只能监控到有前台界面的应用程序运行,而产品预装的系统权限应用程序,有的是没有前台人机界面的,此类程序中有的也会在运行时记录用户使用的痕迹或数据。因此,本发明在前述基础上建立了黑名单机制,在产品研发阶段,对已知的会产生用户数据的系统应用程序,直接添加其包名到黑名单(即第一名单)中。在最终生成清除列表时,无论此应用是否在前台运行过都将该黑名单中的应用程序包名添加进清除列表中,对这些预装应用程序直接进行数据清理。\n[0041] 同样的,产品预装的应用程序中,也有很多程序是已知的不会产生用户数据的,因此建立了白名单(即第二名单)。在最终生成清除列表时,无论此应用是否在前台运行过,都将其从清除列表中去除,以减少整体工作量。需说明的是,除了上述的应用程序用户数据的清理工作,还有清除出厂设置数据的工作,例如1)卸载非系统预装应用程序,此项功能可配置,FactoryService接口方法中传递了标志位来使能/禁用词功能;2)清空有线网络、WiFi无线网络、蓝牙等设置的数据和用户信息;3)清空音量、亮度等系统设置和业务逻辑的数据;4)其他终端运行时生成或下载的文件等资源。\n[0042] 为了进一步提高清理速度,在本实施例中,还可以使用多线程技术,将多项工作分散到多个线程中进行,UI主线程不承担主要工作,以处理用户按键响应和及时更新界面。\n[0043] 因此,根据本发明的技术方案能够智能过滤应用程序,生成最简的需要清理用户数据的应用程序列表,能够直接卸载非预装应用程序,通过多线程并发工作,将出厂操作的时间减少了约十秒钟,并且减少了用户操作步骤,进而提高了恢复出厂设置的效率。\n[0044] 通过上述方法,用户只需要点击一个按键,就可以启动出厂设置操作。操作进行过程中,会在界面上输出提示信息,包括当前工作名称和进度等,在操作过程完毕时,在界面上输出操作完成的提示,用户看到该提示可以直接关机。\n[0045] 图3示出了根据本发明的一个实施例的系统恢复装置的框图。\n[0046] 如图3所示,根据本发明的一个实施例的系统恢复装置300,包括:获取单元302,用于获取启动的应用程序的包名;第一判断单元304,连接至所述获取单元302,用于判断所述应用程序是否是安装之后第一次运行;清除列表生成单元306,用于在所述第一判断单元\n304确定所述应用程序是安装之后第一次运行时,将所述应用程序的包名保存在清除列表中;系统恢复单元308,用于在接收到恢复出厂设置的指令时,根据所述清除列表中包含的应用程序包名,清除相应应用程序的用户数据。\n[0047] 将安装之后第一次启动的应用程序包名加入到清除列表中,在接收到恢复出厂设置指令时,根据清除列表中包含的应用程序包名,清除相应应用程序的用户数据(包括卸载非预装应用程序,以及删除使用应用程序时产生的数据),就可实现恢复出厂设置,对于不在该应用程序列表中的应用程序就可以在恢复过程中被忽略,以节省处理时间,并且无需重新启动系统以及对系统中的数据分区进行格式化,从而使恢复出厂操作的时间被大大减少。除此之外,在应用程序在第一次被运行时就将该应用程序的包名加入清除列表,无需在应用程序每次运行时都进行一次写入操作,也简化了清除列表的生成过程,并且不会使应用程序的包名在清除列表中重复出现,从而避免了在恢复出厂设置时的重复操作。\n[0048] 在上述技术方案中,优选的,还可以包括:第二判断单元310,用于在所述获取单元\n302获取所述应用程序的包名之后,调用系统日志,根据所述系统日志判断所述应用程序是否是当日首次运行,若是当日首次运行,则判断所述应用程序是否是安装之后第一次运行。\n[0049] 当系统调用应用程序界面时,系统日志会记录下应用程序被调用时的时间和应用界面名称等信息,而系统日志只能存储当天的应用程序运行记录,当日期发生变更时,会直接删除前期记录重新开始记录,因此如果直接使用目前的系统日志将不能得到准确的清除列表。为了解决这个问题,在本实施例中,在获取到启动的应用程序的包名时,利用该系统日志,与系统日志中记录的当天运行过的应用程序进行比对,如果所述应用程序本日已经运行过,则说明所述应用程序包名已经加入清除列表,无需将该应用程序的包名传递给清除列表。这样就可以减少重复调用,加快程序运行速度。如果所述应用程序本日首次运行,则将该应用程序包名传递给清除列表,由列表管理服务来决定是否将该应用程序包名加入清除列表。虽然应用程序为当日首次运行,但其也可能在当日之前运行过,那么就需要查询所述应用程序是否安装之后第一次运行,以确定所述应用程序是否需要加入清除列表中。\n[0050] 在上述技术方案中,优选的,所述第一判断单元304还用于判断所述应用程序的包名是否保存在所述清除列表中,若未保存在所述清除列表中,则确定所述应用程序是安装之后第一次运行。\n[0051] 由于清除列表中记录着调用过的应用程序的包名,故判断当日首次运行的应用程序是否为安装之后第一次运行,需要查询清除列表中有无所述应用程序的包名。如果清除列表中包含所述应用程序包名,则说明该应用程序在本日之前运行过,不是安装之后第一次运行,则无需将所述应用程序包名加入清除列表;相反的,如果清除列表中不包含所述应用程序包名,则说明该应用程序为安装之后第一次运行,需要将所述应用程序包名加入清除列表中。通过清除列表判断调用的应用程序是否为安装之后第一次运行,可保证清除列表中相同的应用程序不会被重复记录,当收到恢复出厂指令执行清除操作时,无需做重复检查工作,减少恢复出厂设置的时间。\n[0052] 本领域的技术人员应当理解的是,清除列表不能使用系统日志代替,而只能通过判断应用程序是否为安装之后第一次运行来建立清除列表。首先,一个应用程序可以包含一个到无数个程序界面,那么在系统日志里面就会有相应数量的应用程序包名和调用时间,如果直接使用系统日志中的记录,过多的重复的应用程序包名会增加执行清除工作时的工作量。再者,系统日志依赖于系统时钟,而嵌入式设备由于成本、体积等原因常常没有主板时钟电路和板载电池,系统电力有限经常中断,造成系统时钟不可靠,因此系统日志记录不可靠,不能直接使用系统日志生成恢复出厂设置时的应用程序列表。通过上述技术方案建立的清除列表,只有应用程序安装之后第一次运行时,才会记录并保存其应用程序包名,当进行恢复出厂设置时,从保存的信息中获取应用列表进行清理,而且此清除列表的建立不需要记录时间信息,将信息的记录与系统时间成功解耦,生成的清除列表稳定可靠。\n[0053] 在上述任一技术方案中,优选的,还包括:第一更新单元312,用于获取预设的第一名单,将所述第一名单中的应用程序的包名加入所述清除列表中,其中,所述第一名单保存有会产生用户数据的应用程序的包名;第二更新单元314,用于获取预设的第二名单,将所述第二名单中的应用程序包名与所述清除列表中的应用程序包名进行匹配,从所述清除列表中删除与所述第二名单中的应用程序包名相匹配的应用程序包名,其中,所述第二名单保存有不会产生用户数据的应用程序的包名。\n[0054] 由于系统日志中只能记录有前台界面的应用程序的运行情况,而一些无前台界面但会产生用户使用痕迹和数据的预装应用程序将会被遗漏。而在恢复出厂设置时,该被遗漏的应用程序的用户数据也需要被删除,为了使本发明提出的清除列表也包括这些没有前台界面的应用程序的包名,在一种优选的实施方式中,预设第一名单,在该第一名单中包含没有前台界面但有用户数据的应用程序包名,无论这些应用程序是否在前台运行过都将该第一名单中的应用程序包名添加至清除列表中,无需判断操作,从而加快清除列表的生成速度。在恢复出厂设置时,直接进行数据清理,保证清除列表的完整无遗漏。同时,将已知其不会产生用户数据的应用程序包名作为第二名单与清除列表进行匹配,并从清除列表中去除此部分应用程序包名,无论此部分应用程序是否运行过都将其从清除列表中去除,减少整体清除工作量。\n[0055] 在上述任一技术方案中,优选的,所述系统恢复单元308在接收到所述恢复出厂设置的指令时,还用于清除外设的设置数据;所述系统恢复单元308包括:线程分配单元3082,用于为清除所述相应应用程序的用户数据的任务和清除所述外设的设置数据的任务分配相应的清除线程。\n[0056] 通过上述技术方案,在清除列表中记录了全部产生用户使用痕迹或数据的应用程序包名,在接收到恢复出厂设置指令时,需要将清除列表中全部应用程序数据进行清除,其中非预装应用程序包括卸载和清除用户数据,预装应用程序包括清除用户设置数据和用户信息。恢复出厂设置的工作任务多且复杂,且每项任务之间基本上没有顺序执行关系而且单一的任务工作量不大,清除用户数据和外设的设置数据时可以采用多线程并发的清除方式,将多项工作分配到多个线程中进行,清除所有清除列表中应用程序后直接关机即可,无需重新启动系统,缩短恢复出厂设置的时间。\n[0057] 以上结合附图详细说明了根据本发明的技术方案,本发明能够动态跟踪应用程序运行,生成需要清理数据的应用程序列表,以在恢复出厂设置时清除应用程序使用的痕迹和用户数据,不需要重新启动系统,也不需要格式化数据分区,就可以完成恢复出厂设置,减少了恢复出厂设置的消耗时间。\n[0058] 以上所述仅为本发明的优选实施例而已,并不用于限制本发明,对于本领域的技术人员来说,本发明可以有各种更改和变化。凡在本发明的精神和原则之内,所作的任何修改、等同替换、改进等,均应包含在本发明的保护范围之内。
法律信息
- 2017-01-04
- 2014-04-30
实质审查的生效
IPC(主分类): G06F 9/445
专利申请号: 201310753474.9
申请日: 2013.12.31
- 2014-04-02
引用专利(该专利引用了哪些专利)
序号 | 公开(公告)号 | 公开(公告)日 | 申请日 | 专利名称 | 申请人 |
1
| |
2013-08-28
|
2013-05-15
| | |
2
| |
2011-09-14
|
2011-06-15
| | |
3
| |
2013-05-08
|
2013-02-07
| | |
4
| |
2012-07-18
|
2011-12-26
| | |
被引用专利(该专利被哪些专利引用)
序号 | 公开(公告)号 | 公开(公告)日 | 申请日 | 专利名称 | 申请人 | 该专利没有被任何外部专利所引用! |