WO2021097683A1

WO2021097683A1 - Android system starting method and apparatus, device, and storage medium

Info

Publication number: WO2021097683A1
Application number: PCT/CN2019/119522
Authority: WO
Inventors: 王群峰; 王孙黎; 司磊
Original assignee: 深圳市大疆创新科技有限公司
Priority date: 2019-11-19
Filing date: 2019-11-19
Publication date: 2021-05-27
Also published as: CN112313620A

Abstract

An Android system starting method and apparatus, a terminal device, a photographing apparatus, and a storage medium. The method comprises: after starting of a kernel layer of an Android system is completed, parsing and loading a first init service of a first init script log, the first init service comprising a java starting service (S101); after the java starting service is loaded, loading a first java service (S102); and after the loading of the first java service is completed, starting a desktop launcher to complete starting of the Android system, a second init service and a second java service being loaded after the starting of the Android system is completed (S103).

Description

Method, device, equipment and storage medium for starting Android system

Technical field

This application relates to the technical field of operating systems, and in particular to a method, device, terminal device, photographing device, and storage medium for starting an Android system.

Background technique

The Android system has the problem of slow booting. This problem is a common problem in devices using the Android system.

There are already some similar technologies that can speed up the startup speed of the Android system. For example: delayed loading application (APP, Application) technology (that is, the delayed start of APP that does not need to be started), asynchronous loading framework (that is, asynchronous loading of modules that are not dependent on each other in the framework layer) technology.

However, the delayed loading APP technology is not suitable for device software systems with only a few APPs (such as camera software systems), and the system startup optimization cannot be performed from a lower level; the asynchronous loading framework technology is limited by the number of CPUs.

Summary of the invention

Based on this, this application provides a method, a device, a terminal device, a photographing device, and a storage medium for starting the Android system.

In the first aspect, this application provides a method for starting an Android system. The init service in the Android system includes a first init service and a second init service; the java service of the Android system includes a first java service and a second init service. Java service, the method includes:

After the kernel layer of the Android system is started up, parse and load the first init service recorded by the first init script, where the first init service includes a java startup service;

After loading the java startup service, load the first java service;

After the loading of the first java service is completed, the desktop launcher is started to complete the startup of the Android system; wherein the second init service and the second java service can be loaded after the Android system is started.

In a second aspect, this application provides a device for starting an Android system. The init service in the Android system includes a first init service and a second init service; the java service of the Android system includes a first java service and a second init service. java service, the device includes: a memory and a processor;

The memory is used to store a computer program;

The processor is used to execute the computer program and when executing the computer program, implement the following steps:

After loading the java startup service, load the first java service;

In a third aspect, this application provides a terminal device, the operating system of the terminal device includes an Android system, the init service in the Android system includes a first init service and a second init service; the java service of the Android system Including a first java service and a second java service, the terminal device includes a processor, and a memory connected to the processor, an input/output device, and a communication circuit;

The memory is used to store a computer program;

After loading the java startup service, load the first java service;

In a fourth aspect, the present application provides a photographing device, the operating system of the photographing device includes an Android system, the init service in the Android system includes a first init service and a second init service; the java service of the Android system Including a first java service and a second java service, the photographing device includes a processor and a memory;

The memory is used to store a computer program;

After loading the java startup service, load the first java service;

In a fifth aspect, this application provides a computer-readable storage medium that stores a computer program that, when executed by a processor, causes the processor to start the Android system as described above Methods.

The embodiments of the application provide a method, device, terminal device, photographing device, and storage medium for starting an Android system. The init service in the Android system includes a first init service and a second init service; the java service of the Android system includes the first init service. The java service and the second java service. After the kernel layer of the Android system is started, the first init service recorded by the first init script is parsed and loaded, where the first init service includes the java startup service; after the java startup service is loaded, Load the first java service; after loading the first java service, start the desktop launcher to complete the startup of the Android system; wherein, the second init service and the second java service can be loaded after the Android system is started. Compared with the normal startup process of the Android system, when the Android system in the embodiment of the present application starts, only the first init service in the init service and the first java service in the java service are loaded, but not all the init services and java are loaded. Service, start the desktop launcher after loading the first java service to complete the startup of the Android system. In this way, the startup speed of the Android system can be greatly accelerated without increasing the process/thread switching overhead during the system startup phase. ; Because another part of the second init service and the second java service can be loaded after the Android system is started, in this way, the integrity of the Android system can be guaranteed; the startup method of the embodiment of this application is from the lower layer (framework layer) (And local library/runtime) to optimize the startup of the system. The startup process has nothing to do with the number of APPs in the device software system. Especially for a customized Android system (such as a camera) that contains only a small number of APPs, this application can achieve more prominent Startup optimization effect; the startup process has nothing to do with the number of CPUs, so it is not limited by the number of APPs, nor is it limited by the number of CPUs.

It should be understood that the above general description and the following detailed description are only exemplary and explanatory, and cannot limit the application.

Description of the drawings

In order to explain the technical solutions of the embodiments of the present application more clearly, the following will briefly introduce the drawings used in the description of the embodiments. Obviously, the drawings in the following description are some embodiments of the present application. Ordinary technicians can obtain other drawings based on these drawings without creative work.

Figure 1 is a schematic diagram of an architecture-division method of the Android system;

Figure 2 is a schematic diagram of the normal startup process of the Android system;

Figure 3 is a schematic diagram of the scattered loading of init scripts in the normal startup process of the Android system;

FIG. 4 is a schematic flowchart of an embodiment of a method for starting an Android system according to the present application;

FIG. 5 is a schematic flowchart of another embodiment of the method for starting the Android system according to the present application;

FIG. 6 is a schematic flowchart of another embodiment of the method for starting the Android system according to the present application;

FIG. 7 is a schematic flowchart of another embodiment of the method for starting the Android system according to the present application;

FIG. 8 is a schematic flowchart of another embodiment of the method for starting the Android system according to the present application;

FIG. 9 is a schematic flowchart of another embodiment of the method for starting the Android system according to the present application;

FIG. 10 is a schematic structural diagram of an embodiment of a device for starting an Android system according to the present application.

Detailed ways

The technical solutions in the embodiments of the present application will be described clearly and completely in conjunction with the accompanying drawings in the embodiments of the present application. Obviously, the described embodiments are part of the embodiments of the present application, rather than all of them. Based on the embodiments in this application, all other embodiments obtained by those of ordinary skill in the art without creative work shall fall within the protection scope of this application.

The flowchart shown in the drawings is only an example, and does not necessarily include all contents and operations/steps, nor does it have to be executed in the described order. For example, some operations/steps can also be decomposed, combined or partially combined, so the actual execution order may be changed according to actual conditions.

Slow booting of Android system is a common problem of devices using Android system. The methods that can speed up the startup speed of the Android system now include: delayed loading APP technology and asynchronous loading framework technology. However, the delayed-loading APP technology is not suitable for device software systems with only a small number of APPs, and the system startup optimization cannot be performed from the lower level; the asynchronous loading framework technology is limited by the number of CPUs.

In order to better explain and understand the related content of the embodiments of the present application, first introduce related content such as the architecture of the Android system and the normal startup process of the Android system.

Refer to FIG. 1, which is a schematic diagram of an architecture-division method of the Android system. In the architecture model of the division method of this embodiment, the Android system is divided into 5 levels from top to bottom: application layer 1, framework layer 2, local library/runtime 3, hardware abstraction layer 4, and kernel layer 5. Framework layer 2 and native library/runtime 3 are the core parts of the Android system, and every Android application developer develops applications on this basis.

Application layer 1 refers to various applications APP installed and running on the Android system, which is the part of the Android system directly facing users. It includes not only system applications such as calls, text messages, contacts, etc. (pre-installed on Android devices along with the Android system), but also other third-party applications that are subsequently installed on the device.

Framework layer 2, the application framework layer, is the core part of the Android system. It mainly consists of two parts: android SDK and Android system's Java service. The two interact with each other through the Binder communication mechanism. Android SDK is used to provide various APIs (Application Programming Interface) that may be used to build applications. Some core applications that come with Android and applications built by developers are completed using these APIs to support applications The operation of the program in layer 1; the Java service of the Android system refers to the relatively complete system service that the framework layer 2 of the Android system can provide to the application layer 1. Generally, the Java service of the Android system includes the system service (usually relatively complete) that the framework layer 2 of the Android system can provide to the application layer 1 officially provided by the Android system. Android Java services include: Activity Manager, Window Manager, Content Providers, View System, Notification Manager, Installation Package Management Service (Package Manager), Telephony Manager, Resource Manager, Location Manager, Power Management Service, Call Management Service, Wifi Management Service, Account Management Service, Status Bar Notification Management Service , Hardware services, etc. They have their own functions, for example: Activity Manager is used to manage the life cycle of the program, jump back and other functions; such as the resources required to open the application, and release the resources required when the application is exited. Window Manager is mainly used to manage all open window programs. Content Providers allow applications to access another application's data (such as a contact database) or share their data. The View System can be used to build applications, including list view, grid view, text box, button, graphic drawing, etc., as well as embeddable web browsers.

The local library/runtime 3 includes the initial init service of the Android system, the basic runtime library required for system operation, and the ART virtual machine required for running Java programs. The init service of the Android system refers to the service recorded in the relatively complete init script (that is, the *.rc configuration file) that the Android system can provide. Generally, the init service of the Android system includes the services recorded in the init script (that is, the *.rc configuration file, which is usually relatively complete) that the official Android system can provide. The init service of Android system includes: core service (including: ueventd, logd, healthd, adbd (disabled), lmkd (LowMemoryKiller), servicemanager, vold, debuggerd, surfaceflinger, bootanim (disabled), etc.), main service, zygote service, etc.

The hardware abstraction layer 4 mainly includes some user-level encapsulation of drivers, and provides a hardware abstraction layer interface that conforms to the Android specification. It is also considered to be the same layer as "local library/runtime 3" in some materials.

Kernel layer 5 contains a Linux kernel, which provides basic process management, memory management, process scheduling and other operating system functions.

In the Android system, the user interacts with the APP through touch screen, buttons, voice, etc., while the APP accesses the java service or init service through the android SDK of the framework layer 2, and the java service or init service continues through Binder or Socket or other methods Interact with the lower layer of the device, so as to realize the purpose of APP accessing system resources.

Refer to Figure 2 in combination, which is a schematic diagram of the normal startup process of the Android system. As shown in the figure, after the kernel layer of the Android system is started, the startup process of the Android system mainly involves three levels, which are in order of startup: local library/runtime, framework layer, and application layer.

In the local library/runtime, the first process init is started first. It parses various init scripts (*.rc files) in the system and loads the init services recorded in these *.rc files.

In the middle and late stages of the init process startup phase, an init service called incubation (zygote) will be started, which will start an executable program called app_process64. After app_process64 starts running, it will load the ART virtual machine and enter the java world. From then on, the system enters the framework layer and continues to boot.

In the framework layer, app_process64 renames its own process to a zygote process, copies a copy of its own process, and executes the initialization process of the system server (SystemServer) process. The zygote process itself waits for other processes to connect to determine whether to copy a new child process to execute the APP startup process. The SystemServer process is the process where many java services run in the Android system. Many java services will be started in SystemServer, such as network service, telephone service, Bluetooth service, etc. These many java services and some init services jointly build the rich functions of the Android system.

After the SystemServer process loads the java service, it will start the first APP of the application layer in the system, that is, the desktop launcher launcher. After the launcher starts the first activity, the entire Android system is started.

Refer to Figure 3 in combination, which is a schematic diagram of the scattered loading of init scripts in the normal startup process of the Android system. The init process of the Android system is a very special process: it is the first process started in the system, and it is also the parent process of many system processes. As shown in the figure, during the startup phase of the init process, it will read multiple *.rc files such as /init.rc, /system/etc/init/*.rc, /vendor/etc/init/*.rc, and Load the init service recorded in these *.rc files.

Compared with the normal startup process of the Android system, when the Android system in the embodiment of the present application starts, only the first init service in the init service and the first java service in the java service are loaded, but not all the init services and java are loaded. Service, start the desktop launcher after loading the first java service to complete the startup of the Android system. In this way, the startup speed of the Android system can be greatly accelerated without increasing the process/thread switching overhead during the system startup phase. ; Because another part of the second init service and the second java service can be loaded after the Android system is started, in this way, the integrity of the Android system can be guaranteed; the startup method of the embodiment of this application is from the lower layer (framework layer) (And local library/runtime) to optimize the startup of the system. The startup process has nothing to do with the number of APPs in the device software system. Especially for a customized Android system (such as a camera) that contains only a small number of APPs, this application can achieve more prominent Start-up optimization effect; its startup process has nothing to do with the number of CPUs, so it is not limited by the number of APPs, nor is it limited by the number of CPUs.

Hereinafter, some embodiments of the present application will be described in detail with reference to the accompanying drawings. In the case of no conflict, the following embodiments and features in the embodiments can be combined with each other.

Refer to FIG. 4, which is a schematic flowchart of an embodiment of the method for starting the Android system of the present application. In this embodiment, the init service in the Android system includes a first init service and a second init service; the java service of the Android system includes For the first java service and the second java service, during the startup process of the Android system, only the first init service in the init service and the first java service in the java service are loaded.

The method includes:

Step S101: After the kernel layer of the Android system is started up, the first init service recorded by the first init script is parsed and loaded, where the first init service includes a java startup service.

Step S102: After loading java to start the service, load the first java service.

Step S103: After the loading of the first java service is completed, the desktop launcher is started to complete the startup of the Android system; wherein the second init service and the second java service can be loaded after the Android system is started.

The embodiment of this application divides the init service in the Android system into two parts. A part of the init service (ie, the first init service) is loaded together with the Android system, and the corresponding script is the first init script; the other part of the init service (ie, the first init service) 2. The init service) is not loaded along with the Android system, and can be loaded after the Android system is started. The embodiment of the application divides the java service in the Android system into two parts, one part of the java service (i.e. the first java service) is loaded together with the Android system, and the other part of the java service (i.e. the second java service) is not loaded together with the Android system. It can be loaded after the Android system is started. Since the java startup service belongs to the init service, the first java service loaded along with the Android system can be loaded only after the java startup service is started. Therefore, the first init service includes the java startup service. The java startup service is usually an init service called zygote.

Among them, there may be many ways in which the second init service and the second java service can be loaded after the Android system is started. For example, after the Android system is started, it can automatically trigger the loading of the second init service and the second java service in idle time. Or, after the Android system is started, when the system detects that the new application is started, it triggers the second init service and the second java service that may need to be used to load the new application. Or, after the Android system is started, the specified second init service and the second java service are triggered to load according to the instructions from the application program, etc.; the instructions of the application program can be implemented in the following ways: develop an application program specifically, the application The program may include buttons to trigger each of the second init service and the second java service, the number of buttons is equal to the total number of the second init service and the second java service, and each second init service or second java service corresponds to a button, When the user clicks the button, the corresponding second init service or second java service is triggered to load; or, the application may include a check box, and each check box corresponds to a second init service or second java service, and the user Multiple second init services and second java services can be selected at one time, so that multiple second init services and second java services can be loaded at one time, and so on.

The basis for dividing the init service into two parts and the basis for dividing the java service into two parts are determined by the developer, and the developer usually decides according to the requirements and functions of the specific application. Generally, the init service and java service that are not needed by the developed application can be divided into the second init service and the second java service; and the init service and the java service that the developed application need to use are divided into the first init. Service and the first java service; for example, for a device that does not have a camera function, its Android system can divide the camera-related services into services that are not loaded with the Android system (ie, the second java service); for a camera that only takes pictures The Android system of the device can classify the phone-related services into services that are not loaded along with the Android system (ie, the second java service). For another example, the init service and java service that all applications need to use can be divided into the first init service and the first java service, and the init service and java service that are only used by some and specific applications can be divided into the first init service and the first java service. Divided into the second init service and the second java service; and so on. For example, activity management services, window management services, resource management services, power management services, etc. can be used by all applications. These java services are divided into the first java service loaded with the Android system, while the phone management service and view The system is only used by some and specific applications, and these java services are divided into second java services that are not loaded along with the Android system.

Among them, there are many implementation methods for parsing and loading the first init service recorded by the first init script after the kernel layer of the Android system in step S101 is started, and it usually needs to be prepared in advance during the compilation phase. Generally, after the kernel layer of the Android system is started, the init process is the first to start, and the init process is responsible for parsing and loading the first init service recorded by the first init script.

For example: in the compilation stage of the android system source code, the developer can mark the second init script (the script corresponding to the second init service that is not loaded with the Android system) and mark it as LOCAL_LAZY_INIT_RC. The init service recorded by the marked script is The second init service, the init service recorded by the unmarked first init script (the script corresponding to the first init service loaded with the Android system) is the first init service, so that the second init script and the first init are combined at the machine level. The scripts are distinguished. After the kernel layer of the Android system is started, the init process needs to be identified and distinguished, and only the first init service recorded by the first init script is parsed and loaded.

Since it takes time to identify and distinguish the init process, in one embodiment, in order to further speed up the startup time, in step S101, parsing and loading the first init service recorded by the first ini script may include: automatically parsing and loading the default path The first init service recorded by the first init script. That is, only the files corresponding to the first init script are stored in the default path that the init process can automatically parse and load, for example: store the *.rc file corresponding to the first init script in /init.rc, /system/etc/ At least one of the default paths in init/*.rc, /vendor/etc/init/*.rc, etc.

The file corresponding to the second ini script can be stored in a space other than the default path, or can be placed in a location where the second init service recorded by the second ini script can be parsed and loaded separately. The second init service recorded by the second ini script stored in other places can be parsed and loaded through the init process, or parsed and loaded in other ways, for example, directly called and executed temporarily by the application.

The second init service recorded by the second ini script is parsed and loaded in other ways, which is usually difficult to ensure the security of the system. The second init service recorded by the second ini script can be parsed and loaded through the init process to ensure the security of the system. Therefore, In one embodiment, the file corresponding to the second init script is placed in a non-default path that can be parsed and loaded by the init process.

For example: modify the source code of the compilation system, for the second init script with the aforementioned mark, you can package its corresponding *.rc file to the /[system|vendor]/etc/lazy_init/ directory, which can avoid the system startup process on the one hand The init process automatically loads them. On the other hand, because they are stored in the system directory, you can specify the loading path to the init process when you need to load them. The init process can also parse and load the second init recorded by these second ini scripts. service.

Among them, in step S102, there are many implementation ways of loading the first java service, which usually need to be prepared in advance during the compilation phase.

For example: transfer the second java service to another location; or, do not transfer the second java service, mark the second java service that does not follow the startup of the Android system to show the difference from the first java service, and load the first java service The second java service is not loaded; or, a special java service is added, and the java service specifically manages the second java service that does not follow the startup and loading of the Android system; and so on.

Under normal circumstances, java starts the service, that is, after the zygote service is loaded, it will start an executable program called app_process64. After app_process64 starts running, it will load the ART virtual machine and enter the java world. app_process64 renames its own process to a zygote process, copies its own process, and executes the initialization process of the SystemServer process. The SystemServer process is the process where many java services run in the Android system.

It should be noted that the number of second init services in this embodiment of the application can be zero or the number of second java services can be zero, the sum of the number of second init services and the number of second java services is greater than zero, and the first The sum of the number of init services and the number of first java services is less than the sum of the number of init services and the number of java services in the Android system.

The init service in the Android system in the embodiment of the application includes a first init service and a second init service; the java service of the Android system includes a first java service and a second java service. After the kernel layer of the Android system is started, it is analyzed and combined. Load the first init service recorded by the first init script, where the first init service includes the java startup service; after the java startup service is loaded, the first java service is loaded; after the first java service is loaded, the desktop launcher is started, thereby The startup of the Android system is completed; wherein the second init service and the second java service can be loaded after the startup of the Android system is completed. Compared with the normal startup process of the Android system, when the Android system in the embodiment of the present application starts, only the first init service in the init service and the first java service in the java service are loaded, but not all the init services and java are loaded. Service, start the desktop launcher after loading the first java service to complete the startup of the Android system. In this way, the startup speed of the Android system can be greatly accelerated without increasing the process/thread switching overhead during the system startup phase. ; Because another part of the second init service and the second java service can be loaded after the Android system is started, in this way, the integrity of the Android system can be guaranteed; the startup method of the embodiment of this application is from the lower layer (framework layer) (And local library/runtime) to optimize the startup of the system. The startup process has nothing to do with the number of APPs in the device software system. Especially for a customized Android system (such as a camera) that contains only a small number of APPs, this application can achieve more prominent Startup optimization effect; the startup process has nothing to do with the number of CPUs, so it is not limited by the number of APPs, nor is it limited by the number of CPUs.

In order to ensure the security of the second init service and the second java service in the Android system that are loaded after the Android system is started, to simplify the development steps to the greatest extent and to ensure the integrity of the Android system to the greatest extent, in one embodiment , Add a special java service in the compilation stage, the special java service is loaded following the startup of the Android system, and provides special services for the subsequent loading of the second init service and the second java service. The specific content is explained as follows.

This specialized java service is called a lazy loading service manager. In step S102, loading the first java service may specifically include: enabling the SystemServer process to load the first java service. The first java service includes the lazy loading service manager and other first java services. The java service, the second init service and the second java service can be loaded through the lazy loading service manager after the Android system is started.

Since the second init service and the second java service can be loaded through the lazy loading service manager after the Android system is started, in this way, on the one hand, it can ensure the security of the Android system, simplify the development steps, and ensure the Android system's security. Integrity provides support. On the other hand, it can also provide support for improving the loading speed of the second init service and the second java service when the second init service and the second java service need to be loaded.

Referring to Fig. 5, in a specific application, in step S102, enabling the SystemServer process to load the first java service may further include: sub-step S1021 and sub-step S1022.

Sub-step S1021: Make the SystemServer process load the lazy loading service manager.

Sub-step S1022: mark the java service that needs to be lazy loaded by the lazy loading service manager to obtain the marked second java service, mark the init service that needs to be lazy loaded, and obtain the marked second init service.

In this embodiment, the second java service includes a java service that performs lazy loading, and the second init service includes an init service that requires lazy loading. When the SystemServer process loads the first java service, it loads the newly added lazy loading service manager at the same time. After the lazy loading service manager is loaded, the lazy loading service manager will mark the java services that need to be lazy loaded and get the mark For the second java service, mark the init service that needs lazy loading to obtain the marked second init service. In this way, when the user needs to load, the second init service and the second java service required by the user can be loaded in time through the lazy loading service manager.

The following two situations illustrate the specific details of the user request to load the second java service and the second init service after the Android system has been started up.

Referring to FIG. 6, in an embodiment, the method further includes: step S201 and step S202.

Step S201: After the Android system is started, the first request for loading the specified java service is received through the lazy loading service manager.

Among them, the lazy loading service manager can communicate with the application program, and can communicate with the application program directly through the software development kit provided by the Android system. In this way, the development complexity can be reduced. In an application, the first request comes from the application.

Step S202: According to the first request, load the specified java service.

Specifically, the second java service marked above includes the correspondence between the lazy loading java service name and the loading code corresponding to the lazy loading java service name. In this way, when the first request is received, the specified java service can be quickly responded to and loaded quickly.

Referring to FIG. 7, at this time, step S202 may specifically include: sub-step S2021 and sub-step S2022.

Sub-step S2021: According to the name of the specified java service carried in the first request, determine the corresponding lazy-loaded java service name and the loading code corresponding to the lazy-loaded java service name.

Sub-step S2022: Load the loading code corresponding to the lazy loading java service name.

In this embodiment, the name of the specified java service carried in the first request is usually user-oriented, concise and intuitive, and the lazy loading java service name is usually the name of the java service in the Android system that the machine can recognize. According to the established relationship between the name of the specified java service and the name of the lazy-loaded java service, and then according to the correspondence between the name of the lazy-loaded java service and the loading code corresponding to the lazy-loaded java service name, the specified java service can be quickly loaded .

In another embodiment, the lazy loading service manager can communicate with the init process, in this way, it provides support for the init process to load the second init service.

In an application, the lazy loading service manager can communicate with the init process through the ctrl.loadrc attribute interface of the init process, and the init process can load the second init initialization script among the parameters carried by the attributes of the ctrl.loadrc attribute interface. In this embodiment, a new attribute interface ctrl.loadrc is added to the init process in advance, and the lazy loading service manager sends the relevant parameters requesting to load the specified second init service to the attribute interface ctrl.loadrc, and the attribute interface ctrl.loadrc combines these The relevant parameters are attached to the properties, and the init process can load the corresponding second init service according to the parameters carried by the properties of the ctrl.loadrc property interface.

Wherein, referring to FIG. 8, the method further includes: step S301 and step S302.

Step S301: After the Android system is started, the second request for loading the specified init service is received through the lazy loading service manager.

Among them, the lazy loading service manager can communicate with the application program, and can communicate with the application program directly through the software development kit provided by the Android system. In this way, the development complexity can be reduced. In an application, the second request comes from the application.

Step S302: According to the second request, the init process parses and loads the specified init service recorded by the corresponding second init script through the lazy loading service manager.

Specifically, the second init service marked above includes the corresponding relationship between the lazy loading init service name, the lazy loading init script corresponding to the lazy loading init service name, and the lazy loading path corresponding to the lazy loading init script; in this way, When receiving the second request, it can quickly respond to quickly load the specified init service.

Referring to FIG. 9, at this time, step S302 may specifically include: sub-step S3021 and sub-step S3022.

Sub-step S3021: According to the name of the designated init service carried in the second request, determine the corresponding lazy loading init service name, the lazy loading init script corresponding to the lazy loading init service name, and the lazy loading path corresponding to the lazy loading init script.

Sub-step S3022: using the lazy loading service manager to make the init process parse and load the lazy loading init service recorded by the lazy loading init script according to the lazy loading path.

In this embodiment, the name of the specified init service carried in the second request is usually user-oriented, concise and intuitive, and the lazy loading init service name is usually the name of the init service in the Android system that can be recognized by the machine. According to the established relationship between the name of the specified init service and the name of the lazy-loaded init service, according to the name of the lazy-loaded init service, the lazy-loaded init script corresponding to the lazy-loaded init service name, and the lazy-loaded path corresponding to the lazy-loaded init script The corresponding relationship between the two, you can quickly obtain the lazy loading path of the specified init service name, and send the lazy loading path (parameter) of the specified init service name to the attribute interface ctrl.loadrc, and the attribute interface ctrl.loadrc will specify the init service The lazy loading path of the name is carried as an attribute, and the init process can quickly resolve and load the lazy loading init service recorded by the corresponding lazy loading init script according to the lazy loading path.

In a specific practical application, a faster system startup speed can be obtained without compromising the integrity of the android system, specifically: on the reference development board hikey960, based on the A53 1.8GHz×3 processor configuration, through the network After the service and Wifi service (network/wifi) related framework layer services are delayed to start, the start time is reduced from 4.6s to 4.4s.

Refer to FIG. 10, which is a schematic structural diagram of an embodiment of the device for starting the Android system of the present application. It should be noted that the device of this embodiment can implement the above method for starting the Android system. For a detailed description of related content, please refer to the above-mentioned Android system. The method of system startup will not be repeated here.

The init service in the Android system includes the first init service and the second init service; the java service of the Android system includes the first java service and the second java service. The device 10 started by the Android system includes: a memory 11 and a processor 12; and a memory 11 And the processor 12 is connected through a bus 13.

Among them, the processor 12 may be a micro control unit, a central processing unit, or a digital signal processor, and so on.

Among them, the memory 11 may be a Flash chip, a read-only memory, a magnetic disk, an optical disk, a U disk or a mobile hard disk, etc.

The memory 11 is used to store a computer program; the processor 12 is used to execute the computer program and when the computer program is executed, the following steps are implemented:

After the kernel layer of the Android system is started, the first init service recorded by the first init script is parsed and loaded, where the first init service includes the java startup service; after the java startup service is loaded, the first java service is loaded; After the first java service is completed, the desktop launcher is started to complete the startup of the Android system; wherein, the second init service and the second java service can be loaded after the Android system is started.

Wherein, when the processor executes the computer program, it implements the following steps: automatically parse and load the first init service recorded by the first init script in the default path.

Wherein, the file corresponding to the second init script of the second init service is placed in the non-default path.

Among them, the file corresponding to the second init script is placed in a non-default path that can be parsed and loaded by the init process.

Wherein, when the processor executes the computer program, the following steps are implemented: the SystemServer process loads the first java service, the first java service includes the lazy loading service manager and other first java services, the second init service and the second java service can After the Android system is started, it is loaded through the lazy loading service manager.

Among them, when the processor executes the computer program, the following steps are implemented: make the SystemServer process load the lazy-loading service manager; mark the java services that need to be lazy-loaded through the lazy-loading service manager, and get the marked second java service. The init service that needs to be lazy loaded is marked, and the marked second init service is obtained.

Wherein, when the processor executes the computer program, the following steps are implemented: after the Android system is started, it receives a first request for loading a specified java service through the lazy loading service manager; according to the first request, loads the specified java service.

Wherein, the marked second java service includes the corresponding relationship between the lazy loading java service name and the loading code corresponding to the lazy loading java service name; when the processor executes the computer program, the following steps are implemented: according to the specification carried in the first request For the name of the java service, determine the corresponding lazy-loaded java service name and the load code corresponding to the lazy-loaded java service name; load the load code corresponding to the lazy-loaded java service name.

Among them, the lazy loading service manager can communicate with the init process.

Wherein, when the processor executes the computer program, the following steps are implemented: after the Android system is started, it receives a second request to load the specified init service through the lazy loading service manager; according to the second request, the init process is made through the lazy loading service manager Parse and load the specified init service recorded by the corresponding second init script.

Wherein, the marked second init service includes the correspondence between the lazy loading init service name, the lazy loading init script corresponding to the lazy loading init service name, and the lazy loading path corresponding to the lazy loading init script; when the processor executes the computer program, The following steps are implemented: according to the name of the specified init service carried in the second request, determine the corresponding lazy loading init service name, the lazy loading init script corresponding to the lazy loading init service name, and the lazy loading path corresponding to the lazy loading init script; The loading service manager enables the init process to parse and load the lazy loading init service recorded by the lazy loading init script according to the lazy loading path.

Among them, the lazy loading service manager can communicate with the init process through the ctrl.loadrc attribute interface of the init process, and the init process can load the second init initialization script among the parameters carried by the attributes of the ctrl.loadrc attribute interface.

Among them, the lazy loading service manager can communicate with the application.

Among them, the first request or the second request comes from the application.

Among them, the lazy loading service manager can communicate with the application through the software development kit.

This application also provides a terminal device, the operating system of the terminal device includes the Android system, and the terminal device can implement the above-mentioned Android system startup method. For detailed descriptions of related content, please refer to the above-mentioned Android system startup method section. Repeat it again. The terminal devices in the embodiments of the present application include, but are not limited to: digital cameras, mobile devices, smart terminals, and so on.

The init service in the Android system includes a first init service and a second init service; the java service of the Android system includes a first java service and a second java service. The terminal device includes a processor, a memory connected to the processor, and an input Output device and communication circuit; the memory is used to store the computer program; the processor is used to execute the computer program and when the computer program is executed, the following steps are implemented:

Among them, the input and output devices include a display screen, a keyboard, a USB interface, a headphone interface, a camera, a speaker, and a receiver.

Among them, the first request or the second request comes from the application.

This application also provides a photographing device, the operating system of the photographing device includes the Android system, and the terminal device can implement the above-mentioned method for starting the Android system. For a detailed description of the relevant content, please refer to the above-mentioned method of starting the Android system. Repeat it again.

The init service in the Android system includes a first init service and a second init service; the java service of the Android system includes a first java service and a second java service. The camera includes a processor and a memory; the memory is used to store computer programs ; The processor is used to execute the computer program and when the computer program is executed, the following steps are implemented:

Among them, the first request or the second request comes from the application.

The present application also provides a computer-readable storage medium that stores a computer program, and when the computer program is executed by a processor, the processor realizes the method for starting the Android system as described above. For a detailed description of the relevant content, please refer to the above section of the Android system startup method, which is not repeated here.

Wherein, the computer-readable storage medium may be an internal storage unit of any of the above-mentioned devices or equipment, such as the hard disk or memory of the device or equipment. The computer-readable storage medium may also be an external storage device of the device or the device, such as a plug-in hard disk, a smart memory card, a secure digital card, a flash memory card, etc. equipped on the device or the device.

It should be understood that the terms used in the specification of this application are only for the purpose of describing specific embodiments and are not intended to limit the application.

It should also be understood that the term "and/or" used in the specification and appended claims of this application refers to any combination of one or more of the associated listed items and all possible combinations, and includes these combinations.

The above are only specific embodiments of this application, but the protection scope of this application is not limited to this. Anyone familiar with the technical field can easily think of various equivalents within the technical scope disclosed in this application. Modifications or replacements, these modifications or replacements shall be covered within the scope of protection of this application. Therefore, the protection scope of this application should be subject to the protection scope of the claims.

Claims

A method for starting an Android system, wherein the init service in the Android system includes a first init service and a second init service; the java service of the Android system includes a first java service and a second java service, so The methods include:

After the kernel layer of the Android system is started up, parse and load the first init service recorded by the first init script, where the first init service includes a java startup service;

After loading the java startup service, load the first java service;

After the loading of the first java service is completed, the desktop launcher is started to complete the startup of the Android system; wherein the second init service and the second java service can be loaded after the Android system is started.
The method according to claim 1, wherein the parsing and loading the first init service recorded by the first ini script comprises:

Automatically parse and load the first init service recorded by the first init script in the default path.
The method according to claim 2, wherein the file corresponding to the second init script of the second init service is placed in a non-default path.
The method according to claim 3, wherein the file corresponding to the second init script is placed in a non-default path that can be parsed and loaded by the init process.
The method according to claim 1, wherein said loading the first java service comprises:

Make the SystemServer process load the first java service. The first java service includes a lazy loading service manager and other first java services. The second init service and the second java service can be completed after the Android system is started. It is loaded by the lazy loading service manager.
The method according to claim 5, wherein said causing the SystemServer process to load the first java service comprises:

Enabling the SystemServer process to load the lazy loading service manager;

Through the lazy loading service manager, the java services that need to be lazy loaded are marked to obtain the marked second java service, and the init services that need to be lazy loaded are marked to obtain the marked second init service.
The method according to claim 6, wherein the method further comprises:

After the Android system is started, receiving a first request for loading a specified java service through the lazy loading service manager;

According to the first request, the specified java service is loaded.
The method according to claim 7, wherein the marked second java service includes a correspondence between a lazy loading java service name and the loading code corresponding to the lazy loading java service name;

The loading the specified java service according to the first request includes:

Determining the corresponding lazy loading java service name and the loading code corresponding to the lazy loading java service name according to the name of the specified java service carried in the first request;

Load the loading code corresponding to the lazy loading java service name.
The method according to claim 6, wherein the lazy loading service manager can communicate with the init process.
The method according to claim 9, wherein the method further comprises:

After the Android system is started, receiving a second request for loading a specified init service through the lazy loading service manager;

According to the second request, the lazy loading service manager enables the init process to parse and load the specified init service recorded by the corresponding second init script.
The method according to claim 10, wherein the marked second init service includes a lazy-loaded init service name, a lazy-loaded init script corresponding to the lazy-loaded init service name, and a lazy-loaded init script corresponding to the lazy-loaded init script Correspondence between paths;

According to the second request, enabling the init process to parse and load the specified init service recorded by the corresponding second init script through the lazy loading service manager includes:

Determine the corresponding lazy loading init service name, the lazy loading init script corresponding to the lazy loading init service name, and the lazy loading path corresponding to the lazy loading init script according to the name of the designated init service carried in the second request;

The lazy loading service manager enables the init process to analyze and load the lazy loading init service recorded by the lazy loading init script according to the lazy loading path.
The method according to any one of claims 9-11, wherein the lazy loading service manager can communicate with the init process through the ctrl.loadrc attribute interface of the init process, and the init process can Load the second init initialization script in the parameters carried by the attributes of the ctrl.loadrc attribute interface.
The method according to claim 7 or 10, wherein the lazy loading service manager can communicate with an application program.
The method according to claim 13, wherein the first request or the second request comes from the application program.
The method according to claim 13, wherein the lazy loading service manager can communicate with the application program through a software development kit.
An Android system startup device, characterized in that the init service in the Android system includes a first init service and a second init service; the java service in the Android system includes a first java service and a second java service, so The device includes: a memory and a processor;

The memory is used to store a computer program;

The processor is used to execute the computer program and when executing the computer program, implement the following steps:

After the kernel layer of the Android system is started up, parse and load the first init service recorded by the first init script, where the first init service includes a java startup service;

After loading the java startup service, load the first java service;

After the loading of the first java service is completed, the desktop launcher is started to complete the startup of the Android system; wherein the second init service and the second java service can be loaded after the Android system is started.
The device according to claim 16, wherein the processor implements the following steps when executing the computer program:

Automatically parse and load the first init service recorded by the first init script in the default path.
18. The device according to claim 17, wherein the file corresponding to the second init script of the second init service is placed in a non-default path.
The device according to claim 18, wherein the file corresponding to the second init script is placed in a non-default path that can be parsed and loaded by the init process.
The device according to claim 16, wherein the processor implements the following steps when executing the computer program:

Make the SystemServer process load the first java service. The first java service includes a lazy loading service manager and other first java services. The second init service and the second java service can be completed after the Android system is started. It is loaded by the lazy loading service manager.
The device according to claim 20, wherein the processor implements the following steps when executing the computer program:

Enabling the SystemServer process to load the lazy loading service manager;

Through the lazy loading service manager, the java services that need to be lazy loaded are marked to obtain the marked second java service, and the init services that need to be lazy loaded are marked to obtain the marked second init service.
The device according to claim 21, wherein the processor implements the following steps when executing the computer program:

After the Android system is started, receiving a first request for loading a specified java service through the lazy loading service manager;

According to the first request, the specified java service is loaded.
The apparatus according to claim 22, wherein the marked second java service includes a correspondence between a lazy-loaded java service name and the loading code corresponding to the lazy-loaded java service name;

When the processor executes the computer program, the following steps are implemented:

Determining the corresponding lazy loading java service name and the loading code corresponding to the lazy loading java service name according to the name of the specified java service carried in the first request;

Load the loading code corresponding to the lazy loading java service name.
The apparatus according to claim 21, wherein the lazy loading service manager can communicate with the init process.
The device according to claim 24, wherein the processor implements the following steps when executing the computer program:

After the Android system is started, receiving a second request for loading a specified init service through the lazy loading service manager;

According to the second request, the lazy loading service manager enables the init process to parse and load the specified init service recorded by the corresponding second init script.
The device according to claim 25, wherein the marked second init service includes a lazy-loaded init service name, a lazy-loaded init script corresponding to the lazy-loaded init service name, and a lazy-loaded init script corresponding to the lazy-loaded init script Correspondence between paths;

When the processor executes the computer program, the following steps are implemented:

Determine the corresponding lazy loading init service name, the lazy loading init script corresponding to the lazy loading init service name, and the lazy loading path corresponding to the lazy loading init script according to the name of the designated init service carried in the second request;

The lazy loading service manager enables the init process to analyze and load the lazy loading init service recorded by the lazy loading init script according to the lazy loading path.
The device according to any one of claims 24-26, wherein the lazy loading service manager can communicate with the init process through the ctrl.loadrc attribute interface of the init process, and the init process can Load the second init initialization script in the parameters carried by the attributes of the ctrl.loadrc attribute interface.
The device according to claim 22 or 25, wherein the lazy loading service manager can communicate with an application program.
The device according to claim 28, wherein the first request or the second request comes from the application program.
The device according to claim 28, wherein the lazy loading service manager can communicate with the application program through a software development kit.
A terminal device, characterized in that the operating system of the terminal device includes an Android system, the init service in the Android system includes a first init service and a second init service; the java service of the Android system includes a first java Service and a second java service, the terminal device includes: a processor, and a memory connected to the processor, an input/output device, and a communication circuit;

The memory is used to store a computer program;

The processor is used to execute the computer program and when executing the computer program, implement the following steps:

After the kernel layer of the Android system is started up, parse and load the first init service recorded by the first init script, where the first init service includes a java startup service;

After loading the java startup service, load the first java service;

After the loading of the first java service is completed, the desktop launcher is started to complete the startup of the Android system; wherein the second init service and the second java service can be loaded after the Android system is started.
The terminal device according to claim 31, wherein the input and output devices comprise a display screen, a keyboard, a USB interface, a headphone interface, a camera, a speaker, and a receiver.
The terminal device according to claim 31, wherein the processor implements the following steps when executing the computer program:

Automatically parse and load the first init service recorded by the first init script in the default path.
The terminal device according to claim 33, wherein the file corresponding to the second init script of the second init service is placed in a non-default path.
The terminal device according to claim 34, wherein the file corresponding to the second init script is placed in a non-default path that can be parsed and loaded by the init process.
The terminal device according to claim 31, wherein the processor implements the following steps when executing the computer program:

Make the SystemServer process load the first java service. The first java service includes a lazy loading service manager and other first java services. The second init service and the second java service can be completed after the Android system is started. It is loaded by the lazy loading service manager.
The terminal device according to claim 36, wherein the processor implements the following steps when executing the computer program:

Enabling the SystemServer process to load the lazy loading service manager;

Through the lazy loading service manager, the java services that need to be lazy loaded are marked to obtain the marked second java service, and the init services that need to be lazy loaded are marked to obtain the marked second init service.
The terminal device according to claim 37, wherein the processor implements the following steps when executing the computer program:

After the Android system is started, receiving a first request for loading a specified java service through the lazy loading service manager;

According to the first request, the specified java service is loaded.
The terminal device according to claim 38, wherein the marked second java service includes a correspondence between a lazy loading java service name and a loading code corresponding to the lazy loading java service name;

When the processor executes the computer program, the following steps are implemented:

Determining the corresponding lazy loading java service name and the loading code corresponding to the lazy loading java service name according to the name of the specified java service carried in the first request;

Load the loading code corresponding to the lazy loading java service name.
The terminal device according to claim 37, wherein the lazy loading service manager can communicate with the init process.
The terminal device according to claim 40, wherein the processor implements the following steps when executing the computer program:

After the Android system is started, receiving a second request for loading a specified init service through the lazy loading service manager;

According to the second request, the lazy loading service manager enables the init process to parse and load the specified init service recorded by the corresponding second init script.
The terminal device according to claim 41, wherein the marked second init service includes a lazy loading init service name, a lazy loading init script corresponding to the lazy loading init service name, and a lazy loading init script corresponding to the lazy loading init script. Correspondence between loading paths;

When the processor executes the computer program, the following steps are implemented:

Determine the corresponding lazy loading init service name, the lazy loading init script corresponding to the lazy loading init service name, and the lazy loading path corresponding to the lazy loading init script according to the name of the designated init service carried in the second request;

The lazy loading service manager enables the init process to analyze and load the lazy loading init service recorded by the lazy loading init script according to the lazy loading path.
The terminal device according to any one of claims 40-42, wherein the lazy loading service manager can communicate with the init process through the ctrl.loadrc attribute interface of the init process, and the init process The second init initialization script in the parameters carried by the attributes of the ctrl.loadrc attribute interface can be loaded.
The terminal device according to claim 38 or 41, wherein the lazy loading service manager can communicate with an application program.
The terminal device according to claim 44, wherein the first request or the second request comes from the application program.
The terminal device according to claim 44, wherein the lazy loading service manager can communicate with the application program through a software development kit.
A photographing device, characterized in that the operating system of the photographing device includes an Android system, the init service in the Android system includes a first init service and a second init service; the java service of the Android system includes the first java Service and a second java service, the photographing device includes: a processor and a memory;

The memory is used to store a computer program;

The processor is used to execute the computer program and when executing the computer program, implement the following steps:

After the kernel layer of the Android system is started up, parse and load the first init service recorded by the first init script, where the first init service includes a java startup service;

After loading the java startup service, load the first java service;

After the loading of the first java service is completed, the desktop launcher is started to complete the startup of the Android system; wherein the second init service and the second java service can be loaded after the Android system is started.
The photographing device according to claim 47, wherein the processor implements the following steps when executing the computer program:

Automatically parse and load the first init service recorded by the first init script in the default path.
The photographing device according to claim 48, wherein the file corresponding to the second init script of the second init service is placed in a non-default path.
The photographing device according to claim 49, wherein the file corresponding to the second init script is placed in a non-default path that can be parsed and loaded by the init process.
The photographing device according to claim 47, wherein the processor implements the following steps when executing the computer program:

Make the SystemServer process load the first java service. The first java service includes a lazy loading service manager and other first java services. The second init service and the second java service can be completed after the Android system is started. It is loaded by the lazy loading service manager.
The photographing device according to claim 51, wherein the processor implements the following steps when executing the computer program:

Enabling the SystemServer process to load the lazy loading service manager;

Through the lazy loading service manager, the java services that need to be lazy loaded are marked to obtain the marked second java service, and the init services that need to be lazy loaded are marked to obtain the marked second init service.
The photographing device according to claim 52, wherein the processor implements the following steps when executing the computer program:

After the Android system is started, receiving a first request for loading a specified java service through the lazy loading service manager;

According to the first request, the specified java service is loaded.
The photographing device according to claim 53, wherein the marked second java service includes a correspondence between a lazy loading java service name and the loading code corresponding to the lazy loading java service name;

When the processor executes the computer program, the following steps are implemented:

Determining the corresponding lazy loading java service name and the loading code corresponding to the lazy loading java service name according to the name of the specified java service carried in the first request;

Load the loading code corresponding to the lazy loading java service name.
The photographing device according to claim 52, wherein the lazy loading service manager can communicate with the init process.
The photographing device according to claim 55, wherein the processor implements the following steps when executing the computer program:

After the Android system is started, receiving a second request for loading a specified init service through the lazy loading service manager;

According to the second request, the lazy loading service manager enables the init process to parse and load the specified init service recorded by the corresponding second init script.
The photographing device according to claim 56, wherein the marked second init service includes a lazy loading init service name, a lazy loading init script corresponding to the lazy loading init service name, and a lazy loading init script corresponding to the lazy loading init script. Correspondence between loading paths;

When the processor executes the computer program, the following steps are implemented:

Determine the corresponding lazy loading init service name, the lazy loading init script corresponding to the lazy loading init service name, and the lazy loading path corresponding to the lazy loading init script according to the name of the designated init service carried in the second request;

The lazy loading service manager enables the init process to analyze and load the lazy loading init service recorded by the lazy loading init script according to the lazy loading path.
The photographing device according to any one of claims 55-57, wherein the lazy loading service manager can communicate with the init process through the ctrl.loadrc attribute interface of the init process, and the init process The second init initialization script in the parameters carried by the attributes of the ctrl.loadrc attribute interface can be loaded.
The photographing device according to claim 53 or 56, wherein the lazy loading service manager can communicate with an application program.
The photographing device according to claim 59, wherein the first request or the second request comes from the application program.
The photographing device according to claim 59, wherein the lazy loading service manager can communicate with the application through a software development kit.
A computer-readable storage medium, characterized in that, the computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the processor realizes any one of claims 1-15. The method to start the Android system.