Electronic device and high-speed communication method

Abstract

The present invention comprises: a kernel (4) having a plurality of communication mechanisms (5); a framework (6) launched by the kernel (4); a first application that, prior to the launching of the framework (6), operates by directly using the communication mechanisms (5) on the kernel (4); and a second application that operates by indirectly using the communication mechanisms (5) via the framework (6), after the launching of the framework (6).

Description

[Technical field]

[0001] The present disclosure relates to electronic devices and high speed communication It concerns the method. [Background technology]

[0002] Conventionally, in a technology for establishing a communication connection between an electronic device that uses a high-performance OS (Operating System) and a smartphone, the communication connection process is initiated when the high-performance OS is started up on a CPU (Central Processing Unit) that has the high-performance OS and an application (hereinafter referred to as a "normal application") that operates using the high-performance OS is started. Incidentally, a technology is known for quickly providing communication functions in a software radio, in which when the startup process of the GPP function is completed in the main control unit (e.g., a CPU), a modem unit (e.g., a DSP (Digital Signal Processor)) starts startup processing and enables communication, thereby enabling the main control unit to start communication without waiting for the startup of an OS or the like (e.g., Patent Document 1). [Prior art documents] [Patent documents]

[0003] [Patent Document 1] JP 2017-220003 A Summary of the Invention [Problem to be solved by the invention]

[0004] Conventional communication connection technology for electronic devices using advanced operating systems to connect to smartphones had the problem that it took time to connect to the smartphone because the communication connection process with the smartphone only began once a normal application running using the advanced OS was running. Even if the above-mentioned startup processing technology for software defined radios is applied to conventional communication connection technology, it requires H / W other than the CPU, such as a modem, and it is necessary to switch processing from the H / W other than the CPU to an application in the high-performance OS. When switching processing from the H / W other than the CPU to an application in the high-performance OS, there is a possibility that retry processing may be repeated, and the above-mentioned problem remains unsolved.

[0005] The present disclosure has been made to solve the above-mentioned problems, and aims to provide an electronic device that enables communication connection with a smartphone using a high-performance OS in a shorter time than conventional communication connections. [Means for solving the problem]

[0006] The electronic device according to the present disclosure includes a kernel having multiple communication mechanisms, a framework launched by the kernel, a first application that operates on the kernel before the framework is launched by directly using the communication mechanisms, and a second application that operates after the framework is launched by indirectly using the communication mechanisms using the framework. Effect of the Invention

[0007] According to the present disclosure, when communicating with a smartphone using a high-performance OS, communication connection can be established in a shorter time than with conventional communication connections. [Brief description of the drawings]

[0008] [Figure 1] 1 is a block diagram showing an example of a hardware configuration of an electronic device according to a first embodiment. [Diagram 2] 2 is a block diagram showing an example of a software configuration of the electronic device according to the first embodiment. FIG. [Diagram 3] 13 is a block diagram showing another example of the software configuration of the electronic device according to the first embodiment. FIG. [Figure 4]1 is a block diagram showing an example of a hardware configuration of an electronic device according to a first embodiment. [Diagram 5] FIG. 4 is a diagram showing an example of a start-up order of the electronic device according to the first embodiment. [Figure 6] 4 is a diagram showing an example of the operation of the electronic device in the first embodiment when a CPU has the functions shown in FIG. [Figure 7] 3 is a diagram showing an example of the operation of the electronic device in the first embodiment when a CPU has the functions shown in FIG. 2. [Figure 8] 1A and 1B are diagrams illustrating an example of the operation of a conventional electronic device in which a communication connection with a smartphone is not started until a normal application is started. [Figure 9] 13A and 13B are diagrams illustrating another example of the operation of a conventional electronic device in which a communication connection with a smartphone is not started until a normal application is started. [Figure 10] 4 is a diagram showing an example of the operation of the electronic device in the second embodiment when a CPU has the functions shown in FIG. [Figure 11] 3 is a diagram showing an example of the operation of the electronic device in the second embodiment when a CPU has the functions shown in FIG. 2. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0009] Hereinafter, embodiments of the present disclosure will be described in detail with reference to the drawings. Embodiment 1 First, the configuration of the electronic device according to the first embodiment will be described. In the first embodiment, it is assumed that the electronic device is mounted on an in-vehicle device such as a navigation device. For example, the electronic device establishes a communication connection with a smartphone in the vehicle, and displays the smartphone's operation screen or images stored in the smartphone on the navigation device. The electronic device performs wired or wireless communication. Specifically, the electronic device performs communication via USB (Universal Serial Bus), Bluetooth (registered trademark; description omitted below), or Wi-Fi (registered trademark; description omitted below).

[0010] Fig. 1 is a block diagram showing an example of a hardware configuration of an electronic device according to embodiment 1. Fig. 1 shows an example of a hardware configuration of an electronic device that establishes a communication connection with a smartphone 2 and executes an application that displays an operation video of the smartphone 2 or a video or the like stored in the smartphone 2.

[0011] The electronic device according to the first embodiment is realized by the operation of the CPU1. As shown in FIG. 1, the CPU 1 is connected to a smartphone 2 for communication, and causes an operation image of the smartphone 2 or an image stored in the smartphone 2 to be displayed on a display 3. The CPU 1 has a high-performance OS (Operating System). Here, the high-performance OS refers to an OS that performs high-level information processing, such as the Linux (registered trademark, not described below) OS or the Android (registered trademark, not described below) OS. In the first embodiment, the CPU 1 has the Android OS.

[0012] 1 is similar to a normal hardware configuration (hardware configuration not requiring high-speed communication) for establishing a communication connection with a smartphone 2, and the electronic device does not have a separate hardware configuration for performing high-speed communication. In the first embodiment, the electronic device realizes high-speed communication with the smartphone 2 by using the hardware configuration as shown in FIG.

[0013] Fig. 2 is a block diagram showing an example of a software configuration of the electronic device according to embodiment 1. Note that Fig. 2 shows the software configuration executed by the CPU 1 in Fig. 1.

[0014] As shown in FIG. 2, the CPU 1 has the function of executing a kernel 4 , a framework 6 , a native communication application 7 , a progress status management file 8 , and a normal communication application 9 . The progress status management file 8 manages whether or not the normal communication application 9 is activated. Specifically, the progress status management file 8 holds information such as a numerical value indicating whether or not the normal communication application 9 is activated.

[0015] The kernel 4 has a plurality of communication mechanisms 5, which are functions for communicating with the smartphone 2. The kernel 4 also has drivers and hardware resources for communicating with the smartphone 2. The communication mechanisms 5 exist above the drivers. In the first embodiment, the kernel 4 is described as being a Linux kernel, but is not limited thereto. Also, in the first embodiment, the communication mechanism 5 is assumed to perform communication by USB of Android OS, communication by Bluetooth, or communication by Wi-Fi.

[0016] The framework 6 includes an abstract communication mechanism (not shown) that abstracts the communication mechanism 5, drivers, and hardware resources included in the kernel 4.

[0017] The native communication application 7 is an application for establishing a communication connection with the smartphone 2, and operates by directly utilizing the communication mechanism 5. Note that the native communication application 7 only has a basic function of communicating with the smartphone 2, and does not have a function of outputting operation images of the smartphone 2 or images stored in the smartphone 2. In other words, the native communication application 7 has specific functions among the functions of the normal communication application 9.

[0018] The normal communication application 9 is an application for establishing a communication connection with the smartphone 2 and displaying operation images of the smartphone 2 or images stored in the smartphone 2, and operates by indirectly using the communication mechanism 5 via the framework 6, more specifically, via an abstraction communication mechanism of the framework 6. In this way, the normal communication application 9 has complex functions such as displaying images.

[0019] Fig. 3 is a block diagram showing another example of the software configuration of the electronic device according to embodiment 1. Note that the software configuration shown in Fig. 3 is a generalized version of the software configuration shown in Fig. 2. As shown in Fig. 3, the kernel 4 has a functional mechanism 10 including the communication mechanism 5 of Fig. 2. The kernel 4 also has drivers and hardware resources of a peripheral group including the drivers and hardware resources described with reference to Fig. 2.

[0020] The framework 6 includes a function mechanism 10, a driver, and an abstract function mechanism (not shown) that abstracts hardware resources.

[0021] The native application 11 (first application) operates by directly using the functional mechanism 10. The normal application 12 (second application) has the functions of the native application 11, and operates by indirectly using the functional mechanism 10 via the framework 6, more specifically, via an abstract functional mechanism of the framework 6. The native application 11 has a specific function among the functions of the normal application 12.

[0022] 4 is a block diagram showing an example of a hardware configuration of the electronic device according to embodiment 1. Note that in FIG. 4, the hardware configuration around the CPU 1 in FIG. 4, a NOR type flash memory 13, an eMMC (embedded multi media card) 14, and a DRAM (Dynamic Random Access Memory) 15 are connected to the CPU 1. Note that the NOR type flash memory 13, the eMMC 14, and the DRAM 15 are omitted from FIG.

[0023] The NOR flash memory 13 stores a boot loader 16. Note that the NOR flash memory 13 may be any storage device with a small capacity, such as a Read Only Memory (ROM).

[0024] The eMMC 14 stores a kernel 4, a framework 6, a progress status management file 8, and applications (not shown) including a native communication application 7 and a normal communication application 9. Note that the eMMC 14 may be any large-capacity storage device, and may be, for example, a hard disk or the like.

[0025] The CPU 1 loads at least one of the kernel 4, the framework 6, and the boot loader 16 into the DRAM 15 and runs them. The native communication application 7 and the normal communication application 9 shown in FIG. 2 and the native application 11 and the normal application 12 shown in FIG. 3 are stored in the eMMC 14.

[0026] Next, the overall operation of the electronic device will be described with reference to FIG. FIG. 5 is a diagram showing an example of a start-up order of the electronic device according to the first embodiment. 5, the electronic device operates by starting up the boot loader 16, the kernel 4, and the framework 6 in that order. The start-up of the boot loader 16, the kernel 4, and the framework 6 will be described in detail below.

[0027] The CPU 1 loads the boot loader 16 stored in the NOR flash memory 13 into the DRAM 15 using the program stored in the NOR flash memory 13. The loaded boot loader 16 starts up and runs in the DRAM 15. Here, the program stored in the NOR flash memory 13 has a function of loading the boot loader 16 into the DRAM 15.

[0028] The boot loader 16 loads the kernel 4 stored in the eMMC 14 into the DRAM 15. The loaded kernel 4 starts up and runs in the DRAM 15. Specifically, the kernel 4 initializes and develops drivers, hardware resources, and functional mechanisms.

[0029] The kernel 4 loads the framework 6 stored in the eMMC 14 into the DRAM 15. The loaded framework 6 starts up and runs in the DRAM 15. Specifically, the framework 6 initializes and develops the abstracted function mechanism and other software components (other abstracted function mechanisms).

[0030] In the first embodiment, the advanced OS is configured with a framework 6. The kernel 4 and the framework 6 operate cooperatively in the DRAM 15. On the other hand, the boot loader 16 is ejected from the DRAM 15 and does not operate after the loading of the advanced OS is completed. The boot loader 16 and the advanced OS are different systems. Note that, in the first embodiment, the advanced OS (framework 6) is described as being the Android OS, but is not limited to this.

[0031] Next, the operation of the electronic device will be described in detail. FIG. 6 is a diagram showing an example of the operation of the electronic device in the first embodiment when the CPU 1 has the functions shown in FIG.

[0032] 6, after the power supply of the CPU 1 is turned on, the boot loader 16 loads the kernel 4 into the DRAM 15 (see FIG. 4). The kernel 4 starts up in the DRAM 15.

[0033] The CPU 1 loads the native application 11 into the DRAM 15 and starts the native application 11. The native application 11 directly utilizes the functional mechanism 10 of the kernel 4 to execute a predetermined function. Here, when the CPU 1 starts the native application 11, it starts the progress state management file 8.

[0034] After the native application 11 is started, the kernel 4 loads the framework 6 into the DRAM 15. The framework 6 starts up in the DRAM 15.

[0035] After the framework 6 is started, the CPU 1 loads the normal application 12 into the DRAM 15 and starts the normal application 12. The normal application 12 executes a predetermined function by indirectly using the function mechanism 10 of the kernel 4 via the framework 6, more specifically, via an abstraction function mechanism that the framework 6 has.

[0036] Here, when the CPU 1 starts the native application 11, the progress status management file 8 is started before the normal application 12 is started. When the normal application 12 becomes ready to be started, the native application 11 judges this by checking the progress status management file 8. Specifically, when the normal application 12 starts, it writes information indicating that it has started to the progress status management file 8. When the writing is performed, a file change notification of the progress status management file 8 is output to the native application 11. The file change notification is output, for example, by the progress status management file 8. When the native application 11 obtains the file change notification, it refers to the progress status management file 8 and confirms that the normal application 12 is ready to be started by the writing of information indicating that the normal application 12 has started. The native application 11 ends the function that it has been executing at any timing, such as the timing when the normal application 12 becomes ready to be started. That is, the function that the native application 11 has been executing is taken over by the normal application 12 and is executed by the normal application 12.

[0037] As described above, in the first embodiment, the CPU 1 starts the native application 11 to communicate with the smartphone 2 using the functional mechanism 10 in the kernel 4 before starting the normal application 12. This allows the electronic device to start a communication operation with the smartphone 2 without waiting until the CPU 1 starts the normal application 12 after starting the advanced OS (framework 6) and the normal application 12 communicates with the smartphone 2. As a result, the electronic device can achieve high-speed communication with the smartphone 2.

[0038] As described above, the native application 11 is loaded and developed in the DRAM 15. Therefore, the load time depends on the capacity of the native application 11. Therefore, by minimizing the functions of the native application 11 and reducing the program capacity of the native application 11, the load time of the native application 11 is optimized, and the time from when the power of the CPU 1 is turned on until the operation of the native application 11 can be shortened.

[0039] Furthermore, the native application 11 and the normal application 12 operate by directly or indirectly utilizing the same functional mechanism 10. The native application 11 determines whether the normal application 12 has started by checking the progress status management file 8, and when the normal application 12 starts, the communication operation with the smartphone 2 is handed over from the native application 11 to the normal application 12. Therefore, the electronic device can prevent repeated retry processing when switching from communication by the native application 11 to communication by the normal application 12. In addition, the processing load is reduced.

[0040] The native application 11 ends its operation at any timing after the execution of the normal application 12. The arbitrary timing may be when the normal application 12 starts to operate, or when the normal application 12 has completely operated, that is, after the operation of the normal application 12.

[0041] FIG. 7 is a diagram showing an example of the operation of the electronic device in the first embodiment when the CPU 1 has the functions shown in FIG.

[0042] 7, after the power supply of the CPU 1 is turned on, the boot loader 16 loads the kernel 4 into the DRAM 15 (see FIG. 4). The kernel 4 starts up in the DRAM 15.

[0043] The CPU 1 loads the native communication application 7 into the DRAM 15 and starts the native communication application 7. The native communication application 7 directly uses the communication mechanism 5 of the kernel 4 to communicate with the smartphone 2. Here, when the CPU 1 starts the native communication application 7, it starts the progress state management file 8.

[0044] After the native communication application 7 is started, the kernel 4 loads the framework 6 into the DRAM 15. The framework 6 starts up in the DRAM 15.

[0045] After the framework 6 is started, the CPU 1 loads the normal communication application 9 into the DRAM 15 and starts the normal communication application 9. The normal communication application 9 performs communication with the smartphone 2 via the framework 6, more specifically, via an abstraction communication mechanism of the framework 6, by indirectly using the communication mechanism 5 of the kernel 4. Then, the normal communication application 9 displays an operation image of the smartphone 2 or an image or the like stored in the smartphone 2 on the display 3.

[0046] Here, when the CPU 1 starts the native communication application 7, the progress status management file 8 is started before the normal communication application 9 is started. When the normal communication application 9 becomes available for starting, the native communication application 7 judges this by checking the progress status management file 8. Specifically, when the normal communication application 9 starts, it writes information indicating that it has started to the progress status management file 8. When the writing is performed, a file change notification of the progress status management file 8 is output to the native communication application 7. The file change notification is output, for example, by the progress status management file 8. When the native communication application 7 obtains the file change notification, it refers to the progress status management file 8, and confirms that the normal communication application 9 is available for starting by the writing of information indicating that the normal communication application 9 has started. The native communication application 7 ends the function that it has been executing at any timing, such as the timing when the normal communication application 9 becomes available for starting. That is, the function that the native communication application 7 has been executing is taken over by the normal communication application 9, and is executed by the normal communication application 9.

[0047] As described above, in the first embodiment, the CPU 1 starts the native communication application 7 so as to communicate with the smartphone 2 using the communication mechanism 5 in the kernel 4 before starting the normal communication application 9. This allows the electronic device to start communication with the smartphone 2 without waiting until the CPU 1 starts the normal communication application 9 after starting the advanced OS (framework 6) and the normal communication application 9 starts communication with the smartphone 2. As a result, the electronic device can achieve high-speed communication with the smartphone 2.

[0048] As described above, the native communications application 7 is loaded and developed in the DRAM 15. Therefore, the loading time depends on the capacity of the native communications application 7. Therefore, by minimizing the functions of the native communication application 7 and reducing the program capacity of the native communication application 7, the load time of the native communication application 7 is optimized, and the time from when the power of the CPU 1 is turned on to when the native communication application 7 starts operating can be shortened.

[0049] Furthermore, the native communication application 7 and the normal communication application 9 operate directly or indirectly using the same communication mechanism 5. The native communication application 7 determines whether the normal communication application 9 has started by checking the progress status management file 8, and when the normal communication application 9 starts, the communication operation with the smartphone 2 is handed over from the native communication application 7 to the normal communication application 9. Therefore, the electronic device can prevent repeated retry processing when switching from communication by the native communication application 7 to communication by the normal communication application 9. In addition, the processing load is also reduced.

[0050] The native communication application 7 terminates its operation at any timing after the execution of the normal communication application 9. The arbitrary timing may be when the normal communication application 9 starts to operate, or when the normal communication application 9 has completely operated, in other words, after the operation of the normal communication application 9.

[0051] As described above, according to the first embodiment, the electronic device can realize high-speed communication with the smartphone 2 by starting the native application 11 (or the native communication application 7) before starting the normal application 12 (or the normal communication application 9). That is, the electronic device can establish a communication connection with a smartphone using a high-performance OS in a shorter time than in the conventional communication connection.

[0052] 8 and 9 are diagrams showing an example of the operation of a conventional electronic device in which communication connection with the smartphone 2 is not started until the normal application 24 is activated. Note that Fig. 8 is a diagram showing an example of the operation of the electronic device when the CPU 1 has the functions shown in Fig. 3, and Fig. 9 is a diagram showing an example of the operation of the electronic device when the CPU 1 has the functions shown in Fig. 2. In the conventional technology for communication connection with a smartphone 2, after the boot loader 31 loads the kernel 21, the CPU 1 starts the high-function OS (framework 23) and then uses the functional mechanism 22 (or communication mechanism 25) in the kernel 21 to start the normal application 24 (or normal communication application 26), and the communication connection with the smartphone 2 is not established until the normal application 24 (or normal communication application 26) performs communication operation with the smartphone 2.

[0053] In contrast, in the electronic device according to the first embodiment, as described above, the CPU 1 starts the native application 11 (or the native communication application 7) to communicate with the smartphone 2 using the functional mechanism 10 including the communication mechanism 5 in the kernel 4 before starting the normal application 12 (or the normal communication application 9). This allows the electronic device to start a communication operation with the smartphone 2 without waiting until the CPU 1 starts the normal application 12 (or the normal communication application 9) after starting the advanced OS (framework 6) and the normal application 12 (or the normal communication application 9) performs a communication operation with the smartphone 2. As a result, the electronic device can achieve high-speed communication with the smartphone 2.

[0054] Furthermore, according to the first embodiment, the electronic device can be quickly started up at the time of cold boot by minimizing the functions of the native application 11 (or the native communication application 7).

[0055] Furthermore, by using the same functional mechanism 10 (or communication mechanism 5) for the native application 11 (or native communication application 7) and the normal application 12 (or normal communication application 9), repeated retry processing can be prevented, enabling smooth handover of communication.

[0056] Embodiment 2 In order to operate all abstraction function mechanisms in the high-performance OS (framework 6), it is necessary to start all function mechanisms 10 in the kernel 4. Therefore, the kernel 4 initializes and expands all drivers, all hardware resources, and all function mechanisms 10, and the initialization and expansion of the kernel 4 takes time.

[0057] Therefore, in the second embodiment, the electronic device separates the drivers, hardware resources, and functional mechanisms that the kernel 4 initializes and develops into drivers, hardware resources, and functional mechanisms that are necessary for the operation of the native application 11 (or native communication application 7) and drivers, hardware resources, and functional mechanisms that are not necessary for the operation of the native application 11 (or native communication application 7). The electronic device then performs initialization and development of the drivers, hardware resources, and functional mechanisms that are not necessary for the operation of the native application 11 (or native communication application 7) after the native application 11 (or native communication application 7) is started, thereby shortening the time required for the kernel 4 to initialize and develop. As a result, the electronic device shortens the time until the native application 11 (or native communication application 7) is started. In addition, the configuration and operation of the electronic device of the second embodiment are the same as those of the electronic device described in the first embodiment, except that the drivers, hardware resources, and functional mechanisms that the kernel 4 initializes and deploys are divided into those before and after the native application 11 is launched. Therefore, detailed explanations are omitted.

[0058] FIG. 10 is a diagram showing an example of the operation of the electronic device in the second embodiment when the CPU 1 has the functions shown in FIG.

[0059] 10, after the power supply of the CPU 1 is turned on, the boot loader 16 loads the kernel 4 into the DRAM 15. The kernel 4 starts up in the DRAM 15. At this time, the kernel 4 initializes and develops the drivers, hardware resources, and functional mechanisms required for the native application 11 of the functional mechanism 10.

[0060] The CPU 1 loads the native application 11 into the DRAM 15 and starts the native application 11. The native application 11 directly uses a functional mechanism required for the native application 11 among the functional mechanisms 10 of the kernel 4 to execute a predetermined function. Here, when the CPU 1 starts the native application 11, it starts the progress state management file 8.

[0061] After the native application 11 is executed, the kernel 4 initializes and deploys the drivers, hardware resources, and functional mechanisms that are not necessary for the native application 11 out of the functional mechanisms 10 .

[0062] The subsequent operations (such as the start of the normal application 12) have already been described in the first embodiment (see FIG. 6), so a duplicated description will be omitted.

[0063] In this way, the electronic device of embodiment 2 initializes and deploys only the drivers, hardware resources, and functional mechanisms required for the native application 11 before the native application 11 is launched, thereby making it possible to shorten the time from when the power of the CPU 1 is turned on to when the native application 11 is launched.

[0064] FIG. 11 is a diagram showing an example of the operation of the electronic device in the second embodiment when the CPU 1 has the functions shown in FIG.

[0065] 11, after the power supply of the CPU 1 is turned on, the boot loader 16 loads the kernel 4 into the DRAM 15. The kernel 4 starts up in the DRAM 15. At this time, the kernel 4 initializes and develops the drivers, hardware resources, and communication mechanism 5 required for the native communication application 7 of the functional mechanism 10.

[0066] The CPU 1 loads the native communication application 7 into the DRAM 15 and starts the native communication application 7. The native communication application 7 directly uses the communication mechanism 5 of the kernel 4 to communicate with the smartphone 2. Here, when the CPU 1 starts the native communication application 7, it starts the progress state management file 8.

[0067] After the native communications application 7 is executed, the kernel 4 initializes and deploys drivers, hardware resources, and functional mechanisms (functional mechanisms other than the communications mechanism 5) that are not necessary for the native communications application 7 among the functional mechanisms 10.

[0068] The subsequent operations (such as starting the normal communication application 9) have already been described in the first embodiment (see FIG. 7), so a duplicated description will be omitted.

[0069] In this way, the electronic device of embodiment 2 initializes and deploys only the drivers, hardware resources, and communication mechanism 5 required for the native communication application 7 before launching the native communication application 7, thereby making it possible to shorten the time from powering on the CPU 1 to launching the native communication application 7.

[0070] As described above, according to the second embodiment, the electronic device first starts the functional mechanisms required for the native application 11 (or the native communication application 7) and then executes the native application 11 (or the native communication application 7), thereby shortening the time required for initializing and developing the kernel 4 at cold boot time and enabling the kernel 4 to be started at high speed. This allows the electronic device to shorten the time it takes for the native application 11 to be started. As a result, the electronic device can establish a communication connection with the smartphone 2 at higher speed than when the drivers, hardware resources, and functional mechanisms initialized and developed by the kernel 4 are not divided into drivers, hardware resources, and functional mechanisms required for the operation of the native application 11 (or the native communication application 7) and drivers, hardware resources, and functional mechanisms not required for the operation of the native application 11 (or the native communication application 7).

[0071] In the above-described first and second embodiments, the progress status management file 8 may be provided, for example, in the native application 11 (or the native communication application 7) and in the normal application 12 (or the normal communication application 9). Furthermore, the progress state management file 8 may be provided, for example, in the native application 11 (or the native communication application 7) and in the function mechanism 10 (communication mechanism 5).

[0072] In the above embodiment 1, the electronic device establishes a communication connection with the smartphone 2 in the vehicle and displays an operation image of the smartphone 2 or an image stored in the smartphone 2 in the navigation device, but this is merely an example. For example, the electronic device may establish a communication connection with the smartphone 2 in the vehicle and output music or the like stored in the smartphone 2 from a speaker (not shown). In such a case, the electronic device can apply the embodiments 1 and 2 to the communication connection with the smartphone 2. Furthermore, for example, the electronic device is not limited to being installed in an in-vehicle device, and may be installed in a home appliance such as a television.

[0073] It should be noted that the embodiments may be freely combined, any of the components in each embodiment may be modified, or any of the components in each embodiment may be omitted. [Industrial Applicability]

[0074] An electronic device according to the present disclosure can establish a high-speed communication connection with a smartphone. [Explanation of symbols]

[0075] 1 CPU, 2 Smartphone, 3 Display, 4 Kernel, 5 Communication mechanism, 6 Framework, 7 Native communication application, 8 Progress status management file, 9 Normal communication application, 10 Functional mechanism, 11 Native application, 12 Normal application, 13 NOR type flash memory, 14 eMMC, 15 DRAM, 16 Boot loader, 21 Kernel, 22 Functional mechanism, 23 Framework, 24 Normal application, 25 Communication mechanism, 26 Normal communication application, 31 Boot loader.

Claims

1. a kernel having a plurality of communication mechanisms; A framework launched by the kernel; a first application that runs on the kernel by directly using the communication mechanism before the framework is started; A second application that operates after the framework is started by indirectly utilizing the communication mechanism using the framework. An electronic device comprising:

2. A progress status management file for managing the running status of the second application using the communication mechanism is provided.

2. The electronic device according to claim 1,

3. The progress status management file is provided in the first application and the second application.

3. The electronic device according to claim 2.

4. The progress status management file is provided in the first application and in the communication mechanism.

3. The electronic device according to claim 2.

5. The kernel is a Linux kernel.

2. The electronic device according to claim 1,

6. The framework is the Android OS.

2. The electronic device according to claim 1,

7. The communication mechanism performs wired or wireless communication.

2. The electronic device according to claim 1,

8. A high-speed communication method for an electronic device having a high-performance OS that starts up in the order of a boot loader, a kernel, and a framework, comprising: the kernel has a plurality of communication mechanisms; a step of a first application running on the kernel by directly using the communication mechanism before the framework is started; the framework being launched by the kernel after operation of the first application; A step in which a second application runs by indirectly utilizing the communication mechanism using the framework after the framework is started. A high-speed communication method comprising:

Images