修复方法及相关电子装置的制造方法【
技术领域：
】[0001]本发明有关于电子装置，且尤其有关于一种应用于电子装置的修复方法。【
背景技术：
】[0002]随着移动通信的蓬勃发展，市场上存在各式各样的智能手机、个人数字助理(PersonalDigitalAssistant,PDA)、平板电脑(tablet)、迷你平板电脑等电子装置。这些电子装置的硬件质量往往参差不齐，可能会导致用户无法正常开机，亦即“手机变砖(beingbrick)”。举例来说，存储媒介读写次数过多发生损坏而导致系统关键文件缺失，甚至导致无法开机或不断地重复开关机等。另外，使用者不当的操作(如开机状态下进行电池插拔操作)也有可能造成电子装置无法正常使用。[0003]一般常见电子装置的系统，例如安卓(Android)系统，并无法针对上述错误进行自我修复或恢复，导致电子装置无法恢复到正常状态，用户便只能到维修中心进行刷机。有鉴于此，本发明主要诉求在于如何解决上述问题。【
发明内容】[0004]本发明提供一种修复方法，应用于电子装置中，其中该电子装置包含修复框架和异常源，该修复方法包含:从该异常源接收异常状况；以及针对该异常状况进行修复。[0005]本发明另提供一种电子装置，包含异常源；以及修复框架，用来从该异常源接收异常状况，并针对该异常状况进行修复。[0006]通过利用本发明，可提高电子装置的鲁棒性。【附图说明】[0007]图1是根据本发明一实施例的电子装置的架构图。[0008]图2是根据本发明一实施例的修复方法的流程图。[0009]图3是根据本发明一实施例的修复方法的流程图。[0010]图4是根据本发明一实施例的模块与相应默认异常处理逻辑的示意图。[0011]图5是根据本发明一实施例的确定修复级别的流程图。【具体实施方式】[0012]以下为本发明的较佳实施例揭露，然其并非用以限制本发明。本发明所属
技术领域：
中普通技术人员，在不脱离本发明的精神和范围内，当可作各种的变更和润饰。因此，本发明的保护范围当视之前的权利要求书所界定为准。[0013]在本专利说明书及权利要求当中使用了某些词汇来指称特定的组件。所属领域中具有通常知识者应可理解，硬件制造商可能会用不同的名词来称呼同一个组件。本专利说明书及权利要求并不以名称的差异来作为区分组件的方式，而是以组件在功能上的差异来作为区分的准则。在通篇说明书及请求项当中所提及的“包含”或“包括”为开放式的用语，故应解释成“包含但不限定于”。另外，“耦接”一词在此包含任何直接及间接的电气连接手段。因此，若文中描述一第一装置耦接于一第二装置，则代表该第一装置可直接电气连接于该第二装置，或透过其他装置或连接手段间接地电气连接至该第二装置。[0014]请参考图1，图1是根据本发明一实施例的电子装置100的架构图。其中，电子装置100可为智能手机、PDA、平板电脑、迷你平板电脑等各种电子装置。电子装置100包含有异常源102、修复框架(recoverymanager)104以及应用程序106。其中，由于电子装置100可通过修复框架进行自行修复，因此该修复框架也可称为智能修复框架。当然，电子装置100还可包含其他模块，在此不再赘述。其中，异常源102可为发生异常的模块本身，也可为一中继模块，即发生异常的模块将异常报告给中继模块或被中继模块探知。在一实施例中，异常源102可为系统服务器(systemserver)0其中，系统服务器包含有若干负责不同功能/服务的模块，例如包管理服务(PackageManagementService,PMS)、活动管理服务(ActivityManagementService,AMS)等系统级服务模块。系统服务器本身不具有异常分析与修复能力，在开机过程中，系统服务器会逐个加载系统关键模块(如上述PMS、AMS等服务模块)，当某个模块相对应的系统文件损坏而使得系统启动时的加载动作发生异常状况时，系统服务器便会将该异常状况擷取下来，并且将异常发送给修复框架104来分析和处理。需注意，这只是用于举例的目的，本发明并不限于此。异常源102还可为本地服务(nativeservice)模块、内核(kernel)模块等。[0015]修复框架104可以被视作一平台，设计者可以基于该平台的基本修复架构来增加/改变设计，例如异常源102(如系统服务器)中可能会视需求发展出新的模块，而设计者便可在修复框架104所提供的平台上针对新的模块自行定义新的修复逻辑。具体来说，修复框架104中的异常分析模块1042会对异常源102报告的异常状况进行异常分析，以确认发生异常的模块，并交给处理控制模块1044来找出相对应的处理方式。具体来说，处理控制模块1044会依据内建的默认异常处理逻辑(except1nhandlerpolicy)来决定针对该异常状况所采用的修复方式，例如删除文件、备份文件恢复、执行其它处理流程(如执行用户自定义的操作)等。其中，默认异常处理逻辑与异常状况的对应关系可存储在修复框架104之中的或相耦接的存储模块(图未示)中。决定修复方式之后，修复模块1046便可据以完成对应的修复操作，并通知异常源102。异常源102随后可进行模块重启等操作。[0016]关于应用程序106，用户可以利用应用程序106中的日志察看模块1062来察看过往的异常状况记录。另外，用户可以通过用户设定模块1064来选择所提供的修复级别选项，并记录于设定记录模块1066中。在一实施例中，修复级别分为三个级别:停用服务、基本修复、最大努力修复。在停用服务模式下，修复框架104不会提供修复服务，当异常发生时，仅仅记录下异常状况；在基本修复模式下，修复框架104只会按照预定义的修复规则进行系统修复，如果修复失败，不会进行进一步的修复工作；而在最大努力修复模式下，如果修复失败，修复框架104会进一步采取保留用户数据的恢复出厂模式尝试修复系统，或者按照预定义的修复规则重复进行系统修复。其中，现有的恢复出厂模式是将数据分区(datapartit1n)格式化来清除所有的用户数据(包括应用程序以及所有的应用程序数据)，由于通常用户的应用程序不会影响系统正常使用，所以保留用户数据的恢复出厂模式是在普通的恢复出厂模式基础上，保留数据分区中的应用程序以及应用程序数据(如联系人、短信等)。这样既可以满足恢复手机正常使用状态需求，又能最大程度上使得用户数据得以保留。需注意，上述举例仅为说明的目的，并非用以限制本发明。本领域技术人员可设置不同的修复级别以及修复方式。以下将分别针对修复框架104以及应用程序106的操作流程进行详细的说明。[0017]请参考图2，图2是根据本发明一实施例的修复方法的流程图，本方法可用于图1所示的电子装置100中。[0018]步骤S202:开始。[0019]步骤S204:从异常源102接收异常状况。[0020]步骤S206:针对该异常状况进行修复。[0021]步骤S208:结束。[0022]根据本发明一实施例，步骤S206和步骤S208之间还可包括通知异常源102的步骤。根据本发明另一实施例，步骤S206可具体包括以下步骤:对从系统服务器102接收的异常状况进行分析，以确定发生异常状况的模块；以及根据该模块的默认异常处理逻辑进行修复。根据本发明一实施例，如图3所示，步骤S206可进一步进行细分。图3是根据本发明一实施例的修复方法的流程图。需注意，倘若大体上可达到相同的结果，并不需要一定遵照图3所示流程中的步骤顺序来进行，且图3所示的步骤不一定要连续进行，即其他步骤也可插入其中，此外，图3中的某些步骤也可根据不同实施例或设计需求而进行省略。本实施例所揭示的修复方法主要包含有以下步骤:[0023]步骤S2061:对接收到的异常状况进行分析，以确定发生异常状况的模块。[0024]步骤S2062:判断该模块是否为注册模块。若是注册模块，则进入步骤S2063;否则进入步骤S208。[0025]步骤S2063:判断该异常状况是否可由修复框架104进行修复(即修复框架104是否有能力对该异常状况进行修复)。若可由修复框架104进行修复，则进入步骤S2064;否则进入步骤S208。在一实施例中，若异常状况是由文件损坏导致的，则该异常状况可由修复框架104进行修复；若异常状况不是由文件损坏导致的，则该异常状况无法由修复框架104进行修复。[0026]步骤S2064:确定该模块所对应的默认异常处理逻辑。在一实施例中，可从修复框架104之中的或相耦接的存储模块(图未示)中读取该模块所对应的默认异常处理逻辑，其中存储模块中储存有每个注册模块所对应的默认异常处理逻辑。[0027]步骤S2065:根据该默认异常处理逻辑进行修复。[0028]需注意，根据本发明的一实施例，将一模块所对应的默认异常处理逻辑注册到修复框架104中(例如通过一特定文件:recovery.xml)后，修复框架104才能在该模块发生错误时针对该模块进行修复。根据本发明的当前第1页1 2