CN116719670A - 数据处理的方法、电子设备及可读存储介质 - Google Patents

数据处理的方法、电子设备及可读存储介质 Download PDF

Info

Publication number
CN116719670A
CN116719670A CN202211211714.8A CN202211211714A CN116719670A CN 116719670 A CN116719670 A CN 116719670A CN 202211211714 A CN202211211714 A CN 202211211714A CN 116719670 A CN116719670 A CN 116719670A
Authority
CN
China
Prior art keywords
electronic device
data
user
crash event
crash
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
CN202211211714.8A
Other languages
English (en)
Other versions
CN116719670B (zh
Inventor
苗世洋
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Honor Device Co Ltd
Original Assignee
Honor Device Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Honor Device Co Ltd filed Critical Honor Device Co Ltd
Priority to CN202211211714.8A priority Critical patent/CN116719670B/zh
Publication of CN116719670A publication Critical patent/CN116719670A/zh
Application granted granted Critical
Publication of CN116719670B publication Critical patent/CN116719670B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1402—Saving, restoring, recovering or retrying
    • G06F11/1415—Saving, restoring, recovering or retrying at system level
    • G06F11/1417—Boot up procedures
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0706—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
    • G06F11/0736—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in functional embedded systems, i.e. in a data processing system designed as a combination of hardware and software dedicated to performing a certain function
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0766—Error or fault reporting or storing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/079—Root cause analysis, i.e. error or fault diagnosis

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Quality & Reliability (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Health & Medical Sciences (AREA)
  • Biomedical Technology (AREA)
  • Debugging And Monitoring (AREA)

Abstract

本申请公开了一种数据处理的方法、电子设备及可读存储介质，属于终端技术领域。该方法包括：响应于对第一应用程序的启动操作，启动第一应用程序，第一应用程序为第一电子设备中的任意一个应用程序；第一应用程序读取目标XML文件中的目标数据，目标XML文件是在用于进行最近一次系统升级的升级包中携带且在系统升级后生效的；第一应用程序将目标数据存储至DDR内存中；删除第一电子设备的二进制分区中的目标数据。本申请通过将目标数据存储于DDR内存中，由于DDR内存中的数据在第一电子设备下电后可消失，所以可以避免目标数据长期存在给第一电子设备带来安全隐患的问题。

Description

数据处理的方法、电子设备及可读存储介质
技术领域
本申请涉及终端技术领域，特别涉及一种数据处理的方法、电子设备及可读存储介质。
背景技术
电子设备进行系统升级后会存在一些残留的数据，这些残留的数据通常会被存储在expdb分区(二进制分区)中。在一些场景下，expdb分区中的残留的数据会对电子设备的运行带来一定的影响，譬如在残留的数据中包括通用串行总线(universal serial bus，USB)转储(dump)标志的情况下，会使得电子设备发生崩溃后进入快速启动界面(即fastboot界面)，从而导致需要用户手动关机重启。
在相关技术中，由于残留的数据中包括一些有用的数据，所以通常不会将其从expdb分区中删除，并且，针对expdb分区中的数据，即使电子设备恢复出厂设置也默认不清除，所以导致残留的数据会长期存在于电子设备的expdb分区中。
发明内容
本申请提供了一种数据处理的方法、电子设备及可读存储介质，可以解决相关技术中系统升级后残留的数据会长期存在于电子设备的expdb分区容易影响电子设备运行的问题。所述技术方案如下：
第一方面，提供了一种数据处理的方法，应用于第一电子设备中，所述方法包括：
响应于对第一应用程序的启动操作，启动所述第一应用程序，所述第一应用程序为所述第一电子设备中的任意一个应用程序；
所述第一应用程序读取目标可扩展标记语言XML文件中的目标数据，所述目标XML文件是在用于进行所述最近一次系统升级的升级包中携带且在系统升级后生效的；
所述第一应用程序将所述目标数据存储至所述第一电子设备的双倍速率DDR内存中；
删除二进制分区中的所述目标数据。
如此，通过将升级保留下的目标数据存储至DDR内存中，并将expdb分区中的目标数据删除，由于DDR内存中的数据在第一电子设备下电后可消失，所以使得目标数据不会长期存在于第一电子设备的expdb分区中，从而可以避免目标数据带来的安全隐患问题。
作为本申请的一个示例，在系统崩溃后重启的情况下，显示提示信息，所述提示信息是在根据目标数据确定进入内核崩溃转储模式的情况下显示，所述提示信息用于指示异常日志的获取方式，所述目标数据是所述第一电子设备最近一次系统升级后保留下的数据；
接收用户根据所述提示信息执行的至少一个用户操作，依次响应所述至少一个用户操作中的每个用户操作。
如此，第一电子设备在崩溃重启后，可以从DDR内存中读取第一崩溃事件处理标志，以根据第一崩溃事件处理标志确定针对崩溃事件所要执行的操作。在第一崩溃事件处理标志指示发生崩溃事件后所要执行的操作为开启内核崩溃转储模式的情况下，从DDR内存中读取第一转储模式标志，根据第一转储模式标志，开启对应的内核崩溃转储模式获取异常日志，使得用户可以获得异常日志，从而便于对第一电子设备进行故障分析。
作为本申请的一个示例，所述目标数据包括第一崩溃事件处理标志和第一转储模式标志，所述第一崩溃事件处理标志用于标识在发生崩溃事件的情况下所要执行的操作，所述第一转储模式标志用于标识异常日志获取模式；
所述在系统崩溃后重启的情况下，显示提示信息，包括：
在系统崩溃后重启的情况下，从所述DDR内存中读取所述第一崩溃事件处理标志；
在所述第一崩溃事件处理标志为第一数值的情况下，从所述DDR内存中读取所述第一转储模式标志，所述第一数值用于指示在发生崩溃事件的情况下所要执行的操作为开启内核崩溃转储模式；
根据所述第一转储模式标志，显示所述提示信息。
如此，通过配置第一崩溃事件处理标志和第一转储模式标志，可以使得第一电子设备在发生崩溃事件后，引导用户获取第一电子设备所抓取异常日志，便于用户可以基于异常日志进行故障分析，或者将异常日志上报给后台，方便后台可以远程定位用户故障。
作为本申请的一个示例，在所述第一转储模式标志指示异常日志获取模式为USB接口输出的情况下，所述提示信息用于指示用户通过USB接口接入第二电子设备以获取所述异常日志；或者，在所述第一转储模式标志指示异常日志获取模式为从内存中获取的情况下，所述提示信息用于指示用户所述异常日志已存储于指定存储路径下。
如此，通过配置第一转储模式标志，可以使得第一电子设备通过不同的方式提供异常日志，从而增加了异常日志的获取方式。
作为本申请的一个示例，在所述第一转储模式标志指示异常日志获取模式为通过USB接口输出的情况下，所述接收用户根据所述提示信息执行的至少一个用户操作，依次响应所述至少一个用户操作中的每个用户操作，包括：
响应于通过所述USB接口接入所述第二电子设备的用户操作，监听所述USB接口；
若通过所述USB接口监听到所述第二电子设备的数据传输通道建立请求，则与所述第二电子设备建立所述数据传输通道；
在所述数据传输通道建立成功的情况下，抓取所述异常日志；
通过所述数据传输通道向所述第二电子设备传输所述异常日志。
如此，通过引导用户接入USB数据线，使得第一电子设备将异常日志输出至第二电子设备中，从而便于用户直接从第二电子设备中获得异常日志，提高了获取效率。
作为本申请的一个示例，在所述第一转储模式标志指示异常日志获取模式为从内存中获取的情况下，所述接收用户根据所述提示信息执行的至少一个用户操作，依次响应所述至少一个用户操作中的每个用户操作之前，包括：
抓取所述异常日志；
将所述异常日志存储于所述指定存储路径下；
所述接收用户根据所述提示信息执行的至少一个用户操作，依次响应所述至少一个用户操作中的每个用户操作，包括：
响应于关闭所述提示信息的用户操作，重启所述第一电子设备。
如此，通过将异常日志存储指定存储路径下，使得第一电子设备重启后，用户可以从指定存储路径下查询到该异常日志，避免需要连接其他设备。
作为本申请的一个示例，所述在系统崩溃后重启的情况下，显示提示信息之前，还包括：
在系统启动的情况下，从所述DDR内存中读取启动指示信息，所述启动指示信息用于指示系统启动的触发原因；
在所述启动指示信息指示所述第一电子设备在系统启动前发生崩溃事件的情况下，确定所述第一电子设备是系统崩溃后重启。
如此，通过读取启动指示信息判断第一电子设备是否是崩溃后重启，从而便于确定后续需要执行的操作。
作为本申请的一个示例，所述方法还包括：
在完成异常日志抓取操作后，清除所述DDR内存中存储的所述第一崩溃事件处理标志和所述第一转储模式标志。
如此，在完成异常日志抓取操作后，清除所述DDR内存中存储的所述第一崩溃事件处理标志和所述第一转储模式标志，可以避免给第一电子设备的运行带来影响。
作为本申请的一个示例，所述方法还包括：
在系统崩溃后重启的情况下，在所述第一崩溃事件处理标志为第二数值的情况下，加载所述第一电子设备的内核，所述第二数值用于指示在发生崩溃事件的情况下所要执行的操作为启动操作。
如此，在第一崩溃事件处理标志为第二数值的情况下，控制第一电子设备重启，也即也可以不抓取异常日志，而是继续正常启动，便于第一电子设备能够快速进入正常使用状态。
作为本申请的一个示例，所述方法还包括：
接收在线修改指令，所述在线修改指令中携带第二崩溃事件处理标志和第二转储模式标志；
将所述目标XML文件中的第一崩溃事件处理标志修改为所述第二崩溃事件处理标志，以及将所述目标XML文件中的第一转储模式标志修改为所述第二转储模式标志。
如此，由于目标XML文件支持在线修改，且不需要系统重启即可生效，另外对于用户是不感知的，譬如如图9所示，在目标XML文件修改前后，第一电子设备的界面不会有关于目标XML文件更新的相关变化，所以在无需重启系统的情况下即可修改第一崩溃事件处理标志和第二转储模式标志，可以提高管理效率，并且，由于对于用户是无感知的，不需要重启系统，从而提高了用户体验。
第二方面，提供了一种数据处理的装置，所述数据处理的装置具有实现上述第一方面中数据处理方法行为的功能。所述数据处理的装置包括至少一个模块，所述至少一个模块包括：
启动模块，用于响应于对第一应用程序的启动操作，启动所述第一应用程序，所述第一应用程序为所述第一电子设备中的任意一个应用程序；
读取模块，用于通过所述第一应用程序读取目标可扩展标记语言XML文件中的目标数据，所述目标XML文件是在用于进行所述最近一次系统升级的升级包中携带且在系统升级后生效的；
存储模块，用于通过所述第一应用程序将所述目标数据存储至所述第一电子设备的双倍速率DDR内存中；
删除模块，用于删除二进制分区中的所述目标数据。
作为本申请的一个示例，所述装置还用于：
在系统崩溃后重启的情况下，显示提示信息，所述提示信息是在根据目标数据确定进入内核崩溃转储模式的情况下显示，所述提示信息用于指示异常日志的获取方式，所述目标数据是所述第一电子设备最近一次系统升级后保留下的数据；
接收用户根据所述提示信息执行的至少一个用户操作，依次响应所述至少一个用户操作中的每个用户操作。
作为本申请的一个示例，所述目标数据包括第一崩溃事件处理标志和第一转储模式标志，所述第一崩溃事件处理标志用于标识在发生崩溃事件的情况下所要执行的操作，所述第一转储模式标志用于标识异常日志获取模式；
所述装置用于：
在系统崩溃后重启的情况下，从所述DDR内存中读取所述第一崩溃事件处理标志；
在所述第一崩溃事件处理标志为第一数值的情况下，从所述DDR内存中读取所述第一转储模式标志，所述第一数值用于指示在发生崩溃事件的情况下所要执行的操作为开启内核崩溃转储模式；
根据所述第一转储模式标志，显示所述提示信息。
作为本申请的一个示例，在所述第一转储模式标志指示异常日志获取模式为通过通用串行总线USB接口输出的情况下，所述提示信息用于指示用户通过USB接口接入第二电子设备以获取所述异常日志；或者，在所述第一转储模式标志指示异常日志获取模式为从内存中获取的情况下，所述提示信息用于指示用户所述异常日志已存储于指定存储路径下。
作为本申请的一个示例，在所述第一转储模式标志指示异常日志获取模式为通过USB接口输出的情况下，所述装置用于：
响应于通过所述USB接口接入所述第二电子设备的用户操作，监听所述USB接口；
若通过所述USB接口监听到所述第二电子设备的数据传输通道建立请求，则与所述第二电子设备建立所述数据传输通道；
在所述数据传输通道建立成功的情况下，通过第一内核崩溃转储模块抓取所述异常日志；
通过第一内核崩溃转储模块，利用所述数据传输通道向所述第二电子设备传输所述异常日志。
作为本申请的一个示例，在所述第一转储模式标志指示异常日志获取模式为从内存中获取的情况下，所述装置用于：
通过第二内核崩溃转储模块抓取所述异常日志；
通过所述第二内核崩溃转储模块将所述异常日志存储于所述指定存储路径下；
响应于关闭所述提示信息的用户操作，重启所述第一电子设备。
作为本申请的一个示例，所述装置还用于：
在系统启动的情况下，从所述DDR内存中读取启动指示信息，所述启动指示信息用于指示系统启动的触发原因；
在所述启动指示信息指示所述第一电子设备在系统启动前发生崩溃事件的情况下，确定所述第一电子设备是系统崩溃后重启。
作为本申请的一个示例，所述装置还用于：
在完成异常日志抓取操作后，清除所述DDR内存中存储的所述第一崩溃事件处理标志和所述第一转储模式标志。
作为本申请的一个示例，所述装置还用于：
在系统崩溃后重启的情况下，在所述第一崩溃事件处理标志为第二数值的情况下，加载所述第一电子设备的内核，所述第二数值用于指示在发生崩溃事件的情况下所要执行的操作为启动操作。
作为本申请的一个示例，所述装置还用于：
接收在线修改指令，所述在线修改指令中携带第二崩溃事件处理标志和第二转储模式标志；
将所述目标XML文件中的所述第一崩溃事件处理标志修改为所述第二崩溃事件处理标志，以及将所述目标XML文件中的所述第一转储模式标志修改为所述第二转储模式标志。
第三方面，提供了一种电子设备，所述电子设备的结构中包括处理器和存储器，所述存储器用于存储支持电子设备执行上述第一方面所提供的方法的程序，以及存储用于实现上述第一方面所述的方法所涉及的数据。所述处理器被配置为用于执行所述存储器中存储的程序。所述电子设备还可以包括通信总线，所述通信总线用于在所述处理器与所述存储器之间建立连接。
第四方面，提供了一种计算机可读存储介质，所述计算机可读存储介质中存储有指令，当其在计算机上运行时，使得计算机执行上述第一方面所述的方法。
第五方面，提供了一种包含指令的计算机程序产品，当其在计算机上运行时，使得计算机执行上述第一方面所述的方法。
上述第二方面、第三方面、第四方面和第五方面所获得的技术效果与上述第一方面中对应的技术手段获得的技术效果近似，在这里不再赘述。
附图说明
图1是根据一示例性实施例示出的一种系统更新流程的示意图；
图2是根据一示例性实施例示出的一种电子设备的分区的示意图；
图3是根据一示例性实施例示出的一种通过USB输出异常日志的操作流程示意图；
图4是根据一示例性实施例示出的一种通过USB输出异常日志的示意图；
图5是根据一示例性实施例示出的一种应用场景的示意图；
图6是根据一示例性实施例示出的一种电子设备的软件系统的架构示意图；
图7是根据一示例性实施例示出的一种数据处理的方法的流程图；
图8是根据一示例性实施例示出的一种将目标数据写入DDR内存中的场景示意图；
图9是根据一示例性实施例示出的一种目标XML文件更新前后界面的示意图；
图10是根据另一示例性实施例示出的一种数据处理的方法的流程图；
图11是根据另一示例性实施例示出的一种数据处理的方法的流程图；
图12是根据一示例性实施例示出的一种数据处理的装置的结构示意图；
图13是根据一示例性实施例示出的一种电子设备的结构示意图。
具体实施方式
为使本申请的目的、技术方案和优点更加清楚，下面将结合附图对本申请的实施方式作进一步地详细描述。
应当理解的是，本申请提及的“多个”是指两个或两个以上。在本申请的描述中，除非另有说明，“/”表示或的意思，比如，A/B可以表示A或B；本文中的“和/或”仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，比如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。另外，为了便于清楚描述本申请的技术方案，采用了“第一”、“第二”等字样对功能和作用基本相同的相同项或相似项进行区分。本领域技术人员可以理解“第一”、“第二”等字样并不对数量和执行次序进行限定，并且“第一”、“第二”等字样也并不限定一定不同。
在本申请说明书中描述的参考“一个实施例”或“一些实施例”等意味着在本申请的一个或多个实施例中包括结合该实施例描述的特定特征、结构或特点。由此，在本说明书中的不同之处出现的语句“在一个实施例中”、“在一些实施例中”、“在其他一些实施例中”、“在另外一些实施例中”等不是必然都参考相同的实施例，而是意味着“一个或多个但不是所有的实施例”，除非是以其他方式另外特别强调。术语“包括”、“包含”、“具有”及它们的变形都意味着“包括但不限于”，除非是以其他方式另外特别强调。
在对本申请实施例提供的方法进行详细说明之前，先对本申请实施例涉及的术语和名词进行简单介绍。
可扩展标记语言(eXtensible markup language，XML)文件：是一种数据文件，通常用于传输和存储数据，其存储的数据易于被应用程序读取。
内核崩溃转储模式：通常又称为Ramdump模式。在进入Ramdump模式的情况下，可以通过内核崩溃转储模块将电子设备运行时在内存、处理器等器件上的动态数据(也即易失数据)转储(dump)为静态数据(如文件)，从而得到dump文件(或称Ramdump)。在一个示例中，在系统发生崩溃(crash)事件的情况下，进入Ramdump模式后得到的dump文件一般可以称为异常日志。
双倍速率(double data rate，DDR)内存：在电子设备下电后，DDR内存中的数据可消失。
生产版本：通常是指电子设备生产过程中的过度版本。
用户版本：是指对生产版本的系统进行升级后的系统版本，也可以称为升级版本。
热补丁程序：是指能够修改软件漏洞的一些代码，提供了一种快速、低成本修复产品软件版本缺陷的方式。
在一种场景中，在电子设备出厂之前，通常需要从生产版本升级至用户版本。在另一种场景中，在电子设备流到用户端后，为了提高用户体验，电子设备的后台通常会主动向用户使用的电子设备推送升级包，以便于电子设备可以进行系统升级。譬如以电子设备是手机为例，请参考图1，假设用户在使用手机过程中，手机接收到推送的升级包下载通知10，如图1中的(a)图所示，用户在同意升级的情况下可以点击该升级包下载通知10。响应于用户对升级包下载通知10的点击操作，手机进入升级包下载界面，如图1中的(b)图所示，升级包下载界面中可以提供有下载并安装选项11。如此，用户可以点击下载并安装选项11。响应于用户对下载并安装选项11的点击操作，手机下载升级包，并在下载完成后基于所下载的升级包进行系统升级，从而对电子设备的系统进行升级。
然而，电子设备系统升级后，存在一些残留的数据未清。这些残留的数据存储在expdb分区中。然而在一些场景中，残留的数据会影响电子设备的正常运行，譬如残留的数据中的USB dump标志会导致电子设备发生崩溃后进入fastboot界面，而不是进入重启模式，如此以来需要用户手动重启电子设备，从而影响用户体验。由于残留的数据中包括一些有用的数据，所以通常不会轻易将其从expdb分区中删除，并且，针对expdb分区中的数据，即使对电子设备恢复出厂设置也默认不清除，譬如如图2所示，以残留的数据包括USB dump标志为例，在系统升级后以及恢复出厂设置后，USB dump标志一直存在于expdb分区中。如此导致残留的数据会长期存在于expdb分区中，进而容易导致电子设备在一些场景中总会出现运行异常的问题。
为此，本申请实施例提供了一种方法，该方法可以避免残留的数据长期存在于expdb分区中，从而尽可能地避免残留的数据带来的隐患。
此外，本申请实施例还对残留的数据的应用进行了扩展，以便于电子设备在发生崩溃事件时可以指引用户如何获取异常日志。为了便于理解，接下来以手机为例，对扩展的应用场景进行简单介绍。
在一个示例中，在手机完成升级的情况下，若手机崩溃后重启，则手机可能在启动后显示第一提示信息，第一提示信息用于提示用户通过USB接口接入其他电子设备以获取异常日志，示例性地如图3中的(a)图所示，提示信息具体可以为“请通过USB接口接入PC以抓取Ramdump”。如此，如图3中的(b)图所示，用户可以根据第一提示信息，利用USB数据线连接手机与PC(个人计算机)，此时，手机可以不再显示第一提示信息，作为示例而非限定，手机可以显示“等待连接...”提示内容。在一个示例中，PC中可以提供有指定工具，该指定工具用于按照预置的协议使得PC与手机建立数据传输通道。在通过USB数据线将PC与手机连接的情况下，PC中可以显示包括“请打开指定工具”提示内容的界面，用户可以点击PC中的“请打开指定工具”提示内容，响应于用户对该提示内容的触发操作，PC通过指定工具请求与手机建立数据传输通道，相应地，手机与PC开始建立数据传输通道。作为示例而非限定，在PC与手机建立数据传输通道的过程中，手机和PC可以分别显示如图3中的(c)图所示的提示界面。请参考图4，在数据传输通道建立成功的情况下，手机通过数据传输通道输出异常日志，如此，用户即可在PC中获得手机发生崩溃后抓取的异常日志。
在另一个示例中，在手机完成升级的情况下，若手机崩溃后重启，则手机还可能基于升级后残留的数据显示第二提示信息，第二提示信息可以用于提示用户异常日志已存储于手机的指定存储路径下，其中指定存储路径可以根据需求进行设置，作为示例而非限定，指定存储路径可以为内存的/data路径。示例性地如图5中的(a)图所示，第二提示信息具体可以为“Ramdump已存储于/data路径下”，如此用户即可从/data路径下查找到手机抓取的异常日志。在一个示例中，“Ramdump已存储于/data路径下”所在的提示窗口中还包括关闭选项，该种情况下，用户可以点击该关闭选项，响应于用户对该关闭选项的点击操作，手机重新启动，如图5中的(b)图所示。在手机重新启动后，用户即可在/data路径下查找到异常日志。
需要说明的是，上述是以用户点击第二提示信息所在提示窗口中的关闭选项触发手机重新启动为例进行说明。在另一实施例中，手机还可以在显示第二提示信息后的预设时长后自动重新启动，本申请实施例对此不作限定。其中预设时长可以根据实际需求进行设置，譬如预设时长可以为20秒等。
需要说明的是，针对上述应用场景，手机可以根据残留的数据，确定在崩溃重启后显示第一提示信息，还是显示第二提示信息，具体内部实现流程可以参见下文的实施例。
另外，关于对异常日志的使用通常包括如下两种可能的应用场景：
在一种可能的应用场景中，在电子设备是从生产版本升级至用户版本的情况下，使用电子设备的通常是测试人员，则测试人员按照上述流程获取到异常日志后，就可以基于该异常日志对电子设备进行故障分析。
在另一种可能的应用场景中，在对电子设备的用户版本进行升级的情况下，使用电子设备的通常是用户，则用户按照上述流程获取到异常日志后，可以通过电子设备的后台提供的文件上传接口上传异常日志，以将异常日志发送给技术人员。譬如电子设备的后台可以在电子设备中提供有第二应用程序，若用户需要上传异常日志，则可以登录至第二应用程序，第二应用程序中提供有该文件上传接口，用户通过该文件上传接口上传异常日志至后台，以将异常日志发送给后台的技术人员。如此，技术人员即可远程获取到异常日志，之后，可以对异常日志进行分析，从而定位故障。进一步地，技术人员在确定故障后还可以向用户的电子设备下发故障原因、解决方案等信息，譬如可以通过第二应用程序进行下发，从而帮助用户解决故障问题。如此，可以使得技术人员远程定位故障，避免需要技术人员去现场维修，从而提高了故障定位的效率。
接下来对本申请实施例涉及的电子设备的软件系统进行介绍。请参考图6，图6是根据一示例性实施例示出的一种电子设备的软件系统的架构示意图，分层架构将软件分成若干个层，每一层都有清晰的角色和分工。层与层之间通过软件接口通信。在一些实施例中，将Android系统分为四层，从上至下分别为应用程序层，应用程序框架层，安卓运行时(Android runtime)和系统层，以及内核层。
另外，图6还示出了电子设备的硬件层与软件层之间的关系，硬件层包括但不限于DDR，显示屏，摄像头，传感器。其中DDR用于存储用户数据，譬如作为本申请的一个示例，可以用于存储系统升级后保留下的数据。
其中，应用程序层可以包括第一应用程序，第一应用程序可以电子设备中的任意一个应用程序，譬如，第一应用程序可以是但不限于相机，图库，日历，通话，地图，导航，蓝牙，音乐，视频，短信息等。
应用程序框架层为应用程序层的应用程序提供应用编程接口(applicationprogramming interface，API)和编程框架。应用程序框架层包括一些预先定义的函数。如图6所示，应用程序框架层可以包括窗口管理器，内容提供器，视图系统，电话管理器，资源管理器，通知管理器等。
窗口管理器用于管理窗口程序。窗口管理器可以获取显示屏大小，判断是否有状态栏，锁定屏幕，截取屏幕等。内容提供器用来存放和获取数据，并使这些数据可以被应用程序访问，这些数据可以包括视频，图像，音频，拨打和接听的电话，浏览历史和书签，电话簿等。视图系统包括可视控件，比如显示文字的控件，显示图片的控件等。视图系统可用于构建应用程序的显示界面，显示界面可以由一个或多个视图组成，比如，包括显示短信通知图标的视图，包括显示文字的视图，以及包括显示图片的视图。电话管理器用于提供电子设备的通信功能，比如通话状态的管理(包括接通，挂断等)。资源管理器为应用程序提供各种资源，比如本地化字符串，图标，图片，布局文件，视频文件等。通知管理器使应用程序可以在状态栏中显示通知信息，可以用于传达告知类型的消息，可以短暂停留后自动消失，无需用户交互。比如，通知管理器被用于告知下载完成，消息提醒等。通知管理器还可以是以图表或滚动条文本形式出现在系统顶部状态栏的通知，比如后台运行的应用程序的通知。通知管理器还可以是以对话窗口形式出现在屏幕上的通知，比如在状态栏提示文本信息，发出提示音，电子设备振动，指示灯闪烁等。
Android Runtime包括核心库和虚拟机。Android runtime负责安卓系统的调度和管理。核心库包含两部分：一部分是java语言需要调用的功能函数，另一部分是安卓的核心库。应用程序层和应用程序框架层运行在虚拟机中。虚拟机将应用程序层和应用程序框架层的java文件执行为二进制文件。虚拟机用于执行对象生命周期的管理，堆栈管理，线程管理，安全和异常的管理，以及垃圾回收等功能。
系统库可以包括多个功能模块，比如：表面管理器(surface manager)，媒体库(Media Libraries)，三维图形处理库(比如：OpenGL ES)，2D图形引擎(比如：SGL)等。表面管理器用于对显示子系统进行管理，并且为多个应用程序提供了2D和3D图层的融合。媒体库支持多种常用的音频，视频格式回放和录制，以及静态图像文件等。媒体库可以支持多种音视频编码格式，比如：MPEG4，H.264，MP3，AAC，AMR，JPG，PNG等。三维图形处理库用于实现三维图形绘图，图像渲染，合成，和图层处理等。2D图形引擎是2D绘图的绘图引擎。
内核层是硬件和软件之间的层。内核层至少包含第一内核节点、第二内核节点、显示驱动，摄像头驱动，音频驱动，传感器驱动。第一内核节点和第二内核节点用于为上层的应用程序控制硬件提供接口。作为本申请的一个示例，在第一应用程序要向DDR内存中更新数据的情况下，可以调用第一内核节点和第二内核节点，以分别通过第一内核节点和第二内核节点将数据更新至DDR内存中。
在介绍完本申请实施例涉及的应用场景和执行主体后，接下来结合附图对本申请实施例提供的方法进行详细介绍。
请参考图7，图7是根据一示例性实施例示出的一种数据处理的方法的流程示意图。作为示例而非限定，该方法可以应用于第一电子设备中，第一电子设备可以为上述图6所示的电子设备，譬如第一电子设备可以是第一电子设备。该方法可以包括如下部分或者全部内容：
步骤701：在第一电子设备启动的情况下，微内核进程加载。
微内核进程用于在第一电子设备启动后进行硬件初始化、从存储器中加载Linux内核等至内存中、配置初始化寄存器等一系列初始化操作。在一个示例中，微内核进程为微内核(little kernel，LK)。
不难理解，第一电子设备启动的情况通常包括多种，譬如第一电子设备可能是在系统升级后自动重启，再如第一电子设备也可能是在用户长按开机键的情况下开机启动，又如第一电子设备还可能是在发生崩溃事件后自动重启，此外，第一电子设备还可能是在抓取异常日志后自动重启等。无论何种原因使得第一电子设备启动，在第一电子设备启动后，微内核进程就会进行加载。
步骤702：微内核进程获取启动指示信息。
启动指示信息用于指示系统启动的原因。在一个示例中，第一电子设备的芯片中提供有目标接口，该目标接口可以用于在第一电子设备启动的情况下确定启动原因，从而确定启动指示信息，并将启动指示信息存储在DDR内存中。如此，微内核进程在加载完成后即可从DDR内存中读取到启动指示信息，从而确定第一电子设备的启动原因。
作为示例而非限定，若启动指示信息为“T”，则可以表示启动原因是正常重启，譬如可以用于表示系统升级后自动重启。若启动指示信息为“F”，则可以表示启动原因是崩溃后重启。
步骤703：微内核进程基于启动指示信息确定启动原因是否是发生崩溃事件。
若基于启动指示信息确定启动原因不是发生崩溃事件，说明第一电子设备可能是在检测到用户对开机键的长按操作后正常开机启动，或者也可能是系统升级后自动重启，又或者还可能是在抓取异常日志后自动重启。在该种情况下，第一电子设备进入如下步骤704的操作。否则，若基于启动指示信息确定启动原因是崩溃后重启，也即是崩溃事件触发第一电子设备重启，则第一电子设备进入如下步骤709，以执行步骤709以及后续步骤的操作。
步骤704：微内核进程加载内核。
在内核加载完成后，第一电子设备完成重启操作。之后，用户即可正常使用第一电子设备。
在第一电子设备正常使用的过程中，用户可能会打开某个应用程序实现某种业务，譬如打开天气应用程序查看天气情况等，在该种情况下，第一电子设备还执行如下步骤705至步骤708的操作：
步骤705：第一应用程序接收启动操作。
第一应用程序为第一电子设备中安装的任意一个应用程序。
在一个示例中，用户可能点击第一电子设备中的任意一个应用程序(也即第一应用程序)的应用图标，以启动第一应用程序来实现某种业务。
步骤706：第一应用程序进行加载。
也即响应于用户对第一应用程序的应用图标的点击操作，第一应用程序开始加载。
步骤707：第一应用程序读取目标XML文件。
目标XML文件中包括最近一次系统升级后保留下的目标数据。作为本申请的一个示例，用户在使用第一电子设备的过程中，如果第一电子设备接收到后台推送的用于升级系统的升级包，则用户可以按照上述图1所示的流程对第一电子设备进行升级。第一电子设备在完成升级后，将升级包中携带的目标XML文件存储至指定文件系统路径下，也即目标XML文件在系统升级后生效。
作为本申请的一个示例，目标数据包括第一崩溃事件处理标志和第一转储模式标志，第一崩溃事件处理标志用于标识在发生崩溃事件的情况下所要执行的操作，第一转储模式标志用于标识异常日志获取模式。
作为示例而非限定，目标XML文件命名为hn_dump_mode.xml，第一崩溃事件处理处理标志可以表示为crash_flag1，第一转储模式标志可以表示为dump_mode1。
指定文件系统路径可以根据实际需求进行设置。作为示例而非限定，指定文件系统路径可以为/system或者/vendor等文件系统路径。
如此，第一应用程序在启动后，可以从指定文件系统路径下查找到目标XML文件，并读取目标XML文件中的目标数据。譬如以指定文件系统路径是/system为例，第一应用程序从/system路径下查找到目标XML文件，从目标XML文件中读取目标数据。
步骤708：第一应用程序将目标XML文件中的目标数据更新至DDR内存中。
根据前文可知，目标数据中可能包括多种不同的标志，譬如包括第一崩溃事件处理标志和第一转储模式标志。针对目标数据中的不同标志，第一应用程序可以分别通过不同的内核节点更新至DDR内存中。作为本申请的一个示例，以目标数据中包括第一崩溃事件处理标志和第一转储模式标志为例，此时，第一应用程序将目标数据存储至DDR内存中的具体实现可以包括：第一应用程序将第一崩溃事件处理标志发送给第一内核节点，以及将第一转储模式标志发送给第二内核节点，相应地，第一内核节点将第一崩溃事件处理标志写入DDR内存中，以及第二内核节点将第一转储模式标志写入DDR内存中。
在一个示例中，第一电子设备可以在DDR内存的共享内存中扩展8字节的内存字段，其中共享内存中的数据在第一电子设备重启前后保留。该共享内存的前4个字节的内存字段可以用于存储第一崩溃事件处理标志，后4个字节的内存字段用于存储第一转储模式标志。如此，第一内核节点在接收到第一应用程序发送的第一崩溃事件处理标志后，可以将第一崩溃事件处理标志写入该共享内存的前4个字节的内存字段中，第二内核节点在接收到第一应用程序发送的第一转储模式标志后，可以将第一转储模式标志写入该共享内存的后4个字节的内存字段中。
此外，请参考图8，第一电子设备在将目标数据存储于DDR内存中之后，删除expdb中的目标数据，也即剔除expdb分区中残留的数据。
如此可见，对于第一电子设备中的第一应用程序，当第一应用程序启动后，可以读取目标XML文件中的内容，并将目标XML文件中的内容更新至DDR内存中。由于目标XML文件中的目标数据不再存储于expdb分区中，而是存储在DDR内存中，而DDR内存中的数据在第一电子设备下电后可清除，所以可以避免目标数据长期存在于expdb分区中所带来的安全隐患问题。
步骤709：微内核进程从DDR内存中读取第一崩溃事件处理标志。
根据前文所述可知，在第一电子设备升级重启后，会通过第一应用程序将第一崩溃事件处理标志和第一转储模式标志更新至DDR内存中，所以在基于启动指示信息确定启动原因是崩溃后重启的情况下，为了判断是否需要抓取异常日志，微内核进程可以从DDR内存中读取第一崩溃事件处理标志，譬如从DDR内存的共享内存地址中读取前4个字节的数据，得到第一崩溃事件处理标志。
需要说明的是，由于崩溃后重启不是完全下电，所以DDR内存中的数据不会消失。
步骤710：微内核进程根据第一崩溃事件处理标志确定是否进入内核崩溃转储模式。
在一种可能的情况下，第一崩溃事件处理标志为第一数值，此时第一崩溃事件处理标志用于指示在发生崩溃事件的情况下所要执行的操作为开启内核崩溃转储模式。第一数值可以根据实际需求进行设置，作为示例而非限定，第一数值为1。在另一种可能的情况下，第一崩溃事件处理标志为第二数值，此时第一崩溃事件处理标志用于指示在发生崩溃事件的情况下所要指定的操作为启动操作。第二数值可以根据实际需求进行设置，作为示例而非限定，第二数值为0。不难理解，第一崩溃事件处理标志为第一数值或者第二数值是由技术人员通过升级包下发的。
若根据第一崩溃事件处理标志确定进入内核崩溃转储模式，譬如第一崩溃事件处理标志为第一数值，则第一电子设备进入如下步骤711以及后续步骤的操作。否则，若根据第一崩溃事件处理标志确定不进入内核崩溃转储模式，譬如第一崩溃事件处理标志为第二数值，或者第一崩溃事件崩溃处理标志为随机值，则第一电子设备进入步骤704至708的操作。
需要说明的是，针对第一崩溃事件处理标志为随机值的情况：由于DDR内存中的数据在第一电子设备下电后会消失，而在一种可能的情况下，第一电子设备启动的原因是在用户强制关机的情况下再次检测到用户对开机键的长按操作，也即第一电子设备是在下电后重启，此时DDR内存中不再存储有目标数据，因此从DDR中读取到的第一崩溃事件处理标志可能是一个随机值。
步骤711：微内核进程从DDR内存中读取第一转储模式标志。
也即在根据第一崩溃事件处理标志确定进入内核崩溃转储模式的情况下，为了确定采用何种方式获取异常日志，微内核进程从DDR内存中读取第一转储模式标志，譬如从DDR内存的共享内存地址中读取后4个字节的数据，得到第一转储模式标志。
同理，第一转储模式标志也是由升级包携带的，也即由技术人员通过升级包下发于第一电子设备中。在一种可能的情况下，第一转储模式标志为第三数值，此时第一转储模式标志用于指示异常日志获取模式为通过USB接口输出，在一些示例中，此时的第一转储模式标志又可以称为USB dump标志，也即第一转储模式标志用于指示所启动的内核崩溃转储模式为USB转储模式，这意味着通过USB接口接入第二电子设备(譬如PC)即可获取第一电子设备所抓取的异常日志。在另一种可能的情况下，第一转储模式标志为第四数值，此时第一转储模式标志用于指示异常日志获取模式为从内存中获取，也即第一转储模式标志用于指示所启动的内核崩溃转储模式为内存故障dump模式，此时意味着第一电子设备抓取的异常日志存储于第一电子设备的内存中。
其中，第三数值和第四数值均可以根据实际需求进行设置。作为示例而非限定，第三数值可以与第二数值相同，第四数值可以与第一数值相同，也即第三数值可以为0，第四数值可以为1。
若第一转储模式标志用于指示异常日志获取模式为通过USB接口输出，譬如第一转储模式标志为第三数值，则第一电子设备进入如下步骤712的操作。若第一转储模式标志指示异常日志获取模式为从内存中获取，譬如第一转储模式标志为第四数值，则第一电子设备进入如下步骤717的操作。
步骤712：在第一转储模式标志用于指示异常日志获取模式为通过USB接口输出的情况下，微内核进程显示第一提示信息。
第一提示信息用于提示用户通过USB接口接入第二电子设备以获取异常日志。
也即在第一转储模式标志用于指示异常日志获取模式为通过USB接口输出的情况下，微内核进程显示的提示信息为第一提示信息，以使得使用第一电子设备的用户可以获知如何能够获取到异常日志。
作为本申请的一个示例，微内核进程显示第一提示信息的具体实现可以包括：微内核进程确定第一提示信息，将第一提示信息发送给视图系统，视图系统显示第一提示信息。也即由微内核进程确定第一提示信息的提示内容，然后通知视图系统显示第一提示信息。
作为本申请的一个示例，在显示第一提示信息后，还可以包括如下步骤713至步骤715的操作：
步骤713：响应于通过USB接口接入第二电子设备的用户操作，微内核进程监听USB接口。
第一电子设备显示第一提示信息后，用户可以通过USB数据线连接第一电子设备和第二电子设备。响应于该用户操作，第一电子设备监听USB接口，以等待与第二电子设备建立数据传输通道。
作为示例而非限定，请参考图3中的(c)图，用户通过USB数据线连接手机与PC后，手机可以不再显示第一提示信息。当然，在PC端可以显示有“请打开指定工具”的提示内容。
步骤714：若通过USB接口监听到第二电子设备的数据传输通道建立请求，则与第二电子设备建立数据传输通道。
示例性地，请参考图3中的(b)图，用户点击PC中的“请打开指定工具”的提示内容。相应地，响应于用户对PC中的“请打开指定工具”的点击操作，PC通过指定工具请求与手机建立数据传输通道，相应地，手机与PC开始建立数据传输通道。
步骤715：在数据传输通道建立成功的情况下，微内核进程调用第一内核崩溃转储模块抓取异常日志。
第一内核崩溃转储模块可以是微内核进程中一个用于抓取异常日志的功能函数。
在数据传输通道建立成功的情况下，微内核进程调用第一内核崩溃转储模块，以通过第一内核崩溃转储模块抓取异常日志。
步骤716：第一内核崩溃转储模块通过数据传输通道向第二电子设备传输异常日志。
也即第一内核崩溃转储模块抓取完异常日志后，将异常日志通过数据传输通道发送给第二电子设备。如此，用户即可在第二电子设备中获取到异常日志。
之后，第一电子设备进入如下步骤719的操作。
步骤717：在第一转储模式标志指示异常日志获取模式为从内存中获取的情况下，微内核进程调用第二内核崩溃转储模块抓取异常日志。
第二内核崩溃转储模块可以是微内核进程中另一个用于抓取异常日志的功能函数。
也即在第一转储模式标志指示异常日志获取模式为从内存中获取的情况下，微内核进程直接调用第二内核崩溃转储模块抓取异常日志。第二内核崩溃转储模块抓取完异常日志之后，可以将所抓取的异常日志存储于第一电子设备的内存中，譬如可以存储至内存的指定存储路径下，指定存储路径可以为/data。
步骤718：在通过第二内核崩溃转储模块完成异常日志抓取操作后，显示第二提示信息。
也即此时显示的提示信息为第二提示信息。第二提示信息用于指示用户异常日志已存储于指定存储路径下。
在通过第二内核崩溃转储模块完成异常日志抓取操作后，为了提示用户如何获取到该异常日志，第二内核崩溃转储模块显示第二提示信息，以通过第二提示信息对用户进行提示。
在一个示例中，第二内核崩溃转储模块显示第二提示信息的具体实现可以包括：第二内核崩溃转储模块确定第二提示信息，将第二提示内容发送给视图系统，由视图系统显示第二提示内容。也即第二内核崩溃转储模块确定第二提示信息的提示内容，之后，通过视图系统显示第二提示信息。
进一步地，在显示第二提示信息后，响应于用户关闭第二提示信息的用户操作，微内核进程触发第一电子设备重启。譬如请参考图5，在用户点击关闭选项后，第一电子设备重新启动，也即，第一电子设备进入如下步骤719的操作。
步骤719：异常日志抓取结束后，系统重新启动。
在一个示例中，异常日志抓取结束后，微内核进程可以直接加载内核，以完成系统启动。
当然在另一个示例中，异常日志抓取结束后也可以重新加载微内核进程，本申请实施例对此不作限定。
在一个示例中，异常日志抓取结束后，第一电子设备还可以清除DDR内存中的第一崩溃事件处理标志和第一转储模式标志。
此外，作为本申请的一个示例，当后台的技术人员想要修改目标数据时，还可以进行在线修改。譬如技术人员可以通过在线修改程序向第一电子设备发送在线修改指令，在线修改指令中携带第二崩溃事件处理标志和第二转储模式标志。相应地，第一电子设备接收该在线修改指令，之后，将目标XML文件中的第一崩溃事件处理标志修改为第二崩溃事件处理标志，以及将目标XML文件中的第一转储模式标志修改为第二转储模式标志。如此，在下一个第一应用程序启动后，即可将目标XML文件中更新后的第二崩溃事件处理标志和第二转储模式标志更新至DDR内存中，从而实现对第一崩溃事件处理标志和第一转储模式标志的在线修改。
在一个示例中，在线修改程序可以为热补丁程序。
进一步地，由于目标XML文件支持在线修改，所以对于第一应用程序来说，在读取目标XML文件中的内容后，还可以检测目标XML文件中的内容是否有更新，如果有更新，则将更新后的内容更新至DDR内存中，否则，如果没有更新，则可以不执行将目标XML文件中的内容更新至DDR内存中的操作。
值得一提的是，由于目标XML文件支持在线修改，且不需要系统重启即可生效，另外对于用户是不感知的，譬如如图9所示，在目标XML文件修改前后，第一电子设备的界面不会有关于目标XML文件更新的相关变化，所以在无需重启系统的情况下即可修改第一崩溃事件处理标志和第二转储模式标志，可以提高管理效率，并且，由于对于用户是无感知的，不需要重启系统，从而提高了用户体验。
在本申请实施例中，在系统升级后，将升级保留下的目标数据存储至DDR内存中，由于DDR内存中的数据在第一电子设备下电后可消失，所以使得目标数据不会长期存在于第一电子设备的expdb分区中，从而可以避免目标数据带来的安全隐患问题。
此外，第一电子设备在崩溃重启后，可以从DDR内存中读取第一崩溃事件处理标志，以根据第一崩溃事件处理标志确定针对崩溃事件所要执行的操作。在第一崩溃事件处理标志指示发生崩溃事件后所要执行的操作为开启内核崩溃转储模式的情况下，从DDR内存中读取第一转储模式标志，根据第一转储模式标志，开启对应的内核崩溃转储模式获取异常日志，使得用户可以获得异常日志，从而便于对第一电子设备进行故障分析。
需要说明的是，上述实施例是以在系统升级的场景下会存在目标数据为例进行说明。在另一种可能的场景中，在第一电子设备的用户版本提供有热补丁程序的情况下，目标数据还可能是通过热补丁程序写入第一电子设备中的，针对该种情况，同样可以按照上述流程对目标数据进行转储，也即将目标数据存于DDR内存中。
根据前文记载可知，第一电子设备的启动原因可能包括多种，并且在启动原因不同的情况下，第一电子设备启动后执行的流程操作不同，为了便于理解，接下来分别通过如下图10和图11所示的实施例分别对本申请实施例提供的方法进行介绍。
请参考图10，图10是根据一示例性实施例示出的一种数据处理的方法的流程示意图，这里以第一电子设备的启动原因是正常启动，也即不是崩溃后重启为例进行说明，在该种情况下，该方法可以包括如下内容：
步骤1001：在第一电子设备启动的情况下，微内核进程加载。
在一种可能的情况下，第一电子设备是系统升级后自动重启。在另一种可能的情况下，第一电子设备是在检测到用户长按开机键的情况下启动。在又一种可能的情况下，第一电子设备是在完成异常日志抓取后自动重启。
步骤1002：微内核进程从DDR内存中读取启动指示信息。
启动指示信息用于指示系统启动的原因。
在本申请实施例中，启动指示信息指示启动原因为正常启动，也即不是崩溃后重启。
步骤1003：在根据启动指示信息确定系统正常启动的情况下，微内核进程加载内核。
譬如在系统升级后重启的情况下，为了完成重启操作，微内核进程对内核进行加载。
步骤1004：在系统完成重启的情况下，第一应用程序接收启动操作。
微内核进程加载内核后，系统完成重启操作，之后，用户即可使用第一电子设备执行一些业务，譬如用户点击第一电子设备中的第一应用程序，相应地，第一电子设备检测到对第一应用程序的启动操作。
步骤1005：第一应用程序进行加载。
步骤1006：第一应用程序读取目标XML文件中的第一崩溃事件处理标志和第一转储模式标志。
第一应用程序加载完成后，读取目标XML文件中的目标数据，本申请实施例以目标数据包括第一崩溃事件处理标志和第一转储模式标志为例进行说明。
步骤1007：第一应用程序将第一崩溃事件处理标志发送给第一内核节点，以及将第一转储模式标志发送给第二内核节点。
步骤1008：第一内核节点将第一崩溃事件处理标志更新至DDR内存中。
如前文所述，第一内核节点可以将第一崩溃事件处理标志写入DDR内存的共享内存的前4个字节的内存字段中。
步骤1009：第二内核节点将第一转储模式标志更新至DDR内存中。
如前文所述，第二内核节点可以将第一转储模式标志写入共享内存的后4个字节的内存字段中。
需要说明的是，步骤1008与步骤1009之间没有严格的先后执行顺序。在一个示例中，步骤1008与步骤1009并行执行。
此外，第二内核节点将第一转储模式标志更新至DDR内存中之后，微内核进程删除expdb分区中的目标数据。
进一步地，第一电子设备还可以接收对目标XML文件的在线修改指令，譬如可以由第一电子设备中的第二应用程序接收该在线修改指令，之后根据该在线修改指令对目标XML文件中的目标数据进行修改，并将修改后的目标数据更新至DDR内存中。其中，第二应用程序可以是用于对第一电子设备中的配置文件等进行管理的应用程序，譬如第二应用程序可以是由后台在第一电子设备出厂时提供的应用程序。
在本申请实施例中，在系统升级后，将升级保留下的目标数据存储至DDR内存中，由于DDR内存中的数据在第一电子设备下电后可消失，所以使得目标数据不会长期存在于DDR内存中，从而可以避免目标数据给第一电子设备带来安全隐患的问题。
需要说明的是，在目标数据存在于目标XML文件的情况下，由于是以文件的形式存在，而不是直接存储于分区的内存地址中，所以不会对第一电子设备的运行产生影响，因此即使目标XML文件长期存在也不会给第一电子设备带来安全隐患。
请参考图11，图11是根据一示例性实施例示出的一种对目标数据的应用方法的流程图，这里以第一电子设备是在崩溃后重启的情况下为例进行说明，具体地，该方法可以包括如下内容：
步骤1101：在第一电子设备启动的情况下，微内核进程加载。
在本申请实施例中，第一电子设备在发生崩溃事件后重启，之后，微内核进程加载。
步骤1102：微内核进程从DDR内存中读取启动指示信息。
启动指示信息用于指示系统启动的原因。
不难理解，这里的启动是系统崩溃后重启，所以，启动指示信息指示启动原因为崩溃后重启，也即不是正常启动。
步骤1103：在根据启动指示信息确定是系统崩溃后重启的情况下，微内核进程从DDR内存中读取第一崩溃事件处理标志。
在一种可能的情况下，第一崩溃事件处理标志为第一数值，此时第一崩溃事件处理标志用于指示发生崩溃事件后所要执行的操作是开启内核崩溃转储模式。在该种情况下，进入如下步骤1104的操作。
在另一种可能的情况下，第一崩溃事件处理标志为第二数值，此时第一崩溃事件处理标志用于指示发生崩溃事件后所要执行的操作是系统重启。在该种情况下，微内核进程触发系统启动。其中，微内核进程触发系统启动的流程可以参见上述图7所示实施例中的步骤704至步骤709。
步骤1104：在第一崩溃事件处理标志为第一数值的情况下，微内核进程从DDR内存中读取第一转储模式标志。
步骤1105：微内核进程根据第一转储模式标志，显示提示信息。
在一种可能的情况下，第一转储模式标志为第三数值，此时第一转储模式标志用于指示异常日志获取模式为通过USB接口输出。在该种情况下，显示的提示信息为第一提示信息，其具体实现可以参见上述图7所示实施例的步骤712。
在另一种可能的情况下，第一转储模式标志为第四数值，此时第一转储模式标志用于指示异常日志获取模式为从内存中获取。在该种情况下，显示的提示信息为第二提示信息，其具体实现可以参见上述图7所示实施例的步骤717至步骤718。
步骤1106：接收用户根据提示信息执行的至少一个用户操作，依次响应至少一个用户操作中的每个用户操作。
根据显示的提示信息不同，用户操作不同。在一种情况下，若根据第一转储模式标志显示第一提示信息，则接收用户根据提示信息执行的至少一个用户操作，依次响应至少一个用户操作中的每个用户操作的具体实现可以参见上述图7所示实施例中的步骤713至步骤716。
在另一种情况下，若根据第一转储模式标志显示第二提示信息，则接收用户根据提示信息执行的至少一个用户操作，依次响应至少一个用户操作中的每个用户操作的具体实现包括：响应于关闭第二提示信息的用户操作，微内核进程重启第一电子设备。
在本申请实施例中，通过配置第一崩溃事件处理标志和第一转储模式标志，可以使得第一电子设备在发生崩溃事件后，引导用户获取第一电子设备所抓取异常日志，便于用户可以基于异常日志进行故障分析，或者将异常日志上报给后台，方便后台可以远程定位用户故障。
图12是本申请实施例提供的一种数据处理装置的结构示意图，该装置可以由软件、硬件或者两者的结合实现成为计算机设备的部分或者全部，该计算机设备可以为上述第一电子设备。参见图12，该装置包括：
启动模块1210，用于响应于对第一应用程序的启动操作，启动所述第一应用程序，所述第一应用程序为所述第一电子设备中的任意一个应用程序；
读取模块1220，用于通过所述第一应用程序读取目标可扩展标记语言XML文件中的目标数据，所述目标XML文件是在用于进行所述最近一次系统升级的升级包中携带且在系统升级后生效的；
存储模块1230，用于通过所述第一应用程序将所述目标数据存储至所述DDR内存中；
删除模块1240，用于删除二进制分区中的所述目标数据。
作为本申请的一个示例，所述装置还用于：
在系统崩溃后重启的情况下，显示提示信息，所述提示信息是在根据目标数据确定进入内核崩溃转储模式的情况下显示，所述提示信息用于指示异常日志的获取方式，所述目标数据是所述第一电子设备最近一次系统升级后保留下的数据；
接收用户根据所述提示信息执行的至少一个用户操作，依次响应所述至少一个用户操作中的每个用户操作。
作为本申请的一个示例，所述装置还用于：
响应于对第一应用程序的启动操作，启动所述第一应用程序，所述第一应用程序为所述第一电子设备中的任意一个应用程序；
通过所述第一应用程序读取目标可扩展标记语言XML文件中的目标数据，所述目标XML文件是在用于进行所述最近一次系统升级的升级包中携带且在系统升级后生效的；
通过所述第一应用程序将所述目标数据存储至所述DDR内存中；
删除二进制分区中的所述目标数据。
作为本申请的一个示例，所述目标数据包括第一崩溃事件处理标志和第一转储模式标志，所述第一崩溃事件处理标志用于标识在发生崩溃事件的情况下所要执行的操作，所述第一转储模式标志用于标识异常日志获取模式；
所述装置用于：
在系统崩溃后重启的情况下，从所述DDR内存中读取所述第一崩溃事件处理标志；
在所述第一崩溃事件处理标志为第一数值的情况下，从所述DDR内存中读取所述第一转储模式标志，所述第一数值用于指示在发生崩溃事件的情况下所要执行的操作为开启内核崩溃转储模式；
根据所述第一转储模式标志，显示所述提示信息。
作为本申请的一个示例，在所述第一转储模式标志指示异常日志获取模式为通过通用串行总线USB接口输出的情况下，所述提示信息用于指示用户通过USB接口接入第二电子设备以获取所述异常日志；或者，在所述第一转储模式标志指示异常日志获取模式为从内存中获取的情况下，所述提示信息用于指示用户所述异常日志已存储于指定存储路径下。
作为本申请的一个示例，在所述第一转储模式标志指示异常日志获取模式为通过USB接口输出的情况下，所述装置用于：
响应于通过所述USB接口接入所述第二电子设备的用户操作，监听所述USB接口；
若通过所述USB接口监听到所述第二电子设备的数据传输通道建立请求，则与所述第二电子设备建立所述数据传输通道；
在所述数据传输通道建立成功的情况下，通过第一内核崩溃转储模块抓取所述异常日志；
通过第一内核崩溃转储模块，利用所述数据传输通道向所述第二电子设备传输所述异常日志。
作为本申请的一个示例，在所述第一转储模式标志指示异常日志获取模式为从内存中获取的情况下，所述装置用于：
通过第二内核崩溃转储模块抓取所述异常日志；
通过所述第二内核崩溃转储模块将所述异常日志存储于所述指定存储路径下；
响应于关闭所述第二提示信息的用户操作，重启所述第一电子设备。
作为本申请的一个示例，所述装置还用于：
在系统启动的情况下，从所述DDR内存中读取启动指示信息，所述启动指示信息用于指示系统启动的触发原因；
在所述启动指示信息指示所述第一电子设备在系统启动前发生崩溃事件的情况下，确定所述第一电子设备是系统崩溃后重启。
作为本申请的一个示例，所述装置还用于：
在完成异常日志抓取操作后，清除所述DDR内存中存储的所述第一崩溃事件处理标志和所述第一转储模式标志。
作为本申请的一个示例，所述装置还用于：
在系统崩溃后重启的情况下，在所述第一崩溃事件处理标志为第二数值的情况下，加载所述第一电子设备的内核，所述第二数值用于指示在发生崩溃事件的情况下所要执行的操作为启动操作。
作为本申请的一个示例，所述装置还用于：
接收在线修改指令，所述在线修改指令中携带第二崩溃事件处理标志和第二转储模式标志；
将所述目标XML文件中的第一崩溃事件处理标志修改为所述第二崩溃事件处理标志，以及将所述目标XML文件中的第一转储模式标志修改为所述第二转储模式标志。
在本申请实施例中，在系统升级后，将升级保留下的目标数据存储至DDR内存中，由于DDR内存中的数据在第一电子设备下电后可消失，所以使得目标数据不会长期存在于第一电子设备的expdb分区中，从而可以避免目标数据带来的安全隐患问题。
此外，第一电子设备在崩溃重启后，可以从DDR内存中读取第一崩溃事件处理标志，以根据第一崩溃事件处理标志确定针对崩溃事件所要执行的操作。在第一崩溃事件处理标志指示发生崩溃事件后所要执行的操作为开启内核崩溃转储模式的情况下，从DDR内存中读取第一转储模式标志，根据第一转储模式标志，开启对应的内核崩溃转储模式获取异常日志，使得用户可以获得异常日志，从而便于对第一电子设备进行故障分析。
需要说明的是：上述实施例提供的数据处理装置在处理数据时，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将装置的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。
上述实施例中的各功能单元、模块可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中，上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。另外，各功能单元、模块的具体名称也只是为了便于相互区分，并不用于限制本申请实施例的保护范围。
上述实施例提供的数据处理装置与数据处理方法实施例属于同一构思，上述实施例中单元、模块的具体工作过程及带来的技术效果，可参见方法实施例部分，此处不再赘述。
图13是本申请实施例提供的一种电子设备的结构示意图，该电子设备可以为上述第一电子设备或第二电子设备。参见图13，电子设备100可以包括处理器110，外部存储器接口120，内部存储器121，通用串行总线(universal serial bus，USB)接口130，充电管理模块140，电源管理模块141，电池142，天线1，天线2，移动通信模块150，无线通信模块160，音频模块170，扬声器170A，受话器170B，麦克风170C，耳机接口170D，传感器模块180，按键190，马达191，指示器192，摄像头193，显示屏194，以及用户标识模块(subscriberidentification module，SIM)卡接口195等。其中，传感器模块180可以包括压力传感器180A，陀螺仪传感器180B，气压传感器180C，磁传感器180D，加速度传感器180E，距离传感器180F，接近光传感器180G，指纹传感器180H，温度传感器180J，触摸传感器180K，环境光传感器180L，骨传导传感器180M等。
可以理解的是，本申请实施例示意的结构并不构成对电子设备100的具体限定。在本申请另一些实施例中，电子设备100可以包括比图示更多或更少的部件，或者组合某些部件，或者拆分某些部件，或者不同的部件布置。图示的部件可以以硬件，软件或软件和硬件的组合实现。
处理器110可以包括一个或多个处理单元，比如：处理器110可以包括应用处理器(application processor，AP)，调制解调处理器，图形处理器(graphics processingunit，GPU)，图像信号处理器(image signal processor，ISP)，控制器，存储器，视频编解码器，数字信号处理器(digital signal processor，DSP)，基带处理器，和/或神经网络处理器(neural-network processing unit，NPU)等。其中，不同的处理单元可以是独立的器件，也可以集成在一个或多个处理器中。
其中，控制器可以是电子设备100的神经中枢和指挥中心。控制器可以根据指令操作码和时序信号，产生操作控制信号，完成取指令和执行指令的控制。
处理器110中还可以设置存储器，用于存储指令和数据。在一些实施例中，处理器110中的存储器为高速缓冲存储器。该存储器可以保存处理器110刚用过或循环使用的指令或数据。如果处理器110需要再次使用该指令或数据，可从该存储器中直接调用。避免了重复存取，减少了处理器110的等待时间，因而提高了系统的效率。
在一些实施例中，处理器110可以包括一个或多个接口，如可以包括集成电路(inter-integrated circuit，I2C)接口，集成电路内置音频(inter-integrated circuitsound，I2S)接口，脉冲编码调制(pulse code modulation，PCM)接口，通用异步收发传输器(universal asynchronous receiver/transmitter，UART)接口，移动产业处理器接口(mobile industry processor interface，MIPI)，通用输入输出(general-purposeinput/output，GPIO)接口，用户标识模块(subscriber identity module，SIM)接口，和/或通用串行总线(universal serial bus，USB)接口等。
USB接口130是符合USB标准规范的接口，具体可以是Mini USB接口，Micro USB接口，USB Type C接口等。USB接口130可以用于连接充电器为电子设备100充电，也可以用于电子设备100与外围设备之间传输数据。也可以用于连接耳机，通过耳机播放音频。USB接口130还可以用于连接其他终端，比如AR设备等。
可以理解的是，本申请实施例示意的各模块间的接口连接关系，只是示意性说明，并不构成对电子设备100的结构限定。在本申请另一些实施例中，电子设备100也可以采用上述实施例中不同的接口连接方式，或多种接口连接方式的组合。
充电管理模块140用于从充电器接收充电输入。其中，充电器可以是无线充电器，也可以是有线充电器。在一些有线充电的实施例中，充电管理模块140可以通过USB接口130接收有线充电器的充电输入。在一些无线充电的实施例中，充电管理模块140可以通过电子设备100的无线充电线圈接收无线充电输入。充电管理模块140为电池142充电的同时，还可以通过电源管理模块141为电子设备100供电。
电源管理模块141用于连接电池142，充电管理模块140与处理器110。电源管理模块141接收电池142和/或充电管理模块140的输入，为处理器110，内部存储器121，外部存储器，显示屏194，摄像头193和无线通信模块160等供电。电源管理模块141还可以用于监测电池容量，电池循环次数，电池健康状态(漏电，阻抗)等参数。在其他一些实施例中，电源管理模块141也可以设置于处理器110中。在另一些实施例中，电源管理模块141和充电管理模块140也可以设置于同一个器件中。
电子设备100的无线通信功能可以通过天线1，天线2，移动通信模块150，无线通信模块160，调制解调处理器以及基带处理器等实现。
电子设备100通过GPU，显示屏194，以及应用处理器等实现显示功能。GPU为图像处理的微处理器，连接显示屏194和应用处理器。GPU用于执行数学和几何计算，用于图形渲染。处理器110可包括一个或多个GPU，其执行程序指令以生成或改变显示信息。
显示屏194用于显示图像，视频等。显示屏194包括显示面板。显示面板可以采用液晶显示屏(liquid crystal display，LCD)，有机发光二极管(organic light-emittingdiode，OLED)，有源矩阵有机发光二极体或主动矩阵有机发光二极体(active-matrixorganic light emitting diode，AMOLED)，柔性发光二极管(flex light-emittingdiode，FLED)，Miniled，MicroLed，Micro-oLed，量子点发光二极管(quantum dot lightemitting diodes，QLED)等。在一些实施例中，电子设备100可以包括1个或N个显示屏194，N为大于1的整数。
外部存储器接口120可以用于连接外部存储卡，比如Micro SD卡，实现扩展电子设备100的存储能力。外部存储卡通过外部存储器接口120与处理器110通信，实现数据存储功能。比如将音乐，视频等文件保存在外部存储卡中。
内部存储器121可以用于存储计算机可执行程序代码，计算机可执行程序代码包括指令。处理器110通过运行存储在内部存储器121的指令，来执行电子设备100的各种功能应用以及数据处理。内部存储器121可以包括存储程序区和存储数据区。其中，存储程序区可存储操作系统，至少一个功能所需的应用程序(比如声音播放功能，图像播放功能等)等。存储数据区可存储电子设备100在使用过程中所创建的数据(比如音频数据，电话本等)等。此外，内部存储器121可以包括高速随机存取存储器，还可以包括非易失性存储器，比如至少一个磁盘存储器件，闪存器件，通用闪存存储器(universal flash storage，UFS)等。
按键190包括开机键，音量键等。按键190可以是机械按键，也可以是触摸式按键。电子设备100可以接收按键输入，产生与电子设备100的用户设置以及功能控制有关的键信号输入。
在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意结合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机指令时，全部或部分地产生按照本申请实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络或其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，比如，所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(比如：同轴电缆、光纤、数据用户线(Digital Subscriber Line，DSL))或无线(比如：红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存取的任何可用介质，或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质(比如：软盘、硬盘、磁带)、光介质(比如：数字通用光盘(Digital Versatile Disc，DVD))或半导体介质(比如：固态硬盘(Solid State Disk，SSD))等。
以上所述为本申请提供的可选实施例，并不用以限制本申请，凡在本申请的揭露的技术范围之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。

Claims (12)

1.一种数据处理的方法，其特征在于，应用于第一电子设备，所述方法包括：
响应于对第一应用程序的启动操作，启动所述第一应用程序，所述第一应用程序为所述第一电子设备中的任意一个应用程序；
所述第一应用程序读取目标可扩展标记语言XML文件中的目标数据，所述目标XML文件是在用于进行最近一次系统升级的升级包中携带且在系统升级后生效的；
所述第一应用程序将所述目标数据存储至所述第一电子设备的双倍速率DDR内存中；
删除所述第一电子设备的二进制分区中的所述目标数据。
2.如权利要求1所述的方法，其特征在于，所述第一应用程序将所述目标数据存储至所述第一电子设备的双倍速率DDR内存中之后，还包括：
在系统崩溃后重启的情况下，显示提示信息，所述提示信息是在根据所述目标数据确定进入内核崩溃转储模式的情况下显示，所述提示信息用于指示异常日志的获取方式；
接收用户根据所述提示信息执行的至少一个用户操作，依次响应所述至少一个用户操作中的每个用户操作。
3.如权利要求2所述的方法，其特征在于，所述目标数据包括第一崩溃事件处理标志和第一转储模式标志，所述第一崩溃事件处理标志用于标识在发生崩溃事件的情况下所要执行的操作，所述第一转储模式标志用于标识异常日志获取模式；
所述在系统崩溃后重启的情况下，显示提示信息，包括：
在系统崩溃后重启的情况下，从所述DDR内存中读取所述第一崩溃事件处理标志；
在所述第一崩溃事件处理标志为第一数值的情况下，从所述DDR内存中读取所述第一转储模式标志，所述第一数值用于指示在发生崩溃事件的情况下所要执行的操作为开启内核崩溃转储模式；
根据所述第一转储模式标志，显示所述提示信息。
4.如权利要求3所述的方法，其特征在于，在所述第一转储模式标志指示异常日志获取模式为通过通用串行总线USB接口输出的情况下，所述提示信息用于指示用户通过USB接口接入第二电子设备以获取所述异常日志；或者，在所述第一转储模式标志指示异常日志获取模式为从内存中获取的情况下，所述提示信息用于指示用户所述异常日志已存储于指定存储路径下。
5.如权利要求4所述的方法，其特征在于，在所述第一转储模式标志指示异常日志获取模式为通过USB接口输出的情况下，所述接收用户根据所述提示信息执行的至少一个用户操作，依次响应所述至少一个用户操作中的每个用户操作，包括：
响应于通过所述USB接口接入所述第二电子设备的用户操作，监听所述USB接口；
若通过所述USB接口监听到所述第二电子设备的数据传输通道建立请求，则与所述第二电子设备建立所述数据传输通道；
在所述数据传输通道建立成功的情况下，抓取所述异常日志；
通过所述数据传输通道向所述第二电子设备传输所述异常日志。
6.如权利要求4所述的方法，其特征在于，在所述第一转储模式标志指示异常日志获取模式为从内存中获取的情况下，所述接收用户根据所述提示信息执行的至少一个用户操作，依次响应所述至少一个用户操作中的每个用户操作之前，包括：
抓取所述异常日志；
将所述异常日志存储于所述指定存储路径下；
所述接收用户根据所述提示信息执行的至少一个用户操作，依次响应所述至少一个用户操作中的每个用户操作，包括：
响应于关闭所述提示信息的用户操作，重启所述第一电子设备。
7.如权利要求2-6中任一项所述的方法，其特征在于，所述在系统崩溃后重启的情况下，显示提示信息之前，还包括：
在系统启动的情况下，从所述DDR内存中读取启动指示信息，所述启动指示信息用于指示系统启动的触发原因；
在所述启动指示信息指示所述第一电子设备在系统启动前发生崩溃事件的情况下，确定所述第一电子设备是系统崩溃后重启。
8.如权利要求3-7中任一项所述的方法，其特征在于，所述方法还包括：
在完成异常日志抓取操作后，清除所述DDR内存中存储的所述第一崩溃事件处理标志和所述第一转储模式标志。
9.如权利要求3所述的方法，其特征在于，所述方法还包括：
在系统崩溃后重启的情况下，在所述第一崩溃事件处理标志为第二数值的情况下，加载所述第一电子设备的内核，所述第二数值用于指示在发生崩溃事件的情况下所要执行的操作为启动操作。
10.如权利要求3-7、9中任一项所述的方法，其特征在于，所述方法还包括：
接收在线修改指令，所述在线修改指令中携带第二崩溃事件处理标志和第二转储模式标志；
将所述目标XML文件中的所述第一崩溃事件处理标志修改为所述第二崩溃事件处理标志，以及将所述目标XML文件中的所述第一转储模式标志修改为所述第二转储模式标志。
11.一种电子设备，其特征在于，所述电子设备的结构中包括处理器和存储器；
所述电子设备用于存储支持所述电子设备执行如权利要求1-10任意一项所提供的数据处理的方法的程序，以及存储用于实现如权利要求1-10任意一项所述的数据处理的方法所涉及的数据；所述处理器被配置为用于执行所述存储器中存储的程序。
12.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质中存储有指令，当其在计算机上运行时，使得计算机执行如权利要求1-10任意一项所述的数据处理的方法。
CN202211211714.8A 2022-09-30 2022-09-30 数据处理的方法、电子设备及可读存储介质 Active CN116719670B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202211211714.8A CN116719670B (zh) 2022-09-30 2022-09-30 数据处理的方法、电子设备及可读存储介质

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202211211714.8A CN116719670B (zh) 2022-09-30 2022-09-30 数据处理的方法、电子设备及可读存储介质

Publications (2)

Publication Number Publication Date
CN116719670A true CN116719670A (zh) 2023-09-08
CN116719670B CN116719670B (zh) 2024-04-12

Family

ID=87863726

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202211211714.8A Active CN116719670B (zh) 2022-09-30 2022-09-30 数据处理的方法、电子设备及可读存储介质

Country Status (1)

Country Link
CN (1) CN116719670B (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN117476086A (zh) * 2023-12-26 2024-01-30 成都佰维存储科技有限公司 存储器性能测试方法、装置、可读存储介质及电子设备

Citations (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105204909A (zh) * 2015-10-12 2015-12-30 Tcl集团股份有限公司 一种基于移动终端的强相关apk升级方法及系统
CN106055350A (zh) * 2016-05-19 2016-10-26 北京金山安全软件有限公司 配置文件的升级处理方法以及装置
US20180322016A1 (en) * 2017-05-05 2018-11-08 Dell Products L.P. System and method to capture stored data following system crash
US20190294490A1 (en) * 2016-10-25 2019-09-26 Huawei Technologies Co., Ltd. Recovery Method for Terminal Device Startup Failure and Terminal Device
CN110659041A (zh) * 2019-08-22 2020-01-07 深圳市星汉智能科技有限公司 一种基于Android平台的应用升级方法及系统
CN111221682A (zh) * 2020-01-07 2020-06-02 四川长虹电器股份有限公司 一种存储系统镜像的方法
CN114443081A (zh) * 2020-11-04 2022-05-06 华为技术有限公司 终端升级的方法及终端
CN114443083A (zh) * 2021-07-09 2022-05-06 荣耀终端有限公司 系统升级方法、装置、电子设备及存储介质
WO2022111665A1 (zh) * 2020-11-30 2022-06-02 花瓣云科技有限公司 应用的管理方法、装置、设备及存储介质
WO2022135215A1 (zh) * 2020-12-23 2022-06-30 华为技术有限公司 一种开机异常的修复方法及装置
CN114840242A (zh) * 2022-04-14 2022-08-02 深圳矽递科技股份有限公司 一种电子设备的系统升级方法、装置及可读存储介质
CN115017534A (zh) * 2021-11-05 2022-09-06 荣耀终端有限公司 文件处理权限控制方法、装置及存储介质

Patent Citations (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105204909A (zh) * 2015-10-12 2015-12-30 Tcl集团股份有限公司 一种基于移动终端的强相关apk升级方法及系统
CN106055350A (zh) * 2016-05-19 2016-10-26 北京金山安全软件有限公司 配置文件的升级处理方法以及装置
US20190294490A1 (en) * 2016-10-25 2019-09-26 Huawei Technologies Co., Ltd. Recovery Method for Terminal Device Startup Failure and Terminal Device
US20180322016A1 (en) * 2017-05-05 2018-11-08 Dell Products L.P. System and method to capture stored data following system crash
CN110659041A (zh) * 2019-08-22 2020-01-07 深圳市星汉智能科技有限公司 一种基于Android平台的应用升级方法及系统
CN111221682A (zh) * 2020-01-07 2020-06-02 四川长虹电器股份有限公司 一种存储系统镜像的方法
CN114443081A (zh) * 2020-11-04 2022-05-06 华为技术有限公司 终端升级的方法及终端
WO2022111665A1 (zh) * 2020-11-30 2022-06-02 花瓣云科技有限公司 应用的管理方法、装置、设备及存储介质
CN114579389A (zh) * 2020-11-30 2022-06-03 花瓣云科技有限公司 应用的管理方法、装置、设备及存储介质
WO2022135215A1 (zh) * 2020-12-23 2022-06-30 华为技术有限公司 一种开机异常的修复方法及装置
CN114443083A (zh) * 2021-07-09 2022-05-06 荣耀终端有限公司 系统升级方法、装置、电子设备及存储介质
CN115017534A (zh) * 2021-11-05 2022-09-06 荣耀终端有限公司 文件处理权限控制方法、装置及存储介质
CN114840242A (zh) * 2022-04-14 2022-08-02 深圳矽递科技股份有限公司 一种电子设备的系统升级方法、装置及可读存储介质

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN117476086A (zh) * 2023-12-26 2024-01-30 成都佰维存储科技有限公司 存储器性能测试方法、装置、可读存储介质及电子设备

Also Published As

Publication number Publication date
CN116719670B (zh) 2024-04-12

Similar Documents

Publication Publication Date Title
WO2020147462A1 (zh) 应用异常恢复
US11853820B2 (en) Cross-process communication method, apparatus, and device
CN106293507B (zh) 具有外部存储器的电子设备及操作电子设备的方法
CN112162795B (zh) 一种插件启动方法、装置、计算机设备和存储介质
US11321080B2 (en) Patch package generation method and device
CN106484719B (zh) 一种扩展手机存储的方法及终端
CN110865837A (zh) 一种进行系统升级的方法和终端
CN116719670B (zh) 数据处理的方法、电子设备及可读存储介质
CN115328563B (zh) 系统启动方法及电子设备
CN114706633B (zh) 预加载方法、电子设备及存储介质
WO2019137280A1 (zh) 终端异常的修复方法、装置、移动终端及存储介质
CN112394906A (zh) 一种应用切换运行的方法及设备
US20170199733A1 (en) Method for terminal to update operating system, terminal and system
CN116700768B (zh) 一种应用的处理方法及相关装置
CN116643778A (zh) 一种应用程序优化方法及电子设备
CN108268274B (zh) 应用管理方法、装置、存储介质及电子设备
KR102516940B1 (ko) 부팅을 수행하는 전자 장치와 이의 동작 방법
US20220334820A1 (en) System and method for intermediate software upgrades for information handling systems
KR20190098516A (ko) 어플리케이션과 관련된 데이터를 관리하기 위한 방법 및 그 전자 장치
CN108279937B (zh) 参数的调用方法、装置、存储介质及电子设备
CN117290164B (zh) 重启时的信息记录方法、电子设备及可读存储介质
KR101420026B1 (ko) 부팅 프로세스 중에 파일들을 로딩하기 위한 방법, 장치 및 컴퓨터 판독가능 저장 매체
CN115562697B (zh) 升级方法、设备及存储介质
CN117130627B (zh) 配件升级方法及电子设备
KR20200012536A (ko) 전자 장치 및 그의 동작 방법

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant