Dynamic compatibility method for screens with different resolutions based on Android 10
By processing screen resolution parameters in the BootLoader and init process of Android system, the compatibility problem of displaying UI elements on screens with different resolutions of Android system is solved, and dynamic compatibility and user experience is improved.
Patent Information
- Application Number
- CN202411501973.3
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-10-25
- Publication Date
- 2025-02-18
AI Technical Summary
When existing Android systems deal with screens of different resolutions, it is difficult to achieve dynamic compatibility, resulting in abnormal display of UI elements, which increases system version update and testing pressure.
By reading the screen ID and confirming the resolution in the BootLoader stage, passing the resolution to the kernel as a boot parameter, parsing the parameters through the init process during the system startup stage and creating the ro.sf.lcd_density attribute, resolution compatibility is completed.
It realizes dynamic compatibility of screens with different resolutions, ensures that the display effect of UI elements on different devices, improves the ease of use of the system and user experience, and simplifies user operation process.
Smart Images

Figure CN119473194A_ABST
Abstract
Description
Technical Field
[0001] The present invention belongs to the technical field of smart devices, and specifically provides a dynamic compatibility method for screens with different resolutions based on Android 10. Background Art
[0002] Android 10 is a free and open source mobile operating system, mainly used in mobile devices such as smartphones and tablets. Due to the freedom of the Android system, developers can freely access the system source code and carry out customized development to create a rich variety of applications. This flexibility enables Android devices to meet the needs of different users. From high-end flagships to affordable entry-level devices, the Android system can provide excellent performance and experience.
[0003] However, when creating and producing a project, multiple screens with different resolutions are often used due to various customer needs. The resolution will eventually affect the display of the system interface. For example, on a high-resolution screen, if the screen density is set too high, the UI elements will appear too small, affecting the user experience; conversely, if the screen density is set too low, the UI elements will appear too large, wasting screen space and increasing the difficulty of project implementation.
[0004] In the native Android system, compatibility with this scenario is determined by compilation items, that is, the system is fixed at compile time to be used only for devices with a certain resolution screen. The system interface will display abnormally when using a screen with another resolution. This means that each device with a different resolution requires a system for itself, which greatly increases the pressure on system version updates and testing in the project. Therefore, a method of dynamic resolution compatibility is needed to improve it. Summary of the invention
[0005] The purpose of the present invention is to provide a dynamic compatibility method for screens with different resolutions based on Android 10 to solve the problems raised in the above background technology.
[0006] In order to achieve the above object, the present invention provides the following technical solution: a dynamic compatibility method for screens with different resolutions based on Android 10, the dynamic compatibility method comprising the following steps:
[0007] Step 1: The device is powered on, and the screen ID is read in the BootLoader stage to confirm its resolution, and the resolution is passed to the kernel as a boot parameter;
[0008] Step 2: During the system startup phase, after the kernel receives the parameters passed by BootLoader, it parses the parameters through the init process and creates the ro.sf.lcd_density attribute;
[0009] Step 3: During the startup phase of the Android UI service, the UI icon is displayed by creating the ro.sf.lcd_density attribute to achieve resolution compatibility.
[0010] Preferably, the specific process of the BootLoader stage is:
[0011] A1,After the Android device starts, the BootLoader runs first and is responsible for hardware initialization;
[0012] A2, at this time, BootLoader will read the hardware ID of the screen and use this ID to identify the screen type and resolution of the current device;
[0013] A3, Then, BootLoader will pass the screen resolution as a boot parameter to the kernel, the parameter is androidboot.lcd_size = 720*1280.
[0014] Preferably, the specific process of the system startup phase is:
[0015] B1, first, after receiving the parameters passed by BootLoader, the kernel performs initialization operations and loads various processes;
[0016] B2, after initialization is completed, the init process starts;
[0017] B3,In the stage of generating system properties, the init process will parse the boot parameters passed by the kernel;
[0018] B4, calculate the appropriate screen density through the screen resolution value in the boot parameters, androidboot.lcd_size=720*1280, and then set this value as the system property ro.sf.lcd_density.
[0019] Preferably, the specific process of the Android UI service startup phase is:
[0020] C1, when the system interface service is started, it reads the system property ro.sf.lcd_density;
[0021] C2, based on the value of ro.sf.lcd_density, the system interface service adjusts the size and layout of UI elements;
[0022] C3, the adjusted system interface will be correctly displayed on the screen of the current device, and users can see a clear and beautiful interface effect.
[0023] Preferably, the ro.sf.lcd_density system property value determines the pixels occupied by each icon in the system interface, and the resolution is compatible through different ro.sf.lcd_density property values.
[0024] Preferably, during the system startup phase, init creates a ro.sf.lcd_density attribute and sets its value according to the resolution parameter resolution when parsing the startup parameters;
[0025] Among them, androidboot.lcd_size=720*1280 corresponds to 320;
[0026] androidboot.lcd_size=480*854 corresponds to 240.
[0027] Preferably, the init process is the first process of the Android system, which is responsible for mounting files, system startup and system service tasks, and is also responsible for parsing the startup parameters passed by BootLoader and converting some parameters into Android system properties.
[0028] Preferably, the BootLoader is the first code that runs when the Android device starts up. It is responsible for initializing the hardware and establishing a mapping of the memory space, thereby bringing the system's hardware and software environment to a suitable state, so as to prepare the correct environment for the final call to the operating system kernel or user application.
[0029] The beneficial effects of the present invention are as follows:
[0030] 1. The present invention reads the screen hardware ID and identifies the resolution, so that the system interface can be adaptively adjusted according to the screens with different resolutions, ensuring the consistent display effect of UI elements on different devices. In addition, the method is automatically completed during the startup of the Android system without manual intervention by the user, thereby improving the usability and user experience of the system. At the same time, components such as BootLoader, kernel, init process and system interface service work together to form a highly integrated system, ensuring the accuracy and efficiency of resolution adjustment.
[0031] 2. The present invention transmits resolution parameters through BootLoader, thereby ensuring the accuracy of parameters and the reliability of transmission. By parsing parameters and setting system properties through the init process, the stability and reliability of the system are further enhanced, and the accuracy and error-free compatibility of resolution is ensured.
[0032] 3. The present invention adjusts the size and layout of UI elements so that the system interface can present a clear and beautiful effect on screens with different resolutions, thereby improving the user's visual experience. There is no need for the user to manually adjust the resolution or perform other cumbersome settings, which simplifies the user's operation process, improves the system's usability, and improves user satisfaction. BRIEF DESCRIPTION OF THE DRAWINGS
[0033] Figure 1 This is a flow chart of the dynamic compatibility method of the present invention. DETAILED DESCRIPTION
[0034] The following will be combined with the drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.
[0035] like Figure 1 As shown, an embodiment of the present invention provides a dynamic compatibility method for screens with different resolutions based on Android 10, and the dynamic compatibility method includes the following steps:
[0036] Step 1: The device is powered on, and the screen ID is read in the BootLoader stage to confirm its resolution, and the resolution is passed to the kernel as a boot parameter (cmdline);
[0037] Step 2: During the system startup phase, after the kernel receives the parameters passed by BootLoader, it parses the parameters through the init process and creates the ro.sf.lcd_density attribute;
[0038] Step 3: During the startup phase of the Android UI service, the UI icon is displayed by creating the ro.sf.lcd_density attribute to achieve resolution compatibility.
[0039] By reading the screen hardware ID and identifying the resolution, the system interface can be adaptively adjusted according to screens with different resolutions, ensuring that the display effects of UI elements on different devices are consistent. This method is automatically completed during the startup of the Android system without manual intervention by the user, improving the system's usability and user experience. At the same time, components such as the BootLoader, kernel, init process, and system interface service work together to form a highly integrated system, ensuring the accuracy and efficiency of resolution adjustment.
[0040] The specific process of the BootLoader stage is as follows:
[0041] A1,After the Android device starts, BootLoader runs first and is responsible for hardware initialization (such as screen, memory, processor, and peripherals);
[0042] A2, at this time, BootLoader will read the hardware ID of the screen and use this ID to identify the screen type and resolution of the current device;
[0043] In Android 10, the screen ID (commonly referred to as displayId) is a unique identifier used to represent the ID of the screen. The screen resolution can be identified by the screen ID;
[0044] A3, Then, BootLoader will pass the screen resolution as a boot parameter to the kernel, the parameter is androidboot.lcd_size = 720*1280.
[0045] The resolution parameters are passed through BootLoader to ensure the accuracy of the parameters and the reliability of the transmission. The parameters are parsed and the system properties are set through the init process, which further enhances the stability and reliability of the system and ensures that the resolution is compatible and accurate without errors.
[0046] The specific process of the system startup phase is as follows:
[0047] B1, first, after receiving the parameters passed by BootLoader, the kernel performs initialization operations and loads various processes;
[0048] The kernel is the first layer of software expansion based on hardware, providing secure access to computer hardware for other applications. It is the basis of the operating system and is responsible for managing system resources, including processes, memory, device drivers, files, and network systems.
[0049] B2, after initialization is completed, the init process starts;
[0050] B3,In the stage of generating system properties, the init process will parse the boot parameters passed by the kernel;
[0051] B4, calculate the appropriate screen density through the screen resolution value in the boot parameters, androidboot.lcd_size=720*1280, and then set this value as the system property ro.sf.lcd_density.
[0052] Among them, the specific process of the Android UI service startup phase is:
[0053] C1, when the system interface service is started, it reads the system property ro.sf.lcd_density;
[0054] The Android UI service is a system responsible for handling various tasks related to the user interface. It processes interface elements to form the main interface for users to interact with the device, allowing users to easily access various functions of the device.
[0055] C2, based on the value of ro.sf.lcd_density, the system interface service adjusts the size and layout of UI elements;
[0056] C3, the adjusted system interface will be correctly displayed on the screen of the current device, and users can see a clear and beautiful interface effect.
[0057] By adjusting the size and layout of UI elements, the system interface can present a clear and beautiful effect on screens of different resolutions, thereby improving the user's visual experience. There is no need for users to manually adjust the resolution or perform other tedious settings, which simplifies the user's operation process, improves the system's usability, and increases user satisfaction.
[0058] The ro.sf.lcd_density system property value determines the pixels occupied by each icon in the system interface, and the resolution is compatible through different ro.sf.lcd_density property values.
[0059] Wherein, during the system startup phase, when init parses the startup parameters, it creates the ro.sf.lcd_density attribute and sets its value according to the resolution parameter resolution;
[0060] Among them, androidboot.lcd_size=720*1280 corresponds to 320;
[0061] androidboot.lcd_size=480*854 corresponds to 240.
[0062] By parsing the androidboot.lcd_size property in the boot parameters through the init process, the system sets ro.sf.lcd_density to the screen density that matches the resolution to achieve dynamic compatibility.
[0063] The init process is the first process of the Android system, which is responsible for mounting files, system startup and system service tasks, and is also responsible for parsing the startup parameters passed by the BootLoader and converting some parameters into Android system properties.
[0064] The Init process is the first process to run after the system starts. It is responsible for initializing the system environment, including loading device drivers and setting system properties.
[0065] Among them, the BootLoader is the first code that runs when the Android device starts. It is responsible for initializing the hardware and establishing a mapping of the memory space, thereby bringing the system's hardware and software environment to a suitable state in order to prepare the correct environment for the final call to the operating system kernel or user application.
[0066] BootLoader is responsible for loading the operating system and specific programs.
[0067] It should be noted that, in this article, relational terms such as first and second, etc. are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the terms "include", "comprise" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device.
[0068] Although embodiments of the present invention have been shown and described, it will be appreciated by those skilled in the art that various changes, modifications, substitutions and variations may be made to the embodiments without departing from the principles and spirit of the present invention, and that the scope of the present invention is defined by the appended claims and their equivalents.
Claims
1. A dynamic compatibility method for screens with different resolutions based on Android 10, characterized by: The dynamic compatibility method comprises the following steps: Step 1: The device is powered on, and the screen ID is read in the BootLoader stage to confirm its resolution, and the resolution is passed to the kernel as a boot parameter; Step 2: During the system startup phase, after the kernel receives the parameters passed by BootLoader, it parses the parameters through the init process and creates the ro.sf.lcd_density attribute; Step 3: During the startup phase of the Android UI service, the UI icon is displayed by creating the ro.sf.lcd_density attribute to achieve resolution compatibility.
2. According to claim 1, a method for dynamic compatibility of screens with different resolutions based on Android 10 is characterized in that: The specific process of the BootLoader stage is as follows: A1,After the Android device starts, the BootLoader runs first and is responsible for hardware initialization; A2, at this time, BootLoader will read the hardware ID of the screen and use this ID to identify the screen type and resolution of the current device; A3, Then, BootLoader will pass the screen resolution as a boot parameter to the kernel, the parameter is androidboot.lcd_size = 720*1280.
3. According to claim 1, a method for dynamic compatibility of screens with different resolutions based on Android 10 is characterized in that: The specific process of the system startup phase is as follows: B1, first, after receiving the parameters passed by BootLoader, the kernel performs initialization operations and loads various processes; B2, after initialization is completed, the init process starts; B3,In the stage of generating system properties, the init process will parse the boot parameters passed by the kernel; B4, calculate the appropriate screen density through the screen resolution value in the boot parameters, androidboot.lcd_size=720*1280, and then set this value as the system property ro.sf.lcd_density.
4. According to claim 1, a method for dynamic compatibility of screens with different resolutions based on Android 10 is characterized in that: The specific process of the Android UI service startup phase is as follows: C1, when the system interface service is started, it reads the system property ro.sf.lcd_density; C2, based on the value of ro.sf.lcd_density, the system interface service adjusts the size and layout of UI elements; C3, the adjusted system interface will be correctly displayed on the screen of the current device, and the user can see a clear and beautiful interface effect.
5. The method for dynamic compatibility of screens with different resolutions based on Android 10 according to claim 1, characterized in that: The ro.sf.lcd_density system property value determines the pixels occupied by each icon in the system interface, and different ro.sf.lcd_density property values are used to make the resolution compatible.
6. The method for dynamic compatibility of screens with different resolutions based on Android 10 according to claim 1, characterized in that: During the system startup phase, when init parses the startup parameters, it creates the ro.sf.lcd_density attribute and sets its value according to the resolution parameter resolution; Among them, androidboot.lcd_size=720*1280 corresponds to 320; androidboot.lcd_size=480*854 corresponds to 240.
7. The method for dynamic compatibility of screens with different resolutions based on Android 10 according to claim 3, characterized in that: The init process is the first process of the Android system. It is responsible for mounting files, system startup and system service tasks. It is also responsible for parsing the startup parameters passed by BootLoader and converting some parameters into Android system properties.
8. The method for dynamic compatibility of screens with different resolutions based on Android 10 according to claim 1, characterized in that: The BootLoader is the first code that runs when the Android device starts. It is responsible for initializing the hardware and establishing a mapping of the memory space, thereby bringing the system's hardware and software environment to a suitable state in order to prepare the correct environment for the final call to the operating system kernel or user application.