Display method and display device for status bar of Android device, vehicle and program product

Abstract

The invention discloses an Android device status bar display method, an Android device status bar display device, a vehicle and a computer program product. The display method comprises the following steps: deleting to-be-displayed data intensively displayed in a status bar from an associated target application, and running the to-be-displayed data through an Android service process. Therefore, after the status bar and the service process are started, the status bar can be bound with the service process, and then the to-be-displayed data are obtained from the service process to complete display. In this way, the number of processes started in the startup process can be reduced, the system resource load is reduced, and on the basis that the startup duration is shortened, the fluency of the system after the Android device is started is guaranteed. After the target application is started, the service process can be bound to obtain the to-be-displayed data so as to guarantee the consistency of the to-be-displayed data. Both the status bar and the target application can subscribe to the callback service from the service process, so that the status bar and the target application update the display content in real time after the to-be-displayed data is updated, and the timeliness of the display content is guaranteed.

Description

Technical Field

[0001] The present application belongs to the technical field of electronic equipment, and in particular, relates to a method for displaying a status bar of an Android device, a display device for a status bar of an Android device, a vehicle, and a computer program product. Background Art

[0002] The status bar displays key information such as time, battery, and network, so that users can obtain information efficiently, and can provide users with operation portals to improve the convenience of operating related functions. The centralized display of key information saves screen space and improves user experience, and is an indispensable interactive component in the Android system.

[0003] The status bar is usually started when the device system is turned on. As the hardware functions become richer, the content displayed in the status bar is also increasing. In order to meet the interaction needs, the status bar not only needs to display the static information of the application, but also needs to be able to respond to the user's operation and display dynamic information in real time. The inventor of this application found that during the display process of the status bar, multiple applications need to be pulled up at the same time, which makes the system resource usage very high after the device system is turned on, affecting the startup speed and the fluency of the device after it is turned on. Summary of the invention

[0004] The present application provides a method for displaying the status bar of an Android device, a display device for the status bar of an Android device, a vehicle and a computer program product, which can reduce the number of processes started during the boot process, reduce the system resource load, and ensure the smoothness of the system after the Android device is started while shortening the boot time.

[0005] In a first aspect, the present application provides a method for displaying a status bar of an Android device, comprising:

[0006] During the boot process of the Android device, start the status bar and the Android service process;

[0007] The status bar is bound to the service process and obtains the data to be displayed from the service process to complete the display of the status bar.

[0008] In some embodiments, after the status bar is displayed, the method further includes:

[0009] After the target application associated with the data to be displayed is started, the target application is controlled to bind with the service process to obtain the data to be displayed and display it in the application interface of the target application.

[0010] In some embodiments, after the status bar is bound to the service process, the method further includes:

[0011] Control the status bar and / or the target application to subscribe to the service process to callback the data to be displayed;

[0012] Accordingly, after the status bar is displayed, the following steps are also included:

[0013] After the data to be displayed is updated, the control service process sends the updated data to be displayed to the status bar and / or the target application, so that the status bar and / or the target application updates the display based on the updated data to be displayed.

[0014] In some embodiments, the data to be displayed includes at least two types of sub-data; completing the display of the status bar includes:

[0015] For each type of subdata:

[0016] Control the status bar to send the key value corresponding to the sub-data to the service process;

[0017] Control the service process to receive and parse the key value;

[0018] The control service process returns the corresponding sub-data to the service process based on the parsed key value;

[0019] Control the status bar to receive and display sub data.

[0020] In some embodiments, after displaying the status bar is completed, the method further includes:

[0021] The control status bar generates a data request instruction in response to the user's operation on the displayed target sub-data; the target sub-data is any sub-data being operated;

[0022] The control status bar sends data request instructions to the service process;

[0023] The control service process sends the corresponding designated display data to the status bar based on the data request instruction, so that the status bar updates the display of the target sub-data based on the designated display data.

[0024] In some embodiments, the Android device is a car computer, and the control service process returns corresponding sub-data to the status bar based on the parsed key value, including:

[0025] The control service process transmits a request to obtain sub-data to the vehicle hardware through the vehicle system based on the parsed key value, and receives the sub-data returned by the vehicle hardware through the vehicle system to send the sub-data to the status bar.

[0026] In a second aspect, the present application provides a display device for a status bar of an Android device, comprising:

[0027] The startup module is used to start the status bar and the Android service process during the startup of the Android device;

[0028] The first display module is used to bind the status bar to the service process and obtain the data to be displayed from the service process to complete the display of the status bar.

[0029] In a third aspect, the present application provides a vehicle comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the steps of the method of the first aspect when executing the computer program.

[0030] In a fourth aspect, the present application provides a computer-readable storage medium, wherein the computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the steps of the method of the first aspect are implemented.

[0031] In a fifth aspect, the present application provides a computer program product, which includes a computer program. When the computer program is executed by one or more processors, it implements the steps of the method of the first aspect.

[0032] The first aspect of the present application has the beneficial effect compared with the prior art: the service process of the Android device runs the status bar to display the required data to be displayed, and the status bar and the service process are bound after startup, so that the status bar can obtain the data to be displayed from the service process to complete the display. In this process, all applications related to the data to be displayed will not be started due to the display requirements of the status bar. Especially when there are many applications related to the data to be displayed, the number of process startups at startup can be greatly reduced, the system resource load can be reduced, and the system fluency after the device is started can be ensured while shortening the startup time.

[0033] It can be understood that the beneficial effects of the second to fifth aspects mentioned above can be found in the relevant description of the first aspect mentioned above, and will not be repeated here. BRIEF DESCRIPTION OF THE DRAWINGS

[0034] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0035] Figure 1 The vehicle computer provided in the embodiment of the present application includes a display interface of a status bar;

[0036] Figure 2 The vehicle computer provided in the embodiment of the present application includes a display interface of an interactive pop-up box of WiFi in the status bar;

[0037] Figure 3 is a schematic flow chart of a method for displaying a status bar of an Android device provided in an embodiment of the present application;

[0038] Figure 4 is a schematic diagram of the interaction between the status bar and the target application and the service process provided in an embodiment of the present application;

[0039] Figure 5 It is a structural schematic diagram of a display device for the status bar of an Android device provided in an embodiment of the present application;

[0040] Figure 6 It is a schematic diagram of the structure of a vehicle provided in an embodiment of the present application. DETAILED DESCRIPTION

[0041] In the following description, specific details such as specific system structures, technologies, etc. are provided for the purpose of illustration rather than limitation, so as to provide a thorough understanding of the embodiments of the present application. However, it should be clear to those skilled in the art that the present application may also be implemented in other embodiments without these specific details. In other cases, detailed descriptions of well-known systems, devices, circuits, and methods are omitted to prevent unnecessary details from obstructing the description of the present application.

[0042] Terminology explanation:

[0043] Application (Application, APP): Every software application in the Android system.

[0044] AIDL (Android Interface Definition Language): An interface description language that allows the definition of the communication interface between the client and the server, and implements interface calls between different processes on Android devices.

[0045] Binding: The process of establishing a connection between two or more applications. When two applications need to share data, they first perform process binding, and after binding, data can be transmitted and accessed through AIDL.

[0046] App Launch by Module: A method of launching an application. Other applications launch the application through the Android system mechanism, which is called "pulling up".

[0047] Process: When each application is started, the system creates an independent process for it.

[0048] Service: One of the four major components of the Android system, it has a long life cycle, no visual interface, and is a service program running in the background.

[0049] An icon displayed on the status bar represents the status of an application. Figure 1In the interface of the car system, the contents displayed in the status bar are, from left to right, the account icon, message center icon, driving record icon, Bluetooth icon, WiFi icon and time icon. Each icon is not displayed statically, but a set of sub-functions of the corresponding function, which can be interactively operated by users, providing users with a convenient operation entry.

[0050] like Figure 2 As shown in the figure, after the WiFi icon is clicked, a virtual interactive button for WiFi switch is displayed; the saved networks and available networks are displayed separately, and a hyperlink to jump to the WiFi setting interface is displayed. Therefore, if you want to display the WiFi icon in the status bar, you need to start the network application, and the display of other function icons is similar.

[0051] As hardware devices are upgraded, more and more functions are added, and the number of function icons displayed in the status bar is also increasing. The status bar is usually activated during the boot process, which means that during the boot process of the Android device, the display of the status bar requires the activation of a large number of applications. This not only affects the boot speed, but also after the boot, a large number of applications correspond to a large number of processes, which occupies a large number of system resources and easily affects the smoothness of the Android device after startup.

[0052] In order to solve this problem, this application proposes a display method of the status bar of an Android device, which can reduce the number of processes started during the boot process, reduce the system resource load, and ensure the smoothness of the system after the Android device is started on the basis of shortening the boot time. The control method proposed in this application will be described below through specific embodiments.

[0053] The method for displaying the status bar of an Android device provided in the embodiment of the present application is mainly applied to electronic devices using the Android system, including mobile phones, tablet computers, vehicle-mounted devices, augmented reality (AR) / virtual reality (VR) devices, laptop computers, ultra-mobile personal computers (UMPC), netbooks, personal digital assistants (PDA), etc. The embodiment of the present application does not impose any restrictions on the specific types of electronic devices.

[0054] In order to illustrate the technical solution proposed in this application, each embodiment will be described below using an Android device as the execution subject.

[0055] Figure 3 A schematic flow chart of a method for displaying a status bar of an Android device provided by the present application is shown, and the method for displaying a status bar of an Android device includes:

[0056] Step 310: During the boot process, the Android device starts the status bar and the Android service process.

[0057] Step 320: The Android device controls the status bar to bind with the service process, and obtains the data to be displayed from the service process to complete the display of the status bar.

[0058] Although the display of function icons in the status bar requires obtaining relevant data (recorded as data to be displayed) from the application, not all data of the application is required. For example, for the car computer, in order to display the wireless charging icon, network icon and Bluetooth icon in the status bar, it is necessary to start the vehicle settings application to obtain the data to be displayed from the vehicle settings, that is, the wireless charging status data, network status data and Bluetooth status data, and present the corresponding three icons through these three status data. However, the startup of the application, no matter how the application is started, such as the user clicks to start or is pulled up by other applications, is limited to the application's inability to independently determine which functional modules need to be started, so the application cannot only start the relevant functional modules displayed in the status bar.

[0059] Therefore, the vehicle setting function cannot only start the function modules related to wireless charging, network and Bluetooth to load the corresponding wireless charging status data, network status data and Bluetooth status data, that is, all data corresponding to all modules of the vehicle setting will be loaded, and clear difference initialization cannot be achieved. For example, in addition to loading data of function modules such as wireless charging, network and Bluetooth, the vehicle setting function will also load data of function modules such as driving, lighting and network.

[0060] Therefore, in order to reduce the number of processes started at startup, the data to be displayed through the status bar, such as user account status data, battery status data, network status data, and Bluetooth status data, can be extracted from the relevant applications, and can be centrally run by the service process of the Android device, that is, the service process centrally obtains and loads: the data to be displayed generated by the hardware, such as Bluetooth status data, can be directly obtained by the server from the corresponding Bluetooth module hardware; the data to be displayed generated based on software logic interaction, such as account status data, can be determined by the service process after running the corresponding code based on the user's interaction. Therefore, this embodiment can realize the display of the status bar by decoupling only when the status bar and the service process are started.

[0061] Specifically, after both the status bar and the service process are started, in order for the status bar to obtain the data to be displayed and complete the display, the Android device can control the status bar to complete the binding with the service process, that is, establish a connection between the status bar and the service process, so that the two processes can transmit and access data through AIDL to achieve data sharing. After binding, the status bar can obtain the data to be displayed from the service process to complete the display, that is, based on the data to be displayed, the corresponding function icon is presented at the specified position of the status bar, thereby providing a convenient entry for users to operate related functions to improve the user experience.

[0062] For example, assuming that the Android device is a car computer, when the car computer displays the function icon in the status bar, a total of 8 applications need to be started, plus the process corresponding to the status bar, a total of 9 processes are created; but through the status bar display method of this embodiment, the car computer only needs to create two processes based on the status bar and the service. In comparison, a total of 7 process resources can be saved, thereby shortening the time required for startup and greatly improving the fluency of the Android system after startup.

[0063] In this embodiment, when completing the status bar display, the Android device only needs to start the status bar and run the service process of the data to be displayed, without starting all related applications. This can greatly reduce the number of processes started at startup, thereby reducing the system resource load, and on the basis of shortening the startup time, ensuring the smoothness of the system after the Android device is started.

[0064] In some embodiments, after displaying the status bar, the Android device may further perform the following steps:

[0065] Step A1: After the target application associated with the data to be displayed is started, the Android device controls the target application to bind with the service process to obtain the data to be displayed and display it in the application interface of the target application.

[0066] The relevant applications associated with the data to be displayed can be recorded as target applications. When the data to be displayed is centrally run through the service, in order to ensure data consistency, the data to be displayed in the target application can be deleted to avoid the service process and the target application both running the data to be displayed, which may lead to differences in the data to be displayed in the two applications in some cases and cause system conflicts.

[0067] Although deleting the data to be displayed in the target application can ensure data consistency and avoid system conflicts, the target application needs to obtain the data to be displayed after it is started to provide users with complete application functions. In order to achieve this goal, the Android device can be bound to the service process, that is, to establish a connection between the target application and the service process, so that the two processes can transfer and access data through AIDL to achieve data sharing. Accordingly, after the target application is bound to the service process, it can obtain the data to be displayed and display it in the application interface of the target application, thereby ensuring that the target application can still provide users with complete application functions after the corresponding data to be displayed is deleted.

[0068] In some embodiments, the data to be displayed includes at least two types of sub-data; in order to ensure the correct display of each function icon in the status bar, for each type of sub-data, the Android device can complete the display of the status bar through the following steps:

[0069] Step B1: The Android device controls the status bar to send the key value corresponding to the sub-data to the service process.

[0070] If the data corresponding to all function icons in the status bar are called data to be displayed, for example, user account status data, battery status data, and network status data are collectively referred to as data to be displayed, then the data corresponding to the user account icon, battery icon, and network icon can be called sub-data, that is, separate user account status data, separate battery status data, or separate network status data are all sub-data. Therefore, it can be considered that different function icons correspond to different sub-data in the data to be displayed.

[0071] In order to ensure that the implementation of this embodiment can save at least one process resource, the data to be displayed includes at least two sub-data, and each sub-data corresponds to a function icon in the status bar.

[0072] Based on this, in order to ensure that the function icons displayed in the status bar of the vehicle computer can accurately reflect the corresponding sub-data, data matching can be performed during the data acquisition process. Specifically, the service process can make protocol provisions for different sub-data. Any process that wants to obtain any sub-data in the service process must carry a specified key value (Key). Therefore, to obtain any sub-data in the status bar, the key value corresponding to the sub-data can be sent to the service process.

[0073] Exemplarily, in order to facilitate efficient acquisition of sub-data, the key value composition can be: module_subsystem_data_reserved. For example, the key value corresponding to the on / off state of the Bluetooth of the vehicle computer can be expressed as SETTINGS_Bluetooth_status_-1, which means that the state of Bluetooth under the vehicle settings is -1. -1 is a custom state, and there are two states of Bluetooth, namely on and off, so -1 can be set to on or off; if it is set to off, then SETTINGS_Bluetooth_status_1 can indicate that the state of Bluetooth under the vehicle settings is on.

[0074] If the status bar wants to obtain the switch status of Bluetooth, it can send the key value of SETTINGS_Bluetooth_status to the service process, and the reserved part is provided by the service process.

[0075] Step B2: The Android device controls the service process to receive and parse the key value.

[0076] Step B3: The Android device control service process returns corresponding sub-data to the status bar based on the parsed key value.

[0077] Accordingly, after receiving the key value, the service process can parse it to determine the sub-data to be obtained in the status bar. After determination, the service process can return the corresponding sub-data according to the key value, for example, SETTINGS_Bluetooth_status_-1 or SETTINGS_Bluetooth_status_1.

[0078] Step B4: The Android device controls the status bar to receive and display the sub-data.

[0079] Accordingly, after the status bar receives the sub-data, it can display the sub-data. For example, when SETTINGS_Bluetooth_status_-1 is received, when the Bluetooth icon is displayed, its switch button can be displayed as off.

[0080] In this embodiment, the service process and the application that wants to obtain sub-data, such as the status bar or the target application, can both obtain and feedback data through the key value corresponding to the sub-data, so as to ensure that the status bar can display the sub-data and the corresponding function icon in correspondence.

[0081] In some embodiments, the data to be displayed may change over time. For example, the current network status is not good, resulting in the Android device failing to connect to any wireless network. In order to ensure the accuracy of the WiFi connection status in the status bar and the target, the service process may synchronize the data to the status bar and the target application respectively after the data to be displayed is updated. To achieve this purpose, the Android device may also perform the following steps:

[0082] Step B1: The Android device controls the status bar and / or the target application to subscribe to a callback service from the service process to call back the data to be displayed.

[0083] Accordingly, after the status bar is displayed, the following steps are also included:

[0084] Step C1: After the data to be displayed is updated, the control service process sends the updated data to be displayed to the status bar and / or the target application, so that the status bar and / or the target application updates the display based on the updated data to be displayed.

[0085] In order to ensure that the status bar and the target application can obtain and display the updated data in time, the Android device can control the status bar and / or the target application to subscribe to the callback service of the service process. When the data to be displayed in the service process changes, the subscriber can be notified through the callback, so that the status bar and the target application can receive the updated data to be displayed in real time and display it synchronously. This mechanism can effectively improve the immediacy and synchronization of data updates and ensure the dynamic response of the user interface.

[0086] In some embodiments, after the status bar is displayed, the method further includes:

[0087] Step D1: The Android device controls the status bar to respond to the user's operation on the displayed target sub-data and generates a data request instruction.

[0088] The user may operate a certain function through the function icon of the status bar, which is equivalent to operating a certain displayed sub-data, and the operated sub-data can be recorded as the target sub-data. At this time, in order to respond to the user's operation, the status bar can generate a corresponding data request instruction to obtain the updated data corresponding to the operation of the target sub-data.

[0089] Step D2: The Android device controls the status bar to send a data request instruction to the service process.

[0090] For the generated data request instruction, the Android device can control the state to send it to the service process through AIDL for further processing by the service process.

[0091] Step D3: The Android device controls the service process to send the corresponding designated display data to the status bar based on the data request instruction, so that the status bar updates the display of the target sub-data based on the designated display data.

[0092] The service process obtains the data request instruction to parse the instruction, for example, obtains the key value of the target sub-data, and then sends the corresponding designated display data to the status bar based on the key value, so that the status bar displays the updated target sub-data, that is, the designated display data.

[0093] In this embodiment, when the user operates the function icon in the status bar, a corresponding data request instruction can be generated based on the operation to obtain the specified display data corresponding to the data request instruction from the service process. By receiving the specified display data, the target display data can be updated, thereby satisfying the user's demand for convenient setting of the display function through the status bar and improving the user experience.

[0094] Exemplarily, assuming that the user interacts with the WiFi icon in the status bar and switches the currently connected network, the status bar may generate a network switching request instruction based on the network switching operation. Exemplarily, the instruction may include the currently connected network A and the network B to be connected (for the sake of simplicity of description, it is assumed that network B is a network that has already been connected and there is no need to verify the password again); thus, the service process may obtain the corresponding specified display data, that is, the currently connected network B, from the WiFi module hardware according to the network switching request instruction, and feed the specified display data back to the status bar, so that the status bar can update the display of the WiFi icon, display the currently connected network as network B, and display network A as a connectable network. In this way, real-time update of WiFi status data can be completed, thereby satisfying the user's need to conveniently set up the network through the WiFi icon in the status bar to improve the user experience.

[0095] In some embodiments, if the Android device is a car computer, step B3 specifically includes:

[0096] Step B31, the Android device control service process transmits a request for obtaining sub-data to the vehicle hardware through the vehicle system based on the parsed key value, and receives the sub-data returned by the vehicle hardware through the vehicle system.

[0097] Different sub-data can be generated by the corresponding vehicle hardware. In this case, after the service process obtains the parsed key value, it can transmit the corresponding sub-data acquisition request based on the link of service process-vehicle system-vehicle hardware; accordingly, when the vehicle hardware feeds back the sub-data, the sub-data is transferred based on the link of vehicle hardware-vehicle system-service process, that is, the service process sends the sub-data acquisition request and receives the sub-data through two links, and finally feeds back the sub-data corresponding to the received parsed key value to the status bar. Of course, if the target application obtains the data, the service process also feeds back the corresponding sub-data to the target application based on this process.

[0098] For example, see Figure 4 , Figure 4 A schematic diagram showing the interaction between the status bar / target application and the service process is shown.

[0099] After the status bar is bound to a service process or any function icon displayed is operated by the user, the status bar can send the key value of all / part of the sub-data to the service process according to the display requirements / operation instructions to obtain the corresponding sub-data; the service process obtains the corresponding sub-data through two links to feedback to the status bar. After receiving the corresponding sub-data, the status bar can complete the display or update the display.

[0100] The process of the target application actively requesting data is similar and will not be described here.

[0101] After the data is updated, for example, after the vehicle hardware is operated or set by other applications, updated sub-data appears. At this time, the vehicle hardware can feedback to the service process through the link of hardware-vehicle system-service process to receive the updated sub-data. In order to be able to promptly notify the status bar and target application subscribed to the sub-data callback service, the service process can find the corresponding application from the application subscribed to the data callback service based on the updated sub-data, and then send the updated sub-data to the corresponding application to improve the timeliness and accuracy of the data display of the corresponding application.

[0102] In combination with the above embodiments, it can be known that the present application has the following beneficial effects compared with the prior art: the data to be displayed that is centrally displayed in the status bar is deleted from the associated target application, and the data to be displayed is run through the Android service process. Therefore, after the status bar and the service process are started, the status bar can be bound to the service process, and then the data to be displayed is obtained from the service process to complete the display. In this way, the number of processes started during the boot process can be reduced, the system resource load can be reduced, and the smoothness of the system after the Android device is started can be guaranteed on the basis of shortening the boot time. After the target application is started, the service process can be bound to obtain the data to be displayed to ensure the consistency of the data to be displayed. Both the status bar and the target application can subscribe to the callback service to the service process, so that the status bar and the target application can update the display content in real time after the data to be displayed is updated, thereby ensuring the timeliness of the displayed content.

[0103] It should be understood that the size of the serial numbers of the steps in the above embodiments does not mean the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present application.

[0104] Corresponding to the display method of the status bar of the Android device in the above embodiment, Figure 5 A structural block diagram of a display device 5 for a status bar of an Android device provided in an embodiment of the present application is shown. For ease of explanation, only the parts related to the embodiment of the present application are shown.

[0105] Reference Figure 5 , the display device 5 of the status bar of the Android device includes:

[0106] The startup module 51 is used to start the status bar and the Android service process during the startup of the Android device;

[0107] The first display module 52 is used to control the binding of the status bar with the service process, and obtain the data to be displayed from the service process to complete the display of the status bar.

[0108] Optionally, the display device 5 further includes:

[0109] The second display module is used to control the target application to bind with the service process after the status bar is displayed and the target application associated with the data to be displayed is started, so as to obtain the data to be displayed and display it in the application interface of the target application.

[0110] Optionally, the display device 5 further includes:

[0111] A subscription module, used to control the status bar and / or the target application to subscribe to the callback service of the service process after the status bar is bound to the service process, so as to call back the data to be displayed;

[0112] The synchronization module is used to control the service process to send the updated data to be displayed to the status bar and / or the target application after the status bar is displayed and the data to be displayed is updated, so that the status bar and / or the target application update the display based on the updated data to be displayed.

[0113] Optionally, the data to be displayed includes at least two types of sub-data; and the display module is used for:

[0114] For each type of subdata:

[0115] Control the status bar to send the key value corresponding to the sub-data to the service process;

[0116] Control the service process to receive and parse the key value;

[0117] The control service process returns the corresponding sub-data to the service process based on the parsed key value;

[0118] Control the status bar to receive and display sub data.

[0119] Optionally, the display device 5 further includes an interaction module, which is used to:

[0120] The control status bar generates a data request instruction in response to the user's operation on the displayed target sub-data; the target sub-data is any sub-data being operated;

[0121] The control status bar sends data request instructions to the service process;

[0122] The control service process sends the corresponding designated display data to the status bar based on the data request instruction, so that the status bar updates the display of the target sub-data based on the designated display data.

[0123] Optionally, the Android device is a vehicle computer, and the display module is specifically used for:

[0124] The control service process transmits a request to obtain sub-data to the vehicle hardware through the vehicle system based on the parsed key value, and receives the sub-data returned by the vehicle hardware through the vehicle system to send the sub-data to the status bar.

[0125] It should be noted that the information interaction and execution process between the above-mentioned devices / units are based on the same concept as the method embodiment of the present application. Their specific functions and technical effects can be found in the method embodiment part and will not be repeated here.

[0126] Figure 6 This is a schematic diagram of the physical structure of a vehicle provided in one embodiment of the present application. Figure 6 As shown, the vehicle 6 of this embodiment is equipped with an Android device 60, and the Android device 60 includes at least one processor 61 ( Figure 6 Only one processor is shown), a memory 62, and a computer program 63 stored in the memory 62 and executable on at least one processor 61. When the processor 61 executes the computer program 63, the steps in the above-mentioned method for identifying a button of any Android device are implemented, for example Figure 3 Steps 310-320 are shown.

[0127] The processor 61 may be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field-programmable gate arrays (FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor may be a microprocessor or any conventional processor, etc.

[0128] In some embodiments, the memory 62 may be an internal storage unit of the Android device 60, such as a hard disk or memory of the Android device 60. In other embodiments, the memory 62 may also be an external storage device of the Android device 60, such as a plug-in hard disk, a smart memory card (Smart Media Card, SMC), a secure digital (Secure Digital, SD) card, a flash card (Flash Card), etc. equipped on the Android device 60.

[0129] Furthermore, the memory 62 may include both an internal storage unit of the Android device 60 and an external storage device. The memory 62 is used to store operating devices, applications, boot loaders, data, and other programs, such as program codes of computer programs, etc. The memory 62 may also be used to temporarily store data that has been output or is to be output.

[0130] The technicians in the relevant field can clearly understand that for the convenience and simplicity of description, only the division of the above-mentioned functional units and modules is used as an example for illustration. In practical applications, the above-mentioned function allocation can be completed by different functional units and modules as needed, that is, the internal structure of the above-mentioned device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiment can be integrated in a processing unit, or each unit can exist physically separately, or two or more units can be integrated in one unit. The above-mentioned integrated unit can be implemented in the form of hardware or in the form of software functional units. In addition, the specific names of the functional units and modules are only for the convenience of distinguishing each other, and are not used to limit the scope of protection of this application. The specific working process of the units and modules in the above-mentioned system can refer to the corresponding process in the aforementioned method embodiment, which will not be repeated here.

[0131] An embodiment of the present application further provides a computer-readable storage medium, which stores a computer program. When the computer program is executed by a processor, the steps in the above-mentioned method embodiments can be implemented.

[0132] An embodiment of the present application provides a computer program product. When the computer program product is run on a vehicle, the vehicle can implement the steps in the above-mentioned method embodiments when the computer program product is executed.

[0133] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the present application implements all or part of the processes in the above-mentioned embodiment method, which can be completed by instructing the relevant hardware through a computer program. The above-mentioned computer program can be stored in a computer-readable storage medium, and the computer program can implement the steps of the above-mentioned various method embodiments when executed by the processor. Among them, the above-mentioned computer program includes computer program code, and the above-mentioned computer program code can be in source code form, object code form, executable file or some intermediate form. The above-mentioned computer-readable medium may at least include: any entity or device that can carry the computer program code to the camera / vehicle, a recording medium, a computer memory, a read-only memory (ROM, Read-Only Memory), a random access memory (RAM, Random Access Memory), an electrical carrier signal, a telecommunication signal, and a software distribution medium. For example, a USB flash drive, a mobile hard disk, a disk or an optical disk.

[0134] In the above embodiments, the description of each embodiment has its own emphasis. For parts that are not described or recorded in detail in a certain embodiment, reference can be made to the relevant descriptions of other embodiments.

[0135] Those of ordinary skill in the art will appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of this application.

[0136] In the embodiments provided in the present application, it should be understood that the disclosed devices / network equipment and methods can be implemented in other ways. For example, the device / network equipment embodiments described above are merely schematic. For example, the division of the above modules or units is only a logical function division. There may be other division methods in actual implementation, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0137] The units described above as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0138] The above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit them. Although the present application has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. These modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the embodiments of the present application, and should all be included in the protection scope of the present application.

Claims

1. A method for displaying a status bar of an Android device, characterized in that: include: During the boot process of the Android device, start the status bar and the Android service process; The status bar is controlled to be bound to the service process, and the data to be displayed is obtained from the service process to complete the display of the status bar.

2. The display method according to claim 1, characterized in that: After the display of the status bar is completed, the method further includes: After the target application associated with the data to be displayed is started, the target application is controlled to bind with the service process to obtain the data to be displayed and display it in the application interface of the target application.

3. The display method according to claim 2, characterized in that: After the status bar is bound to the service process, the method further includes: Controlling the status bar and / or the target application to subscribe to a callback service from the service process to call back the data to be displayed; Accordingly, after the display of the status bar is completed, the method further includes: After the data to be displayed is updated, the service process is controlled to send the updated data to be displayed to the status bar and / or the target application, so that the status bar and / or the target application update the display based on the updated data to be displayed.

4. The display method according to claim 1 or 2, characterized in that: The data to be displayed includes at least two types of sub-data; and the display of the status bar is completed, including: For each type of subdata: Controlling the status bar to send the key value corresponding to the sub-data to the service process; Controlling the service process to receive and parse the key value; Controlling the service process to return corresponding sub-data to the status bar based on the parsed key value; The status bar is controlled to receive and display the sub-data.

5. The display method according to claim 4, characterized in that: After the display of the status bar is completed, the method further includes: Controlling the status bar to respond to the user's operation on the displayed target sub-data and generate a data request instruction; the target sub-data is any sub-data being operated; Controlling the status bar to send the data request instruction to the service process; The service process is controlled to send corresponding designated display data to the status bar based on the data request instruction, so that the status bar updates the display of the target sub-data based on the designated display data.

6. The display method according to claim 4, characterized in that: The Android device is a vehicle computer, and the controlling the service process to return corresponding sub-data to the status bar based on the parsed key value includes: The service process is controlled to transmit a request for obtaining the sub-data to the vehicle hardware through the vehicle system based on the parsed key value, and receive the sub-data returned by the vehicle hardware to the status bar through the vehicle system.

7. A display device for a status bar of an Android device, characterized in that: include: The startup module is used to start the status bar and the Android service process during the startup of the Android device; The first display module is used to control the status bar to be bound to the service process, and obtain the data to be displayed from the service process to complete the display of the status bar.

8. A vehicle, wherein the vehicle is equipped with an Android device, wherein the Android device comprises a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein: When the processor executes the computer program, the method for displaying the status bar of an Android device as described in any one of claims 1 to 7 is implemented.

9. A computer program product, comprising a computer program, characterized in that When the computer program is executed by one or more processors, the method for displaying the status bar of an Android device as described in any one of claims 1 to 7 is implemented.

10. A computer-readable storage medium storing a computer program, characterized in that: When the computer program is executed by a processor, the method for displaying the status bar of an Android device as described in any one of claims 1 to 7 is implemented.

Images