Method for realizing status bar and navigation bar under multiple screens and related equipment

Abstract

The invention discloses a method for realizing a status bar and a navigation bar under multiple screens and related equipment, relates to the technical field of vehicle-mounted electronics, and mainly aims to solve the problem that a traditional Android system cannot generate an independent status bar and an independent navigation bar under a vehicle-mounted multi-screen environment. The method comprises the steps that screen basic information is obtained based on a display management service, and the screen basic information comprises the number of screens and screen configuration information; creating a status bar frame and a navigation bar frame for each screen in a system bar creation function of a SystemU I module based on the screen basic information; and configuring interface contents for the status bar frame and the frame navigation bar frame of each screen.

Description

Technical Field

[0001] The present invention relates to the field of vehicle-mounted electronic technology, and in particular to a method for implementing a status bar and a navigation bar under multiple screens and related equipment. Background Art

[0002] With the development of smart cockpit technology, modern cars are generally equipped with multiple displays, such as the central control screen, instrument panel, and passenger entertainment screen, to achieve zoned interaction and an immersive experience. However, the underlying Android system is natively designed for single-screen devices, and its SystemUI service cannot independently create and manage status and navigation bars for multiple physical screens.

[0003] The current industry solution mainly simulates the system bar by directly adding a system window at the application layer. However, this method has poor compatibility, high maintenance costs, and significant defects. It cannot yet resolve the contradictions between system compatibility, dynamic scalability, and multi-screen adaptability. Summary of the Invention

[0004] In view of the above problems, the present invention provides a method for implementing a status bar and a navigation bar under multiple screens and related equipment, the main purpose of which is to solve the problem that the traditional Android system cannot generate independent status bars and navigation bars in a multi-screen environment in a vehicle.

[0005] To solve at least one of the above technical problems, in a first aspect, the present invention provides a method for implementing a status bar and a navigation bar under multiple screens, the method comprising:

[0006] Acquiring basic screen information based on a display management service, wherein the basic screen information includes the number of screens and screen configuration information;

[0007] Based on the basic screen information, a status bar frame and a navigation bar frame are created for each screen in the system bar creation function of the SystemUI module;

[0008] Configure the interface content for the status bar frame and navigation bar frame of each screen.

[0009] Optionally, obtaining basic screen information based on a display management service includes:

[0010] Define SystemUI module based on overlay;

[0011] The SystemUI module is started to obtain the basic screen information through the display management service.

[0012] Optionally, configuring interface content for the status bar and navigation bar frame of each screen includes:

[0013] A context object is created for each screen based on the screen configuration information, wherein the context object represents an independent operating environment of the screen in the system.

[0014] Optionally, configuring interface content for the status bar frame and the frame navigation bar frame of each screen includes:

[0015] The class loader object of the plug-in application where the status bar and navigation bar of each screen are located is obtained through the context object of each screen.

[0016] Optionally, configuring interface content for the status bar frame and the frame navigation bar frame of each screen includes:

[0017] Based on the class loader object of each screen, the plug-in application code corresponding to each screen is loaded through the reflection mechanism;

[0018] The specific implementation content of the respective status bar and navigation bar is obtained through the plug-in application code corresponding to each screen, wherein the specific implementation content is a view class object.

[0019] Optionally, configuring interface content for the status bar frame and the frame navigation bar frame of each screen includes:

[0020] The specific implementation content of the status bar and navigation bar of each screen is placed into the status bar frame and the navigation bar frame.

[0021] Optionally, the method further includes:

[0022] Predefine resource files suitable for different screen resolutions and pixel densities within the plug-in application;

[0023] When the specific implementation contents of the status bar and the navigation bar of each screen are placed into the status bar frame and the navigation bar frame, the target resource file is automatically selected based on the basic screen information.

[0024] In a second aspect, an embodiment of the present invention further provides a device for implementing a status bar and a navigation bar under multiple screens, including:

[0025] an acquiring unit, configured to acquire basic screen information based on a display management service, wherein the basic screen information includes the number of screens and screen configuration information;

[0026] A creation unit, configured to create a status bar frame and a navigation bar frame for each screen in a system bar creation function of a SystemUI module based on the basic screen information;

[0027] Configuration unit, used to configure the interface content for the status bar frame and frame navigation bar frame of each screen.

[0028] In order to achieve the above-mentioned purpose, according to the third aspect of the present invention, a computer-readable storage medium is provided, which includes a stored program, wherein when the above-mentioned program is executed by the processor, the steps of the above-mentioned method for implementing the status bar and navigation bar under multiple screens are implemented.

[0029] In order to achieve the above-mentioned purpose, according to the fourth aspect of the present invention, an electronic device is provided, comprising at least one processor and at least one memory connected to the processor; wherein the above-mentioned processor is used to call the program instructions in the above-mentioned memory to execute the steps of the above-mentioned method for implementing the status bar and navigation bar under multiple screens.

[0030] By means of the above technical solution, the present invention provides a method for implementing the status bar and navigation bar under multiple screens and related equipment. To solve the problem that the traditional Android system cannot generate an independent status bar and navigation bar in a multi-screen environment in a vehicle, the present invention obtains basic screen information based on the display management service, wherein the basic screen information includes the number of screens and screen configuration information; based on the basic screen information, a status bar frame and a navigation bar frame are created for each screen in the system bar creation function of the SystemUI module; and the interface content is configured for the status bar frame and the frame navigation bar frame of each screen. In the above solution, the SystemUI module is overwritten by the Android Overlay mechanism to establish a customized foundation for the multi-screen status bar and navigation bar. Based on the device screen configuration, an independent status bar and navigation bar instance is created for each screen in the customized SystemUI. Through the plug-in mechanism, the corresponding customized interface content is dynamically loaded and adapted for the status bar and navigation bar frame of each screen. The matching relationship between hardware information and software framework is coordinated by the service to achieve on-demand generation of multi-screen system bars and content decoupling. Therefore, by dynamically generating the framework driven by hardware information, the intrusiveness of multi-screen adaptation to the system source code is reduced; through the separation design of the framework and content, the coupling between interface customization and system stability is reduced, so that the system bars on different screens can respond to changes in hardware characteristics and independently update content without affecting the core services of the system.

[0031] Correspondingly, the implementation device, equipment and computer-readable storage medium for the multi-screen status bar and navigation bar provided by the embodiments of the present invention also have the above-mentioned technical effects.

[0032] The above description is only an overview of the technical solution of the present invention. In order to more clearly understand the technical means of the present invention, it can be implemented in accordance with the contents of the specification. In order to make the above and other purposes, features and advantages of the present invention more obvious and easy to understand, the specific implementation methods of the present invention are specifically listed below. BRIEF DESCRIPTION OF THE DRAWINGS

[0033] Various other advantages and benefits will become apparent to those skilled in the art upon reading the detailed description of the preferred embodiment below. The accompanying drawings are for illustration purposes only and are not to be considered as limiting the present invention. The same reference symbols are used throughout the drawings to represent the same components. In the drawings:

[0034] Figure 1 A schematic diagram illustrating a flow chart of a method for implementing a status bar and navigation bar under multiple screens provided by an embodiment of the present invention;

[0035] Figure 2 A schematic block diagram showing the composition of a device for implementing a status bar and navigation bar under multiple screens provided by an embodiment of the present invention is shown;

[0036] Figure 3 A schematic block diagram of the composition of an electronic device implementing a multi-screen status bar and navigation bar provided by an embodiment of the present invention is shown. DETAILED DESCRIPTION

[0037] Exemplary embodiments of the present invention will be described in more detail below with reference to the accompanying drawings. Although exemplary embodiments of the present invention are shown in the accompanying drawings, it should be understood that the present invention can be implemented in various forms and should not be limited by the embodiments set forth herein. Rather, these embodiments are provided to enable a more thorough understanding of the present invention and to fully convey the scope of the present invention to those skilled in the art.

[0038] In order to solve the problem that the traditional Android system cannot generate independent status bar and navigation bar in a multi-screen environment, the embodiment of the present invention provides a method for realizing the status bar and navigation bar under multiple screens, such as Figure 1 As shown, the method includes:

[0039] S101. Acquire basic screen information based on a display management service, wherein the basic screen information includes the number of screens and screen configuration information;

[0040] In one embodiment, obtaining basic screen information based on a display management service includes:

[0041] Define SystemUI module based on overlay;

[0042] The SystemUI module is started to obtain the basic screen information through the display management service.

[0043] Exemplarily, this application utilizes the layered customization mechanism of the Android system to achieve secure access to multi-screen information. The above-mentioned overlay layer refers to the resource and code overlay technology (Overlay mechanism) natively supported by Android, which can redefine specific system functions by superimposing customized modules on the system layer without directly modifying the Android Open Source Project (AOSP) core source code. Defining a SystemUI module means creating a customized system interface service module through the overlay technology, which inherits the basic capabilities of the native SystemUI (such as system bar management), but adds extended support logic for multi-screen scenarios.

[0044] When this customized SystemUI module is launched, the system activates its integrated multi-screen adaptation logic. At this point, the "Display Management Service," or Android's underlying DisplayManager service, acts as a system-level hardware information hub and provides the module with real-time basic screen information, including the number of all currently connected physical screens, such as the center console, instrument panel, and other independent display units, as well as detailed configuration parameters for each screen, such as resolution, physical size, and orientation.

[0045] The customization capabilities granted by the overlay enable the SystemUI module to proactively call the display management service during initialization, obtaining multi-screen hardware information through a secure system-level interface, thereby reducing the compatibility risks associated with traditional solutions that directly access the hardware driver layer. This reduces the intrusiveness of multi-screen adaptation to the system source code: As an officially supported customization path for Android, the overlay ensures the stability of system services. Furthermore, the dynamic acquisition of screen information provides an accurate hardware basis for the subsequent on-demand creation of the system bar framework, decoupling multi-screen expansion capabilities from core system services and providing underlying support for flexible changes to screen configurations, such as adding or replacing new screens in automotive scenarios.

[0046] S102: creating a status bar frame and a navigation bar frame for each screen in a system bar creation function of a SystemUI module based on the basic screen information;

[0047] Exemplarily, this application dynamically constructs multiple independent system bar container architectures based on hardware display characteristics. Basic screen information refers to the set of physical screen metadata provided by the display management service, which includes two key dimensions: one is the number of screens, that is, the total number of independent display units activated by the current system, such as the main driver's instrument screen, central control screen, co-driver's entertainment screen and other entities; the other is screen configuration information, covering the physical properties of each screen, such as pixel density, visible area size, orientation status, etc. This information together constitutes the physical benchmark of the multi-screen system architecture. The SystemUI module is the core service component for managing the status bar and navigation bar of the Android system. Its built-in system bar creation function is a system-level view construction entry point, which is natively designed to generate a unique system bar instance in a single-screen environment. This solution extends the function logic to execute a loop creation process based on the screen quantity parameter: every time a valid screen identifier is detected, a pair of exclusive status bar frames and navigation bar frames are generated based on the configuration information of the screen. The "framework" here refers to an abstract container structure with preset standardized interaction protocols and size constraints. For example, it creates a vertical layout container for portrait-oriented devices and a horizontal stretch container for landscape-oriented wide screens. The framework reserves a content mounting interface but does not yet bind specific visual elements. Its core value lies in establishing a UI skeleton that strictly matches the physical characteristics of the screen.

[0048] This solution reduces the architectural coupling of multi-screen system bars: by dynamically generating the framework driven by basic screen information, it reduces the scalability limitations caused by hard-coded layouts for a fixed number of screens in traditional solutions. At the same time, the automatic matching mechanism between the framework and screen configuration, such as dynamically calculating control spacing based on resolution, reduces the risk of layout misalignment caused by differences in screen parameters, providing compatibility guarantees for the subsequent injection of differentiated content.

[0049] S103: Configure interface content for the status bar frame and the frame navigation bar frame of each screen.

[0050] This technical solution leverages the service's coordination of hardware information and software frameworks, enabling on-demand generation of multi-screen system bars and decoupling them from content. Specifically, the display management service, acting as a hub connecting hardware display devices with the system software layer, continuously monitors the real-time status of all screens.

[0051] Based on the basic screen information obtained in real time, the system performs dynamic framework construction in the system bar creation function of the SystemUI module, which is the core code unit of Android responsible for generating the status bar and navigation bar. This function determines the total number of system bar instances to be created based on the number of screens, and generates a matching status bar frame and navigation bar frame for each screen's configuration information. The "framework" here refers to the standardized container structure preset by the system. In essence, it is a UI skeleton that reserves size, position and basic interaction logic but has not yet been filled with specific content. It provides a mounting point compatible with different screens for subsequent customization.

[0052] Finally, the configuration interface content, independent of the core system's customizable elements such as icons, controls, and layout logic, is injected into the aforementioned framework. By matching the corresponding interface resources and behavioral logic to each screen's framework, for example, configuring a compact layout for the portrait-screen center console status bar and media control buttons for the landscape-screen passenger navigation bar, this preserves the basic functional consistency of the system bar while allowing for visual and interactive customization based on screen roles. The core value of this process lies in: dynamically generating the framework through hardware information reduces the intrusiveness of multi-screen adaptation to the system source code; and by separating the framework from the content, it reduces the coupling between interface customization and system stability, allowing system bars on different screens to respond to hardware feature changes and independently update content without affecting core system services.

[0053] In one embodiment, configuring interface content for the status bar and navigation bar frame of each screen includes:

[0054] A context object is created for each screen based on the screen configuration information, wherein the context object represents an independent operating environment of the screen in the system.

[0055] Exemplarily, the context object represents the independent operating environment of a screen within the system, establishing an isolated software execution sandbox for each physical display unit in a multi-screen system. Screen configuration information refers to a set of parameters specific to a single screen, provided by the display management service. These parameters include key metadata that determines display characteristics, such as pixel density, physical dimensions, orientation, and a unique identifier. Based on these hardware characteristics, a context object is dynamically constructed as a software entity that encapsulates the specific screen's operating environment. While inheriting the basic properties of the system's global context (such as application package permissions and theme settings), it also incorporates screen-specific resource configuration rules (such as rendering logic that automatically scales icon size based on pixel density), theme adaptation policies (such as layout constraints for switching between landscape and portrait modes), and resource search paths pointing to the storage locations of icons and layout files specific to that screen. This object serves as the sole software proxy for the screen's environment, ensuring that any operations executed within this context automatically inherit the physical constraints of the screen, such as loading a horizontally stretched navigation bar on the passenger-side long screen or enabling a circular status bar layout on a circular instrument panel.

[0056] The above technical solution significantly reduces the complexity of multi-screen resource management: by binding the screen's physical properties and environmental configuration to independent context objects, the code redundancy caused by frequent manual parameter adjustments in traditional solutions is reduced; at the same time, the context isolation mechanism blocks resource identification conflicts between different screens, such as the same-name resource files for the central control screen and the instrument screen, reducing the risk of rendering anomalies caused by environmental confusion, and providing a stable environment container for subsequent on-demand loading of screen-specific content.

[0057] In one embodiment, configuring interface content for the status bar frame and the frame navigation bar frame of each screen includes:

[0058] The class loader object of the plug-in application where the status bar and navigation bar of each screen are located is obtained through the context object of each screen.

[0059] Exemplarily, this application utilizes a screen-specific operating environment to securely load differentiated plug-in components. The context object of the above screen is bound to the hardware properties of the screen (such as pixel density, orientation) and resource rules (such as icon scaling logic, layout constraints), ensuring that the code running inside it automatically adapts to the physical characteristics of the corresponding screen. A plug-in application refers to an installable software package that is independent of the system's core services and contains customized status bar and navigation bar implementation logic (such as specific icons, interactive controls), which provides extended functionality through predefined interfaces. The class loader object serves as the core mechanism for loading code in the Android virtual machine. It is responsible for reading compiled class files, such as custom status bar control classes, from the installation package of the plug-in application and converting them into memory code structures that can be executed within the virtual machine.

[0060] This application calls the system resource manager through the context object of each screen, locates the specific plug-in application installation path bound to the screen, and then generates an exclusive class loader strictly associated with the context. This loader will automatically inherit the screen adaptation rules in the context when parsing the plug-in class file. For example, when loading the ring menu class under the context of the circular instrument screen, the arc layout algorithm is automatically applied. At the same time, the class loading process between different screens is strictly isolated to avoid the main driver's instrument screen plug-in code from being mistakenly loaded into the co-driver's entertainment screen.

[0061] The above technical solution reduces the risk of resource conflicts in the multi-screen plug-in architecture: the context-bound class loading mechanism blocks the global pollution of plug-in resource identifiers, such as class definition conflicts of controls with the same name on different screens; at the same time, the environment self-adaptation feature reduces the complexity of developers manually injecting hardware parameters for each screen, so that the same set of plug-in code can automatically generate behavioral logic that conforms to the screen characteristics in different context environments, laying the foundation for providing secure code for the subsequent dynamic construction of differentiated system bars.

[0062] In one embodiment, configuring interface content for the status bar frame and the frame navigation bar frame of each screen includes:

[0063] Based on the class loader object of each screen, the plug-in application code corresponding to each screen is loaded through the reflection mechanism;

[0064] The specific implementation content of the respective status bar and navigation bar is obtained through the plug-in application code corresponding to each screen, wherein the specific implementation content is a view class object.

[0065] Exemplarily, this application uses runtime dynamic binding technology to safely instantiate differentiated system bar interface elements for each screen. Among them, the class loader object is a code loading tool associated with a specific screen operating environment, namely the context object, which has bound the hardware adaptation rules of the screen (such as pixel density scaling factor) and resource search path; the reflection mechanism is a programming paradigm that dynamically parses and operates the code structure during program execution. It does not require static compilation of dependencies in advance, and can locate and activate the target code through string identifiers such as class names and method names; the plug-in application code refers to the compiled program logic stored in an independent installation package, including implementation classes such as view drawing and event response of the custom status bar and navigation bar; the view class object specifically refers to the base class instance used to describe interface elements in the Android system, such as View and its subclasses, which carry specific control trees, layout parameters and rendering behaviors.

[0066] This application is based on the class loader of each screen scanning the corresponding plug-in application package, identifying and loading the preset entry class definition through the reflection mechanism, such as the fully qualified name of the status bar implementation class, and converting the binary bytecode into a memory structure executable by the virtual machine. In this process, the screen environment parameters carried by the class loader are automatically injected into the class initialization link, such as loading high-resolution icon resources for high-pixel density screens. Subsequently, the factory method or constructor in the plug-in code is called through reflection to generate specific implementation content that strictly matches the hardware characteristics of the screen, that is, the instantiated view class object.

[0067] For example, in a circular instrument panel, this object might be a circular status bar control group with a pre-configured arc calculation algorithm for its drawing logic. In a horizontal center console, this might generate a horizontally arranged navigation bar button group with a built-in touch area expansion strategy. These view objects are deeply integrated with screen adaptation rules during creation, forming self-contained display logic units.

[0068] The above technical solution significantly reduces the version maintenance cost of multi-screen customized development: the runtime loading mechanism implemented by reflection eliminates the need to recompile the system core services when adding new screen types or modifying interface styles; the environment self-adaptation feature of the view class object reduces the complexity of developers manually handling screen parameter differences, ensuring that the same set of plug-in code automatically generates an interactive interface that conforms to physical constraints in different screen contexts, providing a standardized visual carrier for subsequent integration into the system bar framework.

[0069] In one embodiment, configuring interface content for the status bar frame and the frame navigation bar frame of each screen includes:

[0070] The specific implementation content of the status bar and navigation bar of each screen is placed into the status bar frame and the navigation bar frame.

[0071] Exemplarily, the above-mentioned specific implementation content refers to the dynamically generated view class objects, which carry the control tree structure of customized interface elements, such as the battery icon control group in the status bar, the return key touch area in the navigation bar, etc. These objects have deeply integrated the hardware adaptation rules of the corresponding screen (such as the drawing logic that automatically scales according to the pixel density) and interactive behaviors (such as the media control gestures of the co-pilot screen navigation bar); the status bar frame and the navigation bar frame are standardized containers pre-built in SystemUI based on the screen configuration information, which have preset size constraints (such as a fixed ratio of height to the top of the screen), layout mounting points (such as the coordinates of the status bar icon arrangement area) and event transmission pipelines (such as the link for transmitting touch events from the framework to specific controls).

[0072] This application injects view class objects as dynamic subcomponents into the frame container of the corresponding screen: for example, the horizontal media control navigation bar view object of the passenger screen is associated with the layout node of the passenger screen navigation bar frame through the hierarchical mounting interface of the view system, so that the size and position of the former automatically adapt to the horizontal screen stretching rules preset by the frame; at the same time, the event distribution logic embedded in the frame (such as clicks and slides) will be bound to the event listener of the view object to form a complete interactive link. This process triggers the re-measurement and re-drawing of the view tree to ensure that the customized content fits the physical boundaries of the frame, such as the arc-shaped controls of the circular instrument panel status bar strictly match the curvature of the ring frame.

[0073] The above technical solution reduces the complexity of interface integration of multi-screen system bars: the framework provides a standardized physical and interactive baseline, so that customized views of different screens do not need to repeatedly implement layout constraint logic; the decoupling design of the view and the framework reduces the maintenance cost of interface upgrades. For example, when modifying the navigation bar icon on the passenger screen, you only need to update the plug-in view object without touching the framework code.

[0074] In one embodiment, the method further comprises:

[0075] Predefine resource files suitable for different screen resolutions and pixel densities within the plug-in application;

[0076] When the specific implementation contents of the status bar and the navigation bar of each screen are placed into the status bar frame and the navigation bar frame, the target resource file is automatically selected based on the basic screen information.

[0077] For example, a plug-in application refers to an independent software package that carries the implementation logic of a customized status bar or navigation bar; resource files contain different versions of visual elements such as layout definitions, icon bitmaps, and size values. These files are implicitly associated with screen parameters through preset directory naming rules (such as a high-pixel density dedicated directory to store fine icons); basic screen information specifically refers to a metadata set that includes core display properties such as resolution (total number of screen pixels) and pixel density (pixel distribution density per unit physical size).

[0078] This application stipulates that developers create multiple sets of differentiated resource files for the same visual element within the plug-in application, such as providing fine icon bitmaps for ultra-high-density screens and simplified vector graphics for low-resolution screens, and store them in accordance with the naming conventions of the system resource manager. When the system injects the view class object into the framework container, such as the specific implementation content described above, the Android resource system automatically activates the resource selection engine based on the basic information of the current screen: the engine parses the resource identifier referenced by the view object, such as the icon name, and dynamically selects the best match from the multi-version resource pool of the plug-in application based on the screen resolution and pixel density parameters. For example, in the small high-density instrument screen scenario, streamlined layout files and small-size high-precision icons are automatically loaded, and in the large low-density central control screen scenario, wide layouts and large-size anti-aliased icons are selected. The entire process does not require the view object to perceive hardware differences.

[0079] The above technical solution reduces the visual maintenance burden of multi-screen system bars: the automatic mapping mechanism of resource versions and screen parameters avoids the complexity of developers manually writing conditional branch code; the design of view objects and framework containers only referencing abstract resource identifiers reduces the compatibility risks caused by resource changes. For example, when replacing an icon set, only the plug-in resource file needs to be updated without modifying the core code, ensuring that the same set of view logic automatically presents ergonomic visual effects in different display environments.

[0080] Furthermore, as a response to the above Figure 1 In addition to the implementation of the method shown in the figure, the embodiment of the present invention also provides a device for implementing the status bar and navigation bar under multiple screens, which is used to implement the above Figure 1 This device embodiment corresponds to the aforementioned method embodiment. For ease of reading, this device embodiment will not describe the details of the aforementioned method embodiment one by one, but it should be clear that the device in this embodiment can implement all the contents of the aforementioned method embodiment. Figure 2 As shown, the device includes: an acquisition unit 21, a creation unit 22 and a configuration unit 23, wherein

[0081] An acquiring unit 21 is configured to acquire basic screen information based on a display management service, wherein the basic screen information includes the number of screens and screen configuration information;

[0082] A creating unit 22 is configured to create a status bar frame and a navigation bar frame for each screen in a system bar creation function of a SystemUI module based on the screen basic information;

[0083] The configuration unit 23 is used to configure interface content for the status bar frame and the frame navigation bar frame of each screen.

[0084] The processor includes a kernel, which retrieves corresponding program units from memory. One or more kernels can be configured, and kernel parameters are adjusted to implement a method for creating a status bar and navigation bar on multiple screens. This method addresses the issue of traditional Android systems being unable to generate independent status bars and navigation bars in a multi-screen vehicle environment.

[0085] An embodiment of the present invention provides a computer-readable storage medium, which includes a stored program. When the program is executed by a processor, it implements the method for implementing the status bar and navigation bar under multiple screens.

[0086] An embodiment of the present invention provides a processor, which is used to run a program, wherein the program executes the method for implementing the status bar and navigation bar under multiple screens when running.

[0087] An embodiment of the present invention provides an electronic device, comprising at least one processor and at least one memory connected to the processor; wherein the processor is configured to call program instructions in the memory to execute the above-mentioned method for implementing the status bar and navigation bar under multiple screens.

[0088] An embodiment of the present invention provides an electronic device 30, such as Figure 3 As shown, the electronic device includes at least one processor 301, and at least one memory 302 and a bus 303 connected to the processor; wherein the processor 301 and the memory 302 communicate with each other through the bus 303; the processor 301 is used to call the program instructions in the memory to execute the above-mentioned method for implementing the status bar and navigation bar under multiple screens.

[0089] The intelligent electronic devices in this article can be PCs, PADs, mobile phones, etc.

[0090] The present application also provides a computer program product, which, when executed on a process management electronic device, is suitable for executing a program of initializing the above-mentioned method steps for implementing the status bar and navigation bar under multiple screens.

[0091] It should be noted that, in the above embodiments, the description of each embodiment has its own focus. For parts that are not described in detail in a certain embodiment, reference can be made to the relevant description of other embodiments.

[0092] Those skilled in the art will appreciate that the embodiments of the present application can be provided as methods, systems, or computer program products. Therefore, the present application can adopt the form of a complete hardware embodiment, a complete software embodiment, or an embodiment in combination with software and hardware. Moreover, the present application can adopt the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to magnetic disk storage, CD-ROM, optical storage, etc.) that contain computer-usable program code.

[0093] The present application is described with reference to the flowcharts and / or block diagrams of the methods, devices (systems), and computer program products according to the embodiments of the present application. It should be understood that each process and / or box in the flowchart and / or block diagram, as well as the combination of the processes and / or boxes in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded computer, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 a process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0094] These computer program instructions may also be stored in a computer readable memory that can direct a computer or other programmable data processing device to work in a specific manner, so that the instructions stored in the computer readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1 a process or multiple processes and / or boxes Figure 1 The function specified in one or more boxes.

[0095] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operational steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing the instructions executed on the computer or other programmable device for implementing the process. Figure 1 a process or multiple processes and / or boxes Figure 1 A step that specifies a function in one or more boxes.

[0096] The present application also provides a computer program product, which includes computer software instructions. When the computer software instructions are executed on a processing device, the processing device is caused to execute the following Figure 1 This corresponds to the flow of memory control in the embodiment.

[0097] A computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the process or function according to the embodiment of the present application is generated in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions can be transmitted from one website, computer, server or data center to another website, computer, server or data center via a wired (e.g., coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) method. The computer-readable storage medium can be any available medium that a computer can store or a data storage device such as a server or data center that includes one or more available media integrated. The available medium can be a magnetic medium (e.g., a floppy disk, a hard disk, a tape), an optical medium (e.g., a DVD), or a semiconductor medium (e.g., a solid state drive (SSD)).

[0098] Those skilled in the art will clearly understand that, for the convenience and brevity of description, the specific working processes of the systems, devices and units described above can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

[0099] In the several embodiments provided in this application, it should be understood that the disclosed systems, devices and methods can be implemented in other ways. For example, the device embodiments described above are merely schematic. For example, the division of units is only a logical function division. In actual implementation, there may be other division methods, 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 an indirect coupling or communication connection through some interface, device or unit, which can be electrical, mechanical or other forms.

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

[0101] In addition, the functional units in the various embodiments of the present application may be integrated into a single processing unit, or each unit may exist physically separately, or two or more units may be integrated into a single unit. The aforementioned integrated units may be implemented in the form of hardware or software functional units.

[0102] 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 technical solution of the present application is essentially or the part that contributes to the prior art or all or part of the technical solution can be embodied in the form of a software product, and the computer software product is stored in a storage medium, including a number of instructions for enabling a computer device (which can be a personal computer, server, or network device, etc.) to execute all or part of the steps of the various embodiments of the present application. The aforementioned storage medium includes: various media that can store program codes, such as a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk.

[0103] 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 above embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the above embodiments, or make equivalent replacements for some of the technical features therein. However, 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.

Claims

1. A method for implementing a status bar and a navigation bar under multiple screens, characterized in that: include: Acquiring basic screen information based on a display management service, wherein the basic screen information includes the number of screens and screen configuration information; Based on the basic screen information, a status bar frame and a navigation bar frame are created for each screen in the system bar creation function of the SystemUI module; Configure the interface content for the status bar frame and navigation bar frame of each screen.

2. The method according to claim 1, characterized in that The obtaining of basic screen information based on the display management service includes: Define SystemUI module based on overlay; The SystemUI module is started to obtain the basic screen information through the display management service.

3. The method according to claim 1, characterized in that The configuration interface content for the status bar and navigation bar frame of each screen includes: A context object is created for each screen based on the screen configuration information, wherein the context object represents an independent operating environment of the screen in the system.

4. The method according to claim 3, characterized in that The configuration of the interface content for the status bar frame and the frame navigation bar frame of each screen includes: The class loader object of the plug-in application where the status bar and navigation bar of each screen are located is obtained through the context object of each screen.

5. The method according to claim 4, characterized in that The configuration of the interface content for the status bar frame and the frame navigation bar frame of each screen includes: Based on the class loader object of each screen, the plug-in application code corresponding to each screen is loaded through the reflection mechanism; The specific implementation content of the respective status bar and navigation bar is obtained through the plug-in application code corresponding to each screen, wherein the specific implementation content is a view class object.

6. The method according to claim 5, characterized in that The configuration of the interface content for the status bar frame and the frame navigation bar frame of each screen includes: The specific implementation content of the status bar and navigation bar of each screen is placed into the status bar frame and the navigation bar frame.

7. The method according to claim 6, characterized in that Also includes: Predefine resource files suitable for different screen resolutions and pixel densities within the plug-in application; When the specific implementation contents of the status bar and the navigation bar of each screen are placed into the status bar frame and the navigation bar frame, the target resource file is automatically selected based on the basic screen information.

8. A device for implementing a status bar and navigation bar under multiple screens, characterized in that: Also includes: an acquiring unit, configured to acquire basic screen information based on a display management service, wherein the basic screen information includes the number of screens and screen configuration information; A creation unit, configured to create a status bar frame and a navigation bar frame for each screen in a system bar creation function of a SystemUI module based on the basic screen information; Configuration unit, used to configure the interface content for the status bar frame and frame navigation bar frame of each screen.

9. A computer-readable storage medium, characterized in that The computer-readable storage medium includes a stored program, wherein when the program is executed by a processor, the steps of the method for implementing the status bar and navigation bar under multiple screens as claimed in any one of claims 1 to 7 are implemented.

10. An electronic device, characterized in that: The electronic device includes at least one processor and at least one memory connected to the processor; wherein the processor is used to call the program instructions in the memory to execute the steps of the method for implementing the status bar and navigation bar under multiple screens as described in any one of claims 1 to 7.

Images