Method for determining wireless charging parameters of an electronic device and electronic device

Abstract

The application relates to the technical field of terminal equipment, in particular to a method for determining wireless charging parameters of an electronic device and the electronic device. The method for determining the wireless charging parameters of the electronic device comprises the following steps: an electronic device acquires a sensor signal of a magnetic attraction sensor through a sensor driver located in an operating system kernel layer; the electronic device determines an in-place state of a magnetic attraction accessory according to the sensor signal; the in-place state represents whether the electronic device is assembled with the magnetic attraction accessory; and the electronic device determines wireless charging parameters of the electronic device according to the in-place state. Through the method, the wireless charging parameters of the electronic device are dynamically adjusted based on whether the electronic device is worn with the magnetic attraction accessory, so as to regulate the related parameters of the wireless charging of the electronic device and improve the success rate and charging efficiency of the wireless charging when the magnetic attraction accessory is worn.

Description

Technical Field

[0001] This application relates to the field of terminal equipment technology, specifically to a method for determining wireless charging parameters of an electronic device and an electronic device thereof. Background Technology

[0002] Using a protective case on your phone can protect it and reduce the risk of damage from bumps and drops. However, for phones that support wireless charging, which relies on electromagnetic induction, non-conductive or excessively thick case materials can create electromagnetic shielding between the phone's coil and the wireless charger's coil. Therefore, phones that support wireless charging may not be able to charge wirelessly when a case is on.

[0003] Magnetic phone cases feature a magnetic permeable area, aligning the phone's coil with the wireless charger's coil within this area. This ensures unobstructed movement between the two coils, preventing electromagnetic shielding.

[0004] However, because magnetic phone cases have thickness, the distance between the phone and the wireless charger changes, causing the phone's wireless charging parameters to no longer be suitable for wireless charging needs at this distance. This results in reduced wireless charging efficiency and the inability to wirelessly charge the phone. Summary of the Invention

[0005] To address the aforementioned technical problems, this application provides a method for determining wireless charging parameters for electronic devices and an electronic device in general, thereby enabling control over wireless charging of electronic devices and improving the success rate and efficiency of wireless charging when wearing magnetic accessories.

[0006] To achieve the above effects, the embodiments of this application propose the following technical solutions:

[0007] In a first aspect, a method for determining wireless charging parameters of an electronic device is provided, comprising: the electronic device acquiring sensor signals of a magnetic sensor through a sensor driver located in the kernel layer of the operating system; the electronic device determining the presence status of a magnetic accessory based on the sensor signals; the presence status characterizing whether the electronic device is equipped with a magnetic accessory; and the electronic device determining wireless charging parameters of the electronic device based on the presence status.

[0008] Based on this solution, the wireless charging parameters of electronic devices are dynamically adjusted according to whether the electronic devices are equipped with magnetic accessories, thereby improving the success rate and charging efficiency of wireless charging when magnetic accessories are worn.

[0009] In one possible implementation, the electronic device determines the wireless charging parameters based on its in-situ state, including: the electronic device acquiring the temperature control parameters of the electronic device; and the electronic device determining the wireless charging parameters based on the temperature control parameters and the in-situ state.

[0010] Based on this solution, by combining the temperature control parameters of the electronic device and the position status of the magnetic accessories, the wireless charging parameters of the electronic device can be determined, thereby enabling temperature control of the electronic device and reducing the problem of overheating affecting the performance of the electronic device.

[0011] In one possible implementation, the electronic device acquires its temperature control parameters, including: the electronic device determines the temperature control parameters based on its operating state; wherein the operating state of the electronic device includes at least one of screen-on state, screen-off state, and power-off state.

[0012] Based on this solution, the required temperature control parameters for electronic devices are different when the screen is on, off, or powered off. By combining the on-state with different temperature control parameters, the wireless charging parameters of electronic devices can be precisely adjusted for the on-state, off-state, or powered-off states respectively.

[0013] In one possible implementation, the electronic device determines its temperature control parameters based on its operating state, including: when the electronic device is in a screen-on state, the electronic device determines a first temperature control parameter; when the electronic device is in a screen-off state or a power-off state, the electronic device determines a second temperature control parameter; wherein the first temperature control parameter is different from the second temperature control parameter.

[0014] Based on this solution, when an electronic device is in a screen-on state, it indicates that the user may be using the device. Therefore, strict thermal management is required to prevent overheating from affecting the device's performance. When the device is in a screen-off or powered-off state, the user may not be using it, so thermal management can be less stringent, allowing for slightly higher heat levels. Thus, by adjusting the thermal management of the electronic device based on its potential user usage patterns, the system can meet user needs while simultaneously managing both thermal and charging performance.

[0015] In one possible implementation, the electronic device determines a first temperature control parameter by: a sensor driver sending an in-situ state to a sensor hardware abstraction layer located in the operating system hardware abstraction layer; the sensor hardware abstraction layer sending the in-situ state to a target application located in the operating system application layer; and the target application determining the first temperature control parameter based on the in-situ state.

[0016] Based on this solution, the in-situ state is sent to the sensor hardware abstraction layer via the sensor driver, and then the in-situ state is sent to the target application via the sensor hardware abstraction layer, thereby enabling the target application to determine the first temperature control parameter based on the in-situ state.

[0017] In one possible implementation, the sensor driver sends the in-situ state to the sensor hardware abstraction layer located in the operating system hardware abstraction layer, including: the sensor driver updating the target node; the target node is a node or node path pre-agreed between the sensor driver and the sensor hardware abstraction layer; after the sensor hardware abstraction layer detects the state change of the target node, it obtains the in-situ state from the sensor driver.

[0018] Based on this solution, communication between the kernel layer and the hardware abstraction layer is achieved by agreeing on the target node. The in-situ status of the magnetic accessory is sent to the sensor hardware abstraction layer, which in turn enables the sensor hardware abstraction layer to send the in-situ status to the target application.

[0019] In one possible implementation, the sensor driver sends the in-situ state to the sensor hardware abstraction layer located in the operating system hardware abstraction layer, including: the sensor driver broadcasting the in-situ state through a target event; and the sensor hardware abstraction layer obtaining the in-situ state by parsing the target event after listening to it.

[0020] Based on this solution, the presence status of the magnetic accessory is broadcast to the sensor hardware abstraction layer by broadcasting the target event, thereby enabling the sensor hardware abstraction layer to send the presence status to the target application.

[0021] In one possible implementation, the electronic device determines wireless charging parameters based on temperature control parameters and in-situ status, including: the target application sending the first temperature control parameters to the charging driver located in the operating system kernel layer; and the charging driver determining the wireless charging parameters based on the first temperature control parameters and in-situ status.

[0022] Based on this solution, the target application sends the first temperature control parameter to the charging driver through the interface located in the hardware abstraction layer, and the charging driver comprehensively considers the first temperature control parameter and the presence status of the magnetic accessory to determine the wireless charging parameter.

[0023] In one possible implementation, the electronic device acquires the sensor signal of the magnetic sensor through a sensor driver located in the operating system kernel layer, including: the sensor driver detecting a change in the sensor signal; and the sensor driver reading the sensor signal through a pre-registered first callback function.

[0024] Based on this solution, the sensor driver uses a registration callback method to read the signal of the magnetic sensor, so that the electronic device can determine the presence status of the magnetic accessory based on the signal of the magnetic sensor, i.e., the level status of the magnetic sensor, and then determine the wireless charging parameters of the electronic device based on the presence status.

[0025] In one possible implementation, the electronic device determines the presence status of the magnetic accessory based on a sensor signal, including: a sensor driver determining the level of the sensor signal; and the sensor driver determining the presence status of the magnetic accessory based on the level of the sensor signal.

[0026] Based on this solution, the presence status of the magnetic accessory is directly determined by sensor driving, so that the presence status of the magnetic accessory can be obtained directly at the lowest level of the operating system. This saves the repetitive operation caused by sending sensor signals to other devices and then having other devices determine the presence status of the magnetic accessory, thereby saving the operating space of electronic devices.

[0027] In one possible implementation, the sensor driver determines the presence status of the magnetic accessory based on the level of the sensor signal, including: when the level is high, determining that the electronic device is equipped with the magnetic accessory; when the level is low, determining that the electronic device is not equipped with the magnetic accessory.

[0028] Based on this solution, taking the magnetic sensor as a Hall sensor as an example, the Hall sensor will change its level when it detects that the magnetic component of the magnetic accessory is close to or far away. Therefore, the level of the magnetic sensor signal can be used to determine whether the electronic device is wearing the magnetic accessory, thus realizing the detection of the magnetic accessory's presence.

[0029] In one possible implementation, the electronic device determines its wireless charging parameters based on its in-situ state, and further includes: a sensor driver sending the in-situ state to a charging driver located in the operating system kernel layer; and the charging driver determining the wireless charging parameters of the electronic device based on the in-situ state.

[0030] Based on this scheme, in the process of determining wireless charging parameters, the sensor driver first sends the in-situ status to the charging driver, and the charging driver then determines the wireless charging parameters based on the in-situ status, thereby realizing the control of the efficiency of wireless charging of electronic devices.

[0031] In one possible implementation, the sensor driver sends the in-situ state to the charging driver located in the operating system kernel layer, including: the sensor driver creating a first interface; the charging driver registering a second callback function on the first interface; and the sensor driver sending the in-situ state to the charging driver through the second callback function.

[0032] Based on this solution, the interaction between the charging driver and the sensor driver is achieved by creating an interface and registering a callback function.

[0033] In one possible implementation, the sensor driver sends the in-situ state to the charging driver located in the operating system kernel layer, including: the charging driver creating a second interface; and the sensor driver sending the in-situ state to the charging driver through the second interface.

[0034] Based on this solution, the interaction between the charging driver and the sensor driver is realized by creating an interface.

[0035] In a second aspect, an electronic device is provided, comprising: a memory and one or more processors; the memory being coupled to the processors; wherein the memory stores computer program code, the computer program code including computer instructions, which, when executed by the processor, cause the electronic device to perform a method for determining wireless charging parameters of the electronic device as described in any of the first aspects.

[0036] Thirdly, a computer-readable storage medium is provided, including computer instructions that, when executed on an electronic device, cause the electronic device to perform a method for determining wireless charging parameters of the electronic device as described in any of the first aspects.

[0037] Fourthly, a computer program product is provided that, when run on a computer, causes the computer to perform a method for determining wireless charging parameters of an electronic device as described in any of the first aspects.

[0038] It is understood that the beneficial effects that the technical solutions provided in the second to fourth aspects above can achieve can be referred to the beneficial effects of the first aspect and any of its possible implementations, which will not be repeated here. Attached Figure Description

[0039] To more clearly illustrate the technical solution of this application, the drawings used in the embodiments will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0040] Figure 1 A schematic diagram illustrating a scenario of wireless charging for electronic devices;

[0041] Figure 2 This is a diagram illustrating a phone case.

[0042] Figure 3 A schematic diagram of a magnetic charging phone case;

[0043] Figure 4 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this application;

[0044] Figure 5 A software structure block diagram of an electronic device provided in an embodiment of this application;

[0045] Figure 6 A first flowchart illustrating a method for determining wireless charging parameters of an electronic device according to an embodiment of this application;

[0046] Figure 7 This is a block diagram of the operating system structure where the sensor driver is set in the kernel layer, as provided in the embodiments of this application.

[0047] Figure 8 A second flowchart illustrating the method for determining wireless charging parameters of an electronic device provided in an embodiment of this application;

[0048] Figure 9 A third flowchart illustrating the method for determining wireless charging parameters of an electronic device provided in this application embodiment;

[0049] Figure 10 This is a fourth flowchart illustrating the method for determining wireless charging parameters of an electronic device provided in an embodiment of this application.

[0050] Figure 11 This is a first flowchart illustrating the interaction between sensor driver and charging driver provided in an embodiment of this application.

[0051] Figure 12 This is a second flowchart illustrating the interaction between sensor driver and charging driver provided in an embodiment of this application.

[0052] Figure 13 A first flowchart illustrating the sensor driver and sensor hardware abstraction layer interaction method provided in an embodiment of this application;

[0053] Figure 14 This is a second flowchart illustrating the interaction method between the sensor driver and the sensor hardware abstraction layer provided in an embodiment of this application.

[0054] Figure 15 A schematic diagram illustrating the process of adding a thread to monitor the target node in the sensor hardware abstraction layer provided in this application embodiment;

[0055] Figure 16 A fifth flowchart illustrating the method for determining wireless charging parameters of an electronic device provided in this application embodiment.

[0056] Figure 17 A schematic diagram of the sensorhub initialization process where only the sensor driver is set in the sensorhub.

[0057] Figure 18 A schematic diagram illustrating the initialization process for setting up a sensor driver in a sensorhal according to an embodiment of this application;

[0058] Figure 19 A schematic flowchart illustrating the method for activating a magnetic sensor provided in an embodiment of this application;

[0059] Figure 20A schematic diagram illustrating the process of disabling the magnetic sensor provided in an embodiment of this application;

[0060] Figure 21 A schematic diagram of a device for determining wireless charging parameters of an electronic device provided in an embodiment of this application;

[0061] Figure 22 This is a schematic diagram of the chip system provided in an embodiment of this application. Detailed Implementation

[0062] The technical solutions of the embodiments of this application will be clearly described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this application. Other embodiments obtained by those skilled in the art based on the embodiments of this application without creative effort are all within the protection scope of this application.

[0063] In the following description, the terms "first," "second," etc., are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Therefore, a feature defined with "first," "second," etc., may explicitly or implicitly include one or more of that feature. In the description of this application, unless otherwise stated, "a plurality of" means two or more.

[0064] Furthermore, in this application, directional terms such as "upper," "lower," "inner," and "outer" are defined relative to the indicated placement of the components in the accompanying drawings. It should be understood that these directional terms are relative concepts, used for relative description and clarification, and can change accordingly depending on the placement of the components in the accompanying drawings.

[0065] To facilitate understanding of the technical solution of this application, some concepts involved in this application will be explained first below.

[0066] Magnetic phone case: A phone protection accessory with a built-in magnetic adsorption structure. The case contains a precisely arranged array of magnets that can be magnetically attached to accessories such as wireless chargers for quick and secure connection.

[0067] SensorHub, also known as a sensor hub, is a low-power coprocessor in electronic devices specifically designed to manage and coordinate multiple sensors. SensorHub can process data from Hall sensors, accelerometers, gyroscopes, light sensors, and more without waking the main processor, thus significantly reducing the power consumption of electronic devices.

[0068] The application scenarios of the embodiments of this application will be described below with reference to the accompanying drawings.

[0069] Figure 1 A schematic diagram illustrating a scenario of wireless charging for electronic devices. Figure 2 This is a diagram illustrating a phone case. Figure 3 A schematic diagram of a magnetic charging phone case.

[0070] For ease of explanation, the following description uses a mobile phone as the electronic device and a magnetic charging phone case as the magnetic accessory to illustrate the wireless charging scenario of an electronic device wearing a magnetic accessory. In reality, the electronic device can also be a tablet computer, a smart wearable device, or other types of electronic devices with wireless power supply capabilities. The examples in this application do not constitute a limitation on the type of electronic device.

[0071] With the development of technology, mobile phones have gradually become an indispensable part of people's work and life. Currently, some mobile phones have wireless charging capabilities, such as... Figure 1 As shown, by placing the mobile phone 1 on the wireless charger 2 and aligning the back of the mobile phone 1 with the coil area of ​​the wireless charger 2, the alternating electromagnetic field generated by the built-in coil of the wireless charger 2 after being powered on causes the receiving coil inside the mobile phone 1 (the receiving coil is usually integrated near the battery) to induce a magnetic field. The receiving coil then generates a current through electromagnetic induction, and the power management chip inside the mobile phone 1 converts the induced current into direct current to charge the battery of the mobile phone 1.

[0072] In order for a mobile phone 1 with wireless charging capability to continue wirelessly charging while wearing a phone case 3, by means of the phone case 3 (e.g. Figure 2 A precise structure is designed on the (as shown) to obtain such a Figure 3 The magnetic charging phone case 4 shown enables magnetic positioning of the phone case and the wireless charger 2, as well as wireless charging of the phone 1. Specifically, the phone case has a magnetic window 5 and a magnet 6. The magnet 5 and the magnet of the wireless charger form a complementary magnetic field, causing the magnet 5 on the phone case to be magnetically attracted and fixed to the wireless charger's magnet for magnetic positioning. Furthermore, the magnetic window 5 ensures unobstructed movement between the phone's coil and the wireless charger's coil, allowing current to be generated between them through electromagnetic induction. This avoids shielding the electromagnetic field of the wireless charger 2, so the phone 1 can still be charged via the wireless charger 2 even when wearing the magnetic charging phone case 4.

[0073] Although the magnetic charging phone case 4 can be used to wirelessly charge the phone 1, the thickness of the magnetic charging phone case 4 changes the distance between the phone 1 and the wireless charger 2, causing the wireless charging parameters of the phone 1 to no longer be suitable for the wireless charging needs at this distance. This results in a decrease in the wireless charging efficiency of the phone 1 and the inability to wirelessly charge.

[0074] To address the issue that the wireless charging efficiency of the phone 1 may be affected when charging while wearing a magnetic charging phone case 4, potentially leading to charging failure, this application proposes a method for determining the wireless charging parameters of an electronic device and an electronic device in general. By adjusting the wireless charging parameters of the electronic device based on the presence of the magnetic accessory, the success rate and charging efficiency of wireless charging when wearing a magnetic phone case can be improved.

[0075] Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application.

[0076] Electronic device 100 may include a processor 110, a wireless charging coil 120, a universal serial bus (USB) interface 130, a charging management module 140, a power management module 141, a battery 142, antenna 1, antenna 2, a mobile communication module 150, a wireless communication module 160, an audio module 170, a sensor module 180, a button 190, a motor 191, an indicator 192, a camera 193, a display screen 194, etc. The sensor module 180 may include a pressure sensor 180A, a gyroscope sensor 180B, a barometric pressure sensor 180C, a magnetic sensor 180D, etc.

[0077] It is understood that the structures illustrated in the embodiments of the present invention do not constitute a specific limitation on the electronic device 100. In other embodiments of this application, the electronic device 100 may include more or fewer components than illustrated, or combine some components, or split some components, or have different component arrangements. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

[0078] Processor 110 may include one or more processing units, such as: application processor (AP), modem processor, graphics processing unit (GPU), image signal processor (ISP), controller, video codec, digital signal processor (DSP), baseband processor, sensor hub, and / or neural network processing unit (NPU), etc. Different processing units may be independent devices or integrated into one or more processors.

[0079] The controller can generate operation control signals based on the instruction opcode and timing signals to complete the control of instruction fetching and execution.

[0080] The processor 110 may also include a memory for storing instructions and data. In some embodiments, the memory in the processor 110 is a cache memory. This memory can store instructions or data that the processor 110 has just used or that are used repeatedly. If the processor 110 needs to use the instruction or data again, it can retrieve it directly from the memory. This avoids repeated accesses, reduces the waiting time of the processor 110, and thus improves the efficiency of the system.

[0081] In some embodiments, the processor 110 may include one or more interfaces. Interfaces may include an inter-integrated circuit (I2C) interface, an inter-integrated circuit sound (I2S) interface, a pulse code modulation (PCM) interface, a universal asynchronous receiver / transmitter (UART) interface, a mobile industry processor interface (MIPI), a general-purpose input / output (GPIO) interface, a subscriber identity module (SIM) interface, and / or a universal serial bus (USB) interface, etc.

[0082] The I2C interface is a bidirectional synchronous serial bus, including a serial data line (SDA) and a serial clock line (SCL). In some embodiments, the processor 110 may include multiple I2C buses. The processor 110 can couple to a touch sensor, charger, flash, camera 193, etc., through different I2C bus interfaces. For example, the processor 110 can couple to a touch sensor through the I2C interface, enabling the processor 110 and the touch sensor to communicate through the I2C bus interface, thereby realizing the touch function of the electronic device 100.

[0083] The I2S interface can be used for audio communication. In some embodiments, the processor 110 may include multiple I2S buses. The processor 110 can be coupled to the audio module 170 via the I2S bus to enable communication between the processor 110 and the audio module 170. In some embodiments, the audio module 170 can transmit audio signals to the wireless communication module 160 via the I2S interface to enable the function of answering phone calls through a Bluetooth headset.

[0084] The PCM interface can also be used for audio communication, sampling, quantizing, and encoding analog signals. In some embodiments, the audio module 170 and the wireless communication module 160 can be coupled via the PCM bus interface. In some embodiments, the audio module 170 can also transmit audio signals to the wireless communication module 160 via the PCM interface, enabling the function of answering phone calls through a Bluetooth headset. Both the I2S interface and the PCM interface can be used for audio communication.

[0085] The UART interface is a universal serial data bus used for asynchronous communication. This bus can be a bidirectional communication bus. It converts the data to be transmitted between serial and parallel communication. In some embodiments, the UART interface is typically used to connect the processor 110 and the wireless communication module 160. For example, the processor 110 communicates with the Bluetooth module in the wireless communication module 160 via the UART interface to implement Bluetooth functionality. In some embodiments, the audio module 170 can transmit audio signals to the wireless communication module 160 via the UART interface to enable music playback through Bluetooth headphones.

[0086] The MIPI interface can be used to connect the processor 110 to peripheral devices such as the display screen 194 and the camera 193. The MIPI interface includes a camera serial interface (CSI) and a display serial interface (DSI). In some embodiments, the processor 110 and the camera 193 communicate via the CSI interface to enable the electronic device 100 to capture images. The processor 110 and the display screen 194 communicate via the DSI interface to enable the electronic device 100 to display images.

[0087] The GPIO interface can be configured via software. It can be configured as a control signal or a data signal. In some embodiments, the GPIO interface can be used to connect the processor 110 to a camera 193, a display screen 194, a wireless communication module 160, an audio module 170, a sensor module 180, etc. The GPIO interface can also be configured as an I2C interface, an I2S interface, a UART interface, a MIPI interface, etc.

[0088] USB port 130 is a USB standard compliant interface, specifically a Mini USB port, Micro USB port, USB Type-C port, etc. USB port 130 can be used to connect a charger to charge electronic device 100, and can also be used for data transfer between electronic device 100 and peripheral devices. It can also be used to connect headphones for audio playback. This interface can also be used to connect other electronic devices, such as AR devices.

[0089] It is understood that the interface connection relationships between the modules illustrated in the embodiments of the present invention are merely illustrative and do not constitute a structural limitation on the electronic device 100. In other embodiments of this application, the electronic device 100 may also employ different interface connection methods or combinations of multiple interface connection methods as described in the above embodiments.

[0090] The charging management module 140 receives charging input from a charger. The charger can be a wireless charger or a wired charger. In some wired charging embodiments, the charging management module 140 can receive charging input from the wired charger via the USB interface 130, or it can receive charging input from the wireless charger via the wireless charging coil 120. In some wireless charging embodiments, the charging management module 140 can receive wireless charging input via the wireless charging coil of the electronic device 100. While charging the battery 142, the charging management module 140 can also supply power to the electronic device via the power management module 141.

[0091] The power management module 141 connects the battery 142, the charging management module 140, and the processor 110. The power management module 141 receives input from the battery 142 and / or the charging management module 140, providing power to the processor 110, internal memory, display screen 194, camera 193, and wireless communication module 160, etc. The power management module 141 can also monitor parameters such as battery capacity, battery cycle count, and battery health status (leakage current, impedance). In some other embodiments, the power management module 141 may also be located within the processor 110. In other embodiments, the power management module 141 and the charging management module 140 may be located in the same device.

[0092] The wireless communication function of electronic device 100 can be realized through antenna 1, antenna 2, mobile communication module 150, wireless communication module 160, modem processor and baseband processor, etc.

[0093] Antenna 1 and antenna 2 are used to transmit and receive electromagnetic wave signals. Each antenna in electronic device 100 can be used to cover one or more communication frequency bands. Different antennas can also be multiplexed to improve antenna utilization. For example, antenna 1 can be multiplexed as a diversity antenna for a wireless local area network. In some other embodiments, the antennas can be used in conjunction with tuning switches.

[0094] The mobile communication module 150 can provide solutions for wireless communication, including 2G / 3G / 4G / 5G, applied to the electronic device 100. The mobile communication module 150 may include at least one filter, switch, power amplifier, low noise amplifier (LNA), etc. The mobile communication module 150 can receive electromagnetic waves via antenna 1, and perform filtering, amplification, and other processing on the received electromagnetic waves before transmitting them to a modem processor for demodulation. The mobile communication module 150 can also amplify the signal modulated by the modem processor and convert it into electromagnetic waves for radiation via antenna 1. In some embodiments, at least some functional modules of the mobile communication module 150 may be housed in the processor 110. In some embodiments, at least some functional modules of the mobile communication module 150 and at least some modules of the processor 110 may be housed in the same device.

[0095] The modem processor may include a modulator and a demodulator. The modulator modulates the low-frequency baseband signal to be transmitted into a mid-to-high frequency signal. The demodulator demodulates the received electromagnetic wave signal into a low-frequency baseband signal. The demodulator then transmits the demodulated low-frequency baseband signal to the baseband processor for processing. After processing by the baseband processor, the low-frequency baseband signal is transmitted to the application processor. The application processor outputs sound signals through an audio device (not limited to a speaker, receiver, etc.) or displays images or videos through the display screen 194. In some embodiments, the modem processor may be a separate device. In other embodiments, the modem processor may be independent of the processor 110 and may be housed in the same device as the mobile communication module 150 or other functional modules.

[0096] The wireless communication module 160 can provide solutions for wireless communication applications on the electronic device 100, including wireless local area networks (WLANs) (such as wireless fidelity (Wi-Fi) networks), Bluetooth (BT), global navigation satellite system (GNSS), frequency modulation (FM), near field communication (NFC), and infrared (IR) technologies. The wireless communication module 160 can be one or more devices integrating at least one communication processing module. The wireless communication module 160 receives electromagnetic waves via antenna 2, performs frequency modulation and filtering of the electromagnetic wave signals, and sends the processed signal to processor 110. The wireless communication module 160 can also receive signals to be transmitted from processor 110, perform frequency modulation and amplification, and convert them into electromagnetic waves for radiation via antenna 2.

[0097] In some embodiments, antenna 1 of electronic device 100 is coupled to mobile communication module 150, and antenna 2 is coupled to wireless communication module 160, enabling electronic device 100 to communicate with networks and other devices via wireless communication technology. Wireless communication technology may include Global System for Mobile Communications (GSM), General Packet Radio Service (GPRS), Code Division Multiple Access (CDMA), Wideband Code Division Multiple Access (WCDMA), Time Division Code Division Multiple Access (TD-SCDMA), Long Term Evolution (LTE), BT, GNSS, WLAN, NFC, FM, and / or IR technologies, etc. GNSS can include the Global Positioning System (GPS), the Global Navigation Satellite System (GLONASS), the BeiDou Navigation Satellite System (BDS), the Quasi-Zenith Satellite System (QZSS), and / or satellite-based augmentation systems (SBAS).

[0098] Electronic device 100 implements display functions through a GPU, a display screen 194, and an application processor. The GPU is a microprocessor for image processing, connected to the display screen 194 and the application processor. The GPU is used to perform mathematical and geometric calculations and for graphics rendering. Processor 110 may include one or more GPUs, which execute program instructions to generate or modify display information.

[0099] Display screen 194 is used to display images, videos, etc. Display screen 194 includes a display panel. The display panel may be a liquid crystal display (LCD), an organic light-emitting diode (OLED), an active-matrix organic light-emitting diode (AMOLED), a flexible light-emitting diode (FLED), a Mini LED, a MicroLED, a Micro-OLED, a quantum dot light-emitting diode (QLED), etc. In some embodiments, electronic device 100 may include one or N displays 194, where N is a positive integer greater than 1.

[0100] Electronic device 100 can perform shooting functions through ISP, camera 193, video codec, GPU, display 194 and application processor.

[0101] The ISP (Image Signal Processor) is used to process data fed back from the camera 193. For example, when taking a picture, the shutter is opened, and light is transmitted through the lens to the camera's photosensitive element. The light signal is converted into an electrical signal, and the camera's photosensitive element transmits the electrical signal to the ISP for processing, transforming it into an image visible to the naked eye. The ISP can also perform algorithmic optimization of image noise, brightness, and skin tone. The ISP can also optimize parameters such as exposure and color temperature of the shooting scene. In some embodiments, the ISP can be set in the camera 193.

[0102] Camera 193 is used to capture still images or videos. An object is projected onto a photosensitive element by generating an optical image through the lens. The photosensitive element can be a charge-coupled device (CCD) or a complementary metal-oxide-semiconductor (CMOS) phototransistor. The photosensitive element converts the light signal into an electrical signal, which is then passed to an ISP for conversion into a digital image signal. The ISP outputs the digital image signal to a DSP for processing. The DSP converts the digital image signal into image signals in standard RGB, YUV, or other formats. In some embodiments, the electronic device 100 may include one or N cameras 193, where N is a positive integer greater than 1.

[0103] Digital signal processors (DSPs) are used to process digital signals. Besides digital image signals, they can also process other digital signals. For example, when electronic device 100 selects a frequency, the DSP can perform Fourier transforms on the frequency energy.

[0104] Video codecs are used to compress or decompress digital video. Electronic device 100 may support one or more video codecs. Thus, electronic device 100 can play or record videos in various encoding formats, such as Moving Picture Experts Group (MPEG) 1, MPEG2, MPEG3, MPEG4, etc.

[0105] An NPU (Neural Processing Unit) is a computational processor for neural networks (NNs). By borrowing the structure of biological neural networks, such as the transmission patterns between neurons in the human brain, it can rapidly process input information and continuously learn on its own. NPUs enable intelligent cognitive applications in electronic devices, such as image recognition, facial recognition, speech recognition, and text understanding.

[0106] Electronic device 100 can implement audio functions such as music playback and recording through audio module 170, speaker, receiver, microphone, headphone jack, and application processor.

[0107] The audio module 170 is used to convert digital audio information into analog audio signals for output, and also to convert analog audio input into digital audio signals. The audio module 170 can also be used for encoding and decoding audio signals. In some embodiments, the audio module 170 may be located in the processor 110, or some functional modules of the audio module 170 may be located in the processor 110.

[0108] Pressure sensor 180A is used to sense pressure signals and convert them into electrical signals. In some embodiments, pressure sensor 180A can be disposed on display screen 194. There are many types of pressure sensors 180A, such as resistive pressure sensors, inductive pressure sensors, and capacitive pressure sensors. A capacitive pressure sensor may include at least two parallel plates with conductive material. When force is applied to pressure sensor 180A, the capacitance between the electrodes changes. Electronic device 100 determines the pressure intensity based on the change in capacitance. When a touch operation is applied to display screen 194, electronic device 100 detects the touch operation intensity based on pressure sensor 180A. Electronic device 100 can also calculate the touch position based on the detection signal from pressure sensor 180A. In some embodiments, touch operations applied to the same touch position but with different touch operation intensities can correspond to different operation commands. For example: when a touch operation with an intensity less than a first pressure threshold is applied to the SMS application icon, a command to view an SMS is executed. When a touch operation with an intensity greater than or equal to the first pressure threshold is applied to the SMS application icon, a command to create a new SMS is executed.

[0109] The gyroscope sensor 180B can be used to determine the motion attitude of the electronic device 100. In some embodiments, the gyroscope sensor 180B can determine the angular velocity of the electronic device 100 about three axes (i.e., the x, y, and z axes). The gyroscope sensor 180B can be used for image stabilization. For example, when the shutter is pressed, the gyroscope sensor 180B detects the angle of the shake of the electronic device 100, calculates the distance that the lens module needs to compensate based on the angle, and allows the lens to counteract the shake of the electronic device 100 by moving in the opposite direction, thus achieving image stabilization. The gyroscope sensor 180B can also be used in navigation and motion-sensing game scenarios.

[0110] The barometric pressure sensor 180C is used to measure air pressure. In some embodiments, the electronic device 100 calculates altitude using the air pressure value measured by the barometric pressure sensor 180C to assist in positioning and navigation.

[0111] The magnetic sensor 180D includes a Hall sensor. The electronic device 100 can use the magnetic sensor 180D to detect the opening and closing of the flip cover. In some embodiments, when the electronic device 100 is a flip phone, it can detect the opening and closing of the flip cover using the magnetic sensor 180D. Based on the detected opening and closing state of the cover or flip cover, features such as automatic unlocking of the flip cover can be set. The electronic device 100 can also use the magnetic sensor 180D to detect whether a magnetic accessory is worn on it. In some embodiments, when a magnetic accessory is worn on the electronic device 100, the output level of the magnetic sensor 180D is high; when no magnetic accessory is worn, the output level of the magnetic sensor 180D is low. Furthermore, the level state of the magnetic sensor 180D can change during the removal / wearing of the magnetic accessory, triggering an interrupt callback function. The sensor driver then reads the current level of the magnetic sensor 180D through its interface.

[0112] Buttons 190 include a power button, volume buttons, etc. Buttons 190 can be mechanical buttons or touch-sensitive buttons. Electronic device 100 can receive button input and generate key signal inputs related to user settings and function control of electronic device 100.

[0113] Motor 191 can generate vibration alerts. Motor 191 can be used for incoming call vibration alerts or for touch vibration feedback. For example, different vibration feedback effects can correspond to touch operations performed on different applications (such as taking photos, playing audio, etc.). Motor 191 can also correspond to different vibration feedback effects for touch operations performed on different areas of the display screen 194. Different application scenarios (such as time reminders, receiving messages, alarm clocks, games, etc.) can also correspond to different vibration feedback effects. The touch vibration feedback effect can also be customized.

[0114] Indicator 192 can be an indicator light, used to indicate charging status, power changes, or to indicate messages, missed calls, notifications, etc.

[0115] The software system of electronic device 100 can adopt a layered architecture, event-driven architecture, microkernel architecture, microservice architecture, or cloud architecture. This embodiment of the invention uses the layered architecture Android system as an example to exemplify the software structure of electronic device 100.

[0116] Figure 5 This is a software structure block diagram of an electronic device provided in an embodiment of this application.

[0117] A layered architecture divides software into several layers, each with a clear role and function. Layers communicate with each other through software interfaces. In some embodiments, the Android system is divided into four layers, from top to bottom: the application layer, the application framework layer, the Android runtime and system libraries, and the kernel layer.

[0118] The application layer can include a series of application packages.

[0119] like Figure 5 As shown, the application package may include applications such as battery management, camera, gallery, calendar, call, map, navigation, music, video, SMS, product testing, power saving assistant, and animation effects.

[0120] A production testing application is used to test the functionality of electronic device 100. For example, the production testing application checks whether the detection of the presence status of magnetic accessories is accurate.

[0121] The power-saving application is used to provide temperature control parameters for electronic device 100 based on its operation, thereby achieving thermal management of the electronic device. For example, when electronic device 100 is in the screen-on state, it outputs dynamic thermal management strategies to the charging drive based on the position status of the magnetic accessories.

[0122] Animation applications are used to display dynamic effects when an electronic device 100 is wearing or removing magnetic accessories.

[0123] The application framework layer provides application programming interfaces (APIs) and a programming framework for applications in the application layer. The application framework layer includes some predefined functions.

[0124] like Figure 5 As shown, the application framework layer may include a window manager, input manager, phone manager, resource manager, notification manager, sensor manager, sensor service, etc.

[0125] The window manager is used to manage windowed applications. It can retrieve screen size, determine the presence of a status bar, lock the screen, and capture screenshots, among other things.

[0126] The input manager can be used to listen for user input events, such as clicks and swipes performed by the user's finger on the display screen 193 of the electronic device 100. By listening to input events, the electronic device 100 can determine whether it is in use.

[0127] The phone manager is used to provide communication functions for electronic device 100. For example, it manages call status (including connection and disconnection).

[0128] The file explorer provides applications with various resources, such as localized strings, icons, images, layout files, video files, and more.

[0129] The notification manager allows applications to display notifications in the status bar. These notifications can be used to deliver informational messages and can disappear automatically after a short pause, requiring no user interaction. For example, the notification manager can be used to notify users of completed downloads or message alerts. The notification manager can also display notifications as icons or scrolling text in the top status bar, such as notifications from background applications, or as dialog boxes on the screen. Examples include displaying text messages in the status bar, emitting sounds, vibrating electronic devices, and flashing indicator lights.

[0130] The sensor manager is used to monitor data returned by various sensors in the electronic device 100, such as motion sensor data, proximity sensor data, temperature sensor data, and magnetic sensor 180D data. Using the data returned by these sensors, the electronic device 100 can determine if it is shaking, if the display screen 193 is obstructed, or if it is wearing magnetic accessories. Furthermore, the sensor manager can provide a unified sensor access interface (sensor service) for applications in the application layer and manage the efficient and secure use of sensor resources.

[0131] The Android Runtime consists of core libraries and a virtual machine. The Android runtime is responsible for the scheduling and management of the Android system.

[0132] The core library consists of two parts: one part is the functionalities that need to be called by the Java language, and the other part is the Android core library.

[0133] The application layer and application framework layer run in a virtual machine. The virtual machine executes the Java files of the application layer and application framework layer as binary files. The virtual machine is used to perform functions such as object lifecycle management, stack management, thread management, security and exception management, and garbage collection.

[0134] System libraries can include multiple functional modules. For example: surface manager, media libraries, 3D graphics processing libraries (e.g., OpenGL ES), 2D graphics engines (e.g., SGL), etc.

[0135] The Surface Manager is used to manage the display subsystem and provides the blending of 2D and 3D layers for multiple applications.

[0136] The media library supports playback and recording of various common audio and video formats, as well as still image files. It supports multiple audio and video encoding formats, such as MPEG4, H.264, MP3, AAC, AMR, JPG, and PNG.

[0137] The 3D graphics processing library is used to implement 3D graphics drawing, image rendering, compositing, and layer processing.

[0138] A 2D graphics engine is a graphics engine for 2D drawing.

[0139] The Hardware Abstraction Layer (HAL) abstracts the hardware operation interface, encapsulating the underlying driver interface into a unified Application Programming Interface (API). This simplifies the complexity of hardware operations for applications.

[0140] It should be noted that the embodiments of this application are only illustrated by the HAL layer and can also be described independently of the kernel layer. In fact, the hardware abstraction layer can also be part of the kernel layer, and the embodiments of this application do not limit this.

[0141] In this embodiment, the HAL layer may include a sensor hardware abstraction layer. The sensor hardware abstraction layer can provide corresponding hardware and software support according to the wireless charging parameter adjustment requirements of the electronic device 100. Specifically, it can provide detection requirements for magnetic accessories and data transmission requirements based on hardware and software support.

[0142] The kernel layer is the layer between hardware and software. The kernel layer includes at least the display driver, camera driver, sensor driver, and charging driver.

[0143] The kernel layer can include the base kernel, extended kernel, and driver layer.

[0144] The basic kernel can implement core functions such as memory management, task management, inter-process communication, and interrupt management based on the memory (Mem) interface, task (Task) interface, inter-process communication (IPC) interface, and interrupt interface.

[0145] The driver layer includes at least the display driver, camera driver, audio driver, sensor driver, and graphics driver.

[0146] It is understood that the structures illustrated in the embodiments of this application do not constitute a specific limitation on the electronic device 100. In other embodiments of this application, the electronic device 100 may include more or fewer components than illustrated, or combine some components, or split some components, or have different component arrangements. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

[0147] The following example, using the scenario of detecting the presence of magnetic accessories, illustrates the workflow of the software and hardware of electronic device 100.

[0148] Figure 6 This is a first flowchart illustrating a method for determining wireless charging parameters of an electronic device according to an embodiment of this application.

[0149] like Figure 6 As shown, in some embodiments, a method for determining wireless charging parameters of an electronic device is provided, the method comprising the following steps S1 to S3.

[0150] Step S1: The electronic device acquires the sensor signal of the magnetic sensor through the sensor driver located in the kernel layer of the operating system.

[0151] In this step, the sensor signals obtained can determine whether the electronic device is wearing magnetic accessories, so as to adjust the wireless charging parameters of the electronic device.

[0152] The sensor signal of a magnetic sensor corresponds to whether an electronic device is wearing a magnetic accessory. The sensor signal is different when the electronic device is wearing a magnetic accessory or not. In this way, the difference in sensor signal can be used to determine whether the electronic device is wearing a magnetic accessory.

[0153] It is worth noting that as long as the sensor signal differs depending on whether the electronic device is wearing or not wearing the magnetic accessory, this application does not limit the magnitude of the sensor signal. For example, when the electronic device is wearing the magnetic accessory, the sensor signal is M1, and when the electronic device is not wearing the magnetic accessory, the sensor signal is M2. It is only necessary that M1 and M2 are different; the magnitude relationship between M1 and M2 is not limited.

[0154] For example, the sensor signal can be any of a voltage signal, a current signal, or a level signal.

[0155] For example, when the sensor signal is a voltage signal, the sensor signal is set to V1 when the electronic device is wearing a magnetic accessory and V2 when the electronic device is not wearing a magnetic accessory. In this way, it can be determined whether the electronic device is wearing a magnetic accessory based on whether the magnitude of the acquired voltage signal is V1 or V2.

[0156] For example, when the sensor signal is a current signal, the sensor signal is set to I1 when the electronic device is wearing a magnetic accessory and I2 when the electronic device is not wearing a magnetic accessory. In this way, it can be determined whether the electronic device is wearing a magnetic accessory based on whether the magnitude of the acquired current signal is I1 or I2.

[0157] For example, when the sensor signal is a level signal, the sensor signal is set to be high when the electronic device is wearing a magnetic accessory and low when the electronic device is not wearing a magnetic accessory. In this way, the high or low state of the acquired level signal can be used to determine whether the electronic device is wearing a magnetic accessory.

[0158] It should be understood that the magnetic sensor can be a magnetic sensor 180D, a pressure sensor, or an optical sensor, etc. As long as the sensor signal of the magnetic sensor changes when the magnetic accessory is worn or not, and the electronic device is able to determine whether it is wearing a magnetic accessory based on the sensor signal of the magnetic sensor, this application does not limit the specific type of magnetic sensor.

[0159] For example, when the magnetic sensor is a magnetic sensor, the magnetic sensor generates different voltage signals, current signals or level signals based on the changes in magnetic force caused by the magnetic accessory approaching or moving away, so as to determine whether the electronic device is wearing a magnetic accessory based on the sensor signal output by the magnetic sensor.

[0160] For example, when the magnetic sensor is a pressure sensor, the pressure sensor detects different pressures when the electronic device is wearing magnetic accessories and when it is not wearing magnetic accessories, thereby outputting different voltage signals, current signals or level signals, so as to determine whether the electronic device is wearing magnetic accessories based on the sensor signals output by the magnetic sensor.

[0161] For example, when the magnetic sensor is an optical sensor, the optical sensor detects whether the emitted infrared light is blocked by the magnetic accessory. When the electronic device is wearing the magnetic accessory, the infrared light is blocked by the magnetic accessory, and when the electronic device is not wearing the magnetic accessory, the infrared light is not blocked by the magnetic accessory. Different voltage signals, current signals, or level signals are output according to whether the infrared light is blocked by the magnetic accessory, so that it is possible to determine whether the electronic device is wearing the magnetic accessory based on the sensor signal output by the magnetic sensor.

[0162] In related technologies, for example, Hall effect sensors are used to detect whether an electronic device is wearing a magnetic protective case. The presence of the magnetic protective case can be determined by recognizing the Hall effect sensor signal through the corresponding sensor driver on the SensorHub. When the electronic device needs to read the presence status of the magnetic protective case, it registers the Hall effect sensor interface, and the Hall effect sensor interface reports the presence status of the magnetic protective case to the electronic device. Since the sensor driver is located on the SensorHub, the magnetic sensor is driven through the SensorHub's sensor driver. The SensorHub and SensorHal (the sensor hardware abstraction layer, located in the operating system hardware abstraction layer) communicate via a common QMI module.

[0163] However, in some System-on-a-Chip (SoC) platforms, when an electronic device is powered off and charging, it defaults to running the kernel layer instead of starting the sensorhub. Therefore, if the sensor driver is set up in the sensorhub, the sensorhub process needs to be activated for wireless charging to work when the electronic device is powered off and wireless charging is in progress. Furthermore, since the kernel layer and sensorhub cannot communicate directly, the sensorhal process also needs to be activated first. The sensorhal communicates with the sensorhub to obtain the presence status of the magnetic protective case, and then sends this status to the charging module located in the kernel layer to adjust the wireless charging parameters of the electronic device based on the presence status of the magnetic protective case.

[0164] Therefore, this embodiment places the sensor driver in the kernel layer of the operating system. This allows the sensor driver to directly obtain the presence status of the magnetic accessory (i.e., the presence status of the magnetic protective case) on the electronic device, regardless of whether the device is powered on or off. When the electronic device is powered off and wirelessly charging, the kernel layer is enabled by default, and modules within the kernel layer can directly communicate via interfaces. Therefore, the charging module located in the kernel layer can also directly obtain the presence status of the magnetic protective case from the sensor driver located in the kernel layer. This eliminates the need to first wake up the sensorhub and sensorhal processes; the charging module can directly obtain the presence status of the magnetic protective case to adjust the wireless charging parameters of the electronic device. This implementation is not only concise in code and business logic but also reduces the standby power consumption of the electronic device and results in faster wireless charging.

[0165] Figure 7 This is a block diagram of the operating system structure where the sensor driver is located at the kernel layer, as provided in the embodiments of this application. Compared to... Figure 5, Figure 7 Some parts that are not needed in the introduction are omitted, and arrows showing the data transmission between each level when executing the method to determine the wireless charging parameters of electronic devices are provided. Figure 7 In this context, register and callback represent the registration and callback between modules to enable communication between them.

[0166] In one implementation, the sensor driver is set at the operating system kernel layer, such as... Figure 7 As shown.

[0167] For example, on some mainstream SoC platforms, the SoC (System-on-a-Chip) uses a 1.2V power supply design. Therefore, the GPIO interface voltage on the SoC is 1.2V, while the power management unit (PMU) chip on the board has a 1.8V GPIO interface. Furthermore, current magnetic sensors support a voltage of 1.8V. If the solution in related technologies where the sensor driver is located on the sensor hub side is adopted, the sensor hub can only use the GPIO interface on the SoC, not the GPIO interface on the PMU. The voltage of the GPIO interface on the SoC is incompatible with the voltage supported by the magnetic sensor. Therefore, the solution of setting the sensor driver on the sensor hub side cannot be used directly; a level conversion circuit is needed to ensure that the converted voltage of the GPIO interface on the SoC matches the voltage supported by the magnetic sensor.

[0168] Specifically, the process of improving related technologies using level conversion circuitry involves converting the 1.2V GPIO interface on the SoC to a 1.8V GPIO interface to match the voltage supported by the magnetic sensor. However, this increases cost and board space. The increased board space is particularly significant in foldable screen electronic devices.

[0169] By adopting the solution proposed in this application of setting the sensor driver in the kernel layer, since the kernel layer can directly use the GPIO interface on the PMU as the interrupt GPIO interface of the magnetic sensor, the level conversion line can be eliminated, thereby saving cost and board space.

[0170] Figure 8 This is a second flowchart illustrating a method for determining wireless charging parameters of an electronic device according to an embodiment of this application.

[0171] In one implementation, combining Figure 8 As shown, step S1 includes the following steps S11 and S12.

[0172] Step S11: The sensor driver detects a change in the sensor signal.

[0173] For example, when the sensor signal is a continuous analog signal (such as a voltage or current signal), the analog signal output by the magnetic sensor is converted into a digital signal by an analog-to-digital converter and stored in the memory of the electronic device. When the digital signal generates a rising or falling edge, it is determined that the sensor signal has changed. This change triggers a pre-registered interrupt callback function of the magnetic sensor, and the digital signal is sent to the sensor driver by the processor.

[0174] When the sensor signal is a discrete level signal used to represent the state, the level signal output by the magnetic sensor is directly read through the GPIO interface and stored in the memory of the electronic device. When the level signal changes, it is determined that the sensor signal has changed. This change triggers the interrupt callback function pre-registered by the magnetic sensor, and the level signal is sent to the sensor driver by the processor.

[0175] In step S12, the sensor driver reads the sensor signal through a pre-registered first callback function.

[0176] For example, a first callback function can be pre-registered on the GPIO interface of the magnetic sensor.

[0177] For example, sensor signals such as Figure 7 The GPIO parameters corresponding to the magnetic sensor shown are shown.

[0178] In this embodiment, the sensor driver uses a registered callback method to read the signal from the magnetic sensor. This allows the electronic device to determine the presence status of the magnetic accessory based on the signal, i.e., the voltage level of the magnetic sensor, thereby regulating the charging of the electronic device and improving its charging efficiency. Specifically, the first callback function is pre-registered on the GPIO interface of the magnetic sensor.

[0179] For example, the sensor signal of the magnetic sensor is read from the GPIO interface of the magnetic sensor through the first callback function.

[0180] In step S2, the electronic device determines the in-situ status of the magnetic accessory based on the sensor signal.

[0181] Among them, the in-situ status indicates whether the electronic device is equipped with magnetic accessories.

[0182] In this step, the sensor signal corresponds to different sensor signals depending on the state of the electronic device wearing the magnetic accessory. The presence status of the magnetic accessory can be determined based on the magnitude of the sensor signal.

[0183] For example, if the sensor signal is a voltage signal, and the voltage signal is greater than the voltage threshold, then the presence of the magnetic accessory is determined to be that the electronic device is equipped with the magnetic accessory; if the voltage signal is greater than the voltage threshold, then the presence of the magnetic accessory is determined to be that the electronic device is not equipped with the magnetic accessory.

[0184] For example, if the sensor signal is a current signal, and the current signal is greater than the current threshold, then the presence of the magnetic accessory is determined to be that the electronic device is equipped with the magnetic accessory. If the current signal is greater than the voltage threshold, then the presence of the magnetic accessory is determined to be that the electronic device is not equipped with the magnetic accessory.

[0185] It is worth noting that in electronic devices, the determination of the in-situ state of the magnetic accessory can be achieved by a sensor driven at the kernel layer, a charging driver at the kernel layer, an application in the electronic device, or other components in the electronic device, and this application does not limit this.

[0186] Figure 9 This is a third flowchart illustrating the method for determining wireless charging parameters of an electronic device provided in an embodiment of this application.

[0187] In one implementation, combining Figure 9 As shown, step S2 includes the following steps S21 and S22.

[0188] Step S21: The sensor driver determines the level state of the sensor signal.

[0189] In one example, the level is determined to be high when the voltage of the sensor signal is greater than 1.5V, and low when the voltage of the sensor signal is less than or equal to 1.5V.

[0190] In another example, the sensor driver reads the sensor signal as only "0" or "1" representing the level state, where "0" represents a low level and "1" represents a high level.

[0191] Step S22: The sensor driver determines the in-situ status of the magnetic accessory based on the level of the sensor signal.

[0192] In this embodiment, the presence status of the magnetic accessory is directly determined by sensor driving, so that the presence status of the magnetic accessory can be obtained directly at the lowest level of the operating system. This saves the repetitive operation caused by sending sensor signals to other devices and then having other devices determine the presence status of the magnetic accessory, thereby saving the operating space of the electronic device.

[0193] In one specific implementation, step S22 includes the following steps S221 and S222.

[0194] Step S221: When the level is high, determine that the electronic device is equipped with a magnetic accessory.

[0195] Step S222: When the level is low, determine that the electronic device is not equipped with magnetic accessories.

[0196] In another specific implementation, step S22 includes the following steps S223 and S224.

[0197] Step S223: When the level is low, determine that the electronic device is equipped with a magnetic accessory.

[0198] Step S224: When the level is high, determine that the electronic device is not equipped with magnetic accessories.

[0199] It is worth noting that this application does not limit the specific correspondence between the in-situ state and the sensor signal, such as whether the voltage signal and current signal are large or small in different in-situ states, or whether the level signal is high or low in different in-situ states. This is related to the specific circuit design. As long as the sensor signal can be distinguished under different in-situ states, it is acceptable.

[0200] For example, the magnetic sensor can be a Hall sensor (i.e., magnetic sensor 180D). The Hall sensor changes its voltage level when it detects the magnet of the magnetic accessory approaching or moving away. Therefore, the presence of the magnetic accessory can be determined by the voltage level of the magnetic sensor signal. Specifically, a high voltage level corresponds to the magnetic accessory being mounted on the electronic device. However, this high voltage level could also indicate that the magnetic accessory is not yet mounted on the electronic device, but is very close to it. Therefore, a high voltage level could correspond to the magnetic accessory being about to be mounted on the electronic device, the magnetic accessory being mounted on the electronic device, or the magnetic accessory being about to be removed from the electronic device. However, the sensor driver only reads the sensor signal when the aforementioned sensor signal changes. Therefore, the presence of the magnetic accessory after the change can be determined by comprehensively judging the voltage level of the sensor signal before the change and whether the sensor signal is high or low after the change.

[0201] Alternatively, step S22 may include steps S225 and S226.

[0202] Step S225: When the voltage level is high and the voltage level of the sensor signal was low before the sensor signal changed, it is determined that the electronic device is not equipped with the magnetic accessory.

[0203] Step S226: When the level is low and the sensor signal level was high before the sensor signal changed, it is determined that the electronic device is equipped with a magnetic accessory.

[0204] This improves the accuracy of identifying the presence of magnetic accessories.

[0205] Specifically, if the sensor signal is at a high level before the sensor signal changes, and the "sensor driver detects a change in sensor signal" is triggered at this time, it indicates that the magnetic accessory may only momentarily jump to a low level and then quickly jump back to a high level. The cause may be that the magnetic sensor is malfunctioning or the magnetic accessory is simply moving away from or approaching the electronic device quickly. In this case, there is no need to modify the charging parameters of the electronic device, so as to reduce the complex process required to adjust the charging parameters.

[0206] If the sensor signal is at a low level before the sensor signal changes, and the "sensor driver detects a change in sensor signal" is triggered at this time, it indicates that the magnetic accessory may only momentarily jump to a high level and then quickly jump back to a low level. The cause may be that the magnetic sensor is malfunctioning or the magnetic accessory is only quickly approaching and moving away from the electronic device. In this case, there is no need to modify the charging parameters of the electronic device, so as to reduce the complicated process required to adjust the charging parameters.

[0207] Step S3: The electronic device determines its wireless charging parameters based on its in-situ status.

[0208] In this step, the wireless charging parameters of the electronic device are adjusted based on whether the device is wearing a magnetic protective case. This allows for adjustment of the wireless charging parameters while the device is wirelessly charging, enabling wireless charging even when the device is wearing a magnetic protective case, improving charging efficiency, and reducing the impact of magnetic accessories on wireless charging.

[0209] In one implementation, wireless charging parameters include charging power and communication signal strength, among others.

[0210] For example, wireless charging parameters include charging power. When electronic devices are equipped with magnetic accessories, the power loss caused by wearing magnetic accessories can be reduced by increasing the charging power, thereby improving the electromagnetic effect between the built-in coil of the electronic device and the wireless charger.

[0211] For example, wireless charging parameters include communication signal strength. When electronic devices are equipped with magnetic accessories, the impact of the magnetic accessories on the communication signal strength between the electronic devices and the wireless charger can be reduced by enhancing the communication signal strength.

[0212] Figure 10 This is a fourth flowchart illustrating the method for determining wireless charging parameters of an electronic device provided in an embodiment of this application.

[0213] In one implementation, combining Figure 10 As shown, step S3 includes the following steps S31 and S32.

[0214] Step S31: The electronic device acquires the temperature control parameters of the electronic device.

[0215] In this step, the temperature control parameters of the electronic device are obtained first, and then the wireless charging parameters of the electronic device are determined, so as to achieve thermal control of the electronic device by regulating the charging of the electronic device.

[0216] Furthermore, the temperature control parameters of electronic devices differ depending on their operating state. For example, the temperature control parameters of an electronic device differ when the screen is on, off, or powered off. Specifically, when the screen is on, it indicates that the user may be using the electronic device, requiring adjustments to the heat generated by wireless charging and minimizing its impact on the device's performance. To provide a better user experience when the screen is on, the temperature control parameters of the electronic device need to be strictly controlled. When the screen is off or powered off, the user may not be using the electronic device temporarily, allowing for less restriction of thermal management on charging efficiency and improving charging efficiency.

[0217] For example, the temperature control parameters include at least one of the following: CPU maximum frequency limit, GPU maximum frequency limit, CPU core switching strategy, GPU core switching strategy, charging current, charging voltage, and wireless charging efficiency. Specifically, the CPU maximum frequency limit is used to adjust the CPU's peak frequency at high temperatures; the GPU maximum frequency limit is used to adjust the GPU's peak frequency at high temperatures; the CPU core switching strategy is used to disable some CPU cores to reduce power consumption; the GPU core switching strategy is used to disable some GPU cores to reduce power consumption; the charging current and charging voltage are both used to reduce fast charging power when the electronic device is at high temperatures; and the wireless charging efficiency is used to dynamically adjust the power transmission of the electronic device's wireless charging coil.

[0218] For example, step S31 includes the following step S311.

[0219] Step S311: The electronic device determines the temperature control parameters of the electronic device based on its operating status.

[0220] The operating state of an electronic device includes at least one of the following: screen on, screen off, and power off.

[0221] The required temperature control parameters for electronic devices differ depending on whether the screen is on, off, or powered off. Therefore, by combining the current state with these different temperature control parameters, the wireless charging parameters of the electronic device can be precisely adjusted for each state. Specifically, the temperature control parameters differ depending on the operating state. For example, when the electronic device is on, the temperature control parameters must consider both the heat generated by the device's operation and the heat generated during charging to minimize the impact on user experience. When the electronic device is off or powered off, the temperature control parameters can only consider the heat generated during charging.

[0222] The following examples illustrate the implementation of step S311, which involves determining the temperature control parameters of an electronic device based on its operating state, using the electronic device in a screen-on state, a screen-off state, and a power-off state as examples.

[0223] For example, when the electronic device is in the screen-on state, the method of determining the temperature control parameters of the electronic device includes step S3111.

[0224] Step S3111: When the electronic device is in the screen-on state, the electronic device determines the first temperature control parameter.

[0225] In this step, with the electronic device's screen on, the wireless charging parameters are determined based on the first temperature control parameter and the device's on-state status. Determining the first temperature control parameter requires the target application within the electronic device to provide a dynamic first temperature control parameter based on the screen-on state. Therefore, the on-state status of the magnetic accessory needs to be sent to the target application first.

[0226] For example, the first temperature control parameter is determined by the target application based on the type and number of processes running in the electronic device. For instance, when a user is playing a game on an electronic device, it is necessary to strictly control the heat generated by the electronic device to ensure that the power consumption of the game provides a good gaming experience for the user and reduce problems such as lag caused by heat generation.

[0227] For example, the first temperature control parameter regulates all aspects of the electronic device that may generate heat, thereby controlling the heat generation of the electronic device without affecting user operation. The first temperature control parameter may include the maximum frequency limit of the CPU, the maximum frequency limit of the GPU, the core switching strategy of the CPU, the core switching strategy of the GPU, the charging current, the charging voltage, and the wireless charging efficiency.

[0228] The method for determining the temperature control parameters of an electronic device when the screen is off or the device is powered off includes step S3112.

[0229] Step S3112: When the electronic device is in a screen-off state or a power-off state, the electronic device determines the second temperature control parameter.

[0230] For example, such as Figure 7 As shown, the battery thermal management module "Bms_thermal" in the hardware abstraction layer of the electronic device is responsible for determining the second temperature control parameter. The battery thermal management module is used to coordinate the battery status and temperature control of the electronic device to ensure that the electronic device is charged within a safe temperature range.

[0231] The first temperature control parameter is different from the second temperature control parameter.

[0232] The second temperature control parameter can be known, meaning it is pre-stored in the battery thermal management module. When the electronic device is powered off or the screen is off, the temperature control parameter can be a fixed setting. In this case, the target application does not need to participate in the temperature control parameter determination process; it can directly obtain the fixed temperature control parameter. For example, the second temperature control parameter can have a mapping relationship with the temperature of the electronic device. After the battery thermal management module collects the temperature of the electronic device, it directly looks up the corresponding second temperature control parameter in the pre-stored second temperature control parameters.

[0233] For example, the second temperature control parameter includes charging current, charging voltage, and wireless charging efficiency.

[0234] In this embodiment, when the electronic device is in a screen-on state, it indicates that the user may be using the device. Therefore, strict thermal management is required to prevent the device's performance from being affected by overheating. When the electronic device is in a screen-off or powered-off state, the user may not be using it, so thermal management can be reduced, meaning the device can generate slightly more heat. Thus, by adjusting the thermal management of the electronic device based on its potential user usage patterns, the user's needs for using the device are met while simultaneously managing both thermal and charging performance.

[0235] Specifically, when wirelessly charging electronic devices while wearing a magnetic protective case, the devices often generate excessive heat. By adjusting the wireless charging settings using temperature control parameters, the heat generated by wearing a magnetic protective case during wireless charging can be reduced.

[0236] In step S32, the electronic device determines the wireless charging parameters based on the temperature control parameters and the in-situ status.

[0237] Wireless charging parameters can be obtained by readjusting the temperature control parameters based on the in-situ state. That is, after obtaining the temperature control parameters, the parameters are readjusted according to whether the electronic device is wearing magnetic accessories to obtain the wireless charging parameters. For example, if the temperature control parameters include wireless charging efficiency, the wireless charging efficiency can be improved if the electronic device is wearing magnetic accessories in the in-situ state, thereby increasing the charging efficiency.

[0238] In this embodiment, by combining the temperature control parameters of the electronic device and the position status of the magnetic accessory, the wireless charging parameters of the electronic device are determined, thereby enabling temperature control of the electronic device and reducing the problem of overheating affecting the performance of the electronic device.

[0239] The method for determining wireless charging parameters of electronic devices provided in this application dynamically adjusts the wireless charging parameters of electronic devices based on whether the electronic device is wearing magnetic accessories, thereby regulating the wireless charging power and heat generation of the electronic device and reducing the problems of reduced wireless charging efficiency and inability to wirelessly charge caused by wearing magnetic accessories.

[0240] In one implementation, the charging driver of the electronic device's operating system determines the wireless charging parameters. Before step S32, steps S33 and S34 are also performed to send the in-place status to the charging driver.

[0241] In step S33, the sensor driver will send the in-situ state to the charging driver located in the operating system kernel layer.

[0242] Step S34: The charging driver determines the wireless charging parameters of the electronic device based on the in-situ status.

[0243] In this embodiment, during the process of determining wireless charging parameters, the sensor driver first sends the in-situ status to the charging driver, which then determines the wireless charging parameters based on the in-situ status, thereby controlling the power and other parameters of wireless charging for electronic devices. Specifically, during the process of the charging driver determining the wireless charging parameters based on the in-situ status, the charging driver can comprehensively determine the wireless charging parameters based on temperature control parameters and the in-situ status.

[0244] For example, when the electronic device is in the screen-on state, the temperature control parameters are determined by the target application after the sensor driver sends the in-situ status to the target application. When the electronic device is in the power-off state or screen-off state, the temperature control parameters can be fixed. In this case, the target application does not need to participate in the temperature control parameter determination process; it can directly obtain the fixed temperature control parameters.

[0245] In this embodiment, communication between the sensor driver and the charging driver in the kernel layer is established so that the sensor driver can send the in-situ state to the charging driver, thereby facilitating the charging driver to determine the wireless charging parameters based on the in-situ state. The method for establishing communication between the sensor driver and the charging driver in the kernel layer is as described in steps S331 to S333, or as described in steps S334 and S335.

[0246] Figure 11 This is a schematic diagram of the first process of sensor driving and charging driving interaction provided in an embodiment of this application.

[0247] In one specific implementation, combined with Figure 11 As shown, the method for establishing communication between the sensor driver and the charging driver in the kernel layer includes the following steps S331 to S333.

[0248] Step S331: The sensor driver creates the first interface.

[0249] The first interface is a software interface used by other modules to register callback functions, so that the sensor driver can communicate with other modules that have registered callback functions through the first interface.

[0250] Step S332: The charging driver registers a second callback function on the first interface.

[0251] The second callback function is used for communication between the charging driver and the sensor driver.

[0252] In step S333, the sensor driver sends the in-place status to the charging driver via the second callback function.

[0253] In this embodiment, the interaction between the charging driver and the sensor driver is achieved by creating an interface and registering a callback function. Specifically, the first interface is the core interface exposed by the sensor driver to other modules. After the sensor driver detects a change in the voltage level of the magnetic sensor, the sensor driver calls the second callback function to notify the charging driver of the in-situ state corresponding to the changed voltage level of the magnetic sensor.

[0254] For example, the first interface is that the sensor exposes itself to other modules through the kernel layer macro "EXPORT_SYMBOL" of the operating system.

[0255] Figure 12 This is a second flowchart illustrating the interaction between sensor driving and charging driving provided in an embodiment of this application.

[0256] In another specific implementation, combined with Figure 12 As shown, the method for establishing communication between the sensor driver and the charging driver in the kernel layer includes the following steps S334 and S335.

[0257] Step S334: The charging driver creates a second interface.

[0258] The second interface is a software interface used for direct communication between the charging driver and other modules.

[0259] In step S335, the sensor driver sends the in-place status to the charging driver via the second interface.

[0260] In this embodiment, the interaction between the charging driver and the sensor driver is achieved by creating an interface. Specifically, the second interface is the core interface exposed by the charging driver to other modules. After the sensor driver detects a change in the voltage level of the magnetic sensor, the sensor driver notifies the charging driver of the corresponding presence status of the magnetic sensor after the change in voltage level through the second interface.

[0261] For example, the second interface is that the sensor exposes itself to other modules through the kernel layer macro "EXPORT_SYMBOL" of the operating system.

[0262] Combination Figure 7 As can be seen, the process by which the sensor driver located in the kernel layer sends the presence status of the magnetic accessory to the target application includes: the sensor driver reporting layer by layer according to the hardware abstraction layer, the framework layer, and the application layer. The specific implementation method is as follows.

[0263] For example, when the electronic device is in the screen-on state, the electronic device determines the first temperature control parameter (i.e., the above step S3111), which may include the following steps S3111a to S3111c.

[0264] In step S3111a, the sensor driver will send the in-situ status to the sensor hardware abstraction layer located in the operating system hardware abstraction layer.

[0265] In step S3111b, the sensor hardware abstraction layer will send the in-bit state to the target application located in the operating system application layer.

[0266] In step S3111c, the target application determines the first temperature control parameter based on the in-situ status.

[0267] In this embodiment, the in-situ state is sent to the sensor hardware abstraction layer via the sensor driver, and then the sensor hardware abstraction layer sends the in-situ state to the target application, enabling the target application to determine the first temperature control parameter based on the in-situ state. Specifically, during the process of the target application determining the temperature control parameter based on the in-situ state, whether the magnetic shell is being worn can be considered to determine whether it is necessary to anticipate and regulate the heat generated by other applications within the electronic device and the heat generated by wireless charging.

[0268] For example, combining Figure 7 As shown, the target applications include: Power Saving Wizard APK, Product Testing APK, and Animation Effects. Power Saving Wizard APK is responsible for dynamically adjusting the temperature control of the electronic device when the screen is on. Product Testing APK is responsible for testing the capabilities of the electronic device, and in the process of testing, it uses the in-situ status of the magnetic device. Animation Effects is responsible for adjusting the display animations of the electronic device's screen based on the in-situ status of the magnetic device.

[0269] Continue to refer to Figure 7 After obtaining the presence status of the magnetic accessory, the sensor driver located in the kernel layer sends the presence status to the sensor hardware abstraction layer located in the hardware abstraction layer. The sensor hardware abstraction layer sends the presence status to the power saving wizard APK (i.e. the target application mentioned above) in the application layer through the interface of the framework layer provided by the operating system. After the target application determines the low temperature control parameters based on the presence status, it sends the low temperature control parameters to the charging driver located in the kernel layer through the interface of the hardware abstraction layer.

[0270] Simultaneously, after acquiring the presence status, the sensor driver will directly send the presence status to the charging driver, which is also located in the kernel layer. In this way, after obtaining the first temperature control parameter and the presence status, the wireless driver can determine whether the electronic device is wirelessly charging while the screen is on.

[0271] In this embodiment, communication between the sensor driver and the sensor hardware abstraction layer is established so that the sensor driver can send the in-situ state to the sensor hardware abstraction layer, thereby facilitating the sensor hardware abstraction layer to send the in-situ state to the target application. The method for establishing communication between the sensor driver and the sensor hardware abstraction layer is as described in steps S1301 and S1302, or as described in steps S1401 and S1402.

[0272] Figure 13 This is a first flowchart illustrating the interaction method between the sensor driver and the sensor hardware abstraction layer provided in an embodiment of this application.

[0273] In one implementation, combining Figure 13 As shown, the method for constructing communication between the sensor driver and the sensor hardware abstraction layer is as follows: steps S1301 and S1302.

[0274] Step S1301: The sensor driver updates the target node.

[0275] The target node is a node or node path pre-agreed upon by the sensor driver and the sensor hardware abstraction layer.

[0276] In step S1302, after the sensor hardware abstraction layer detects a change in the state of the target node, it obtains the in-situ state from the sensor driver.

[0277] The sensor hardware abstraction layer monitors whether the state of the target node changes through I / O multiplexing mechanisms (such as epoll, poll, and select). The I / O multiplexing mechanism is used by the program to monitor whether the node has changed.

[0278] In this embodiment, communication between the kernel layer and the hardware abstraction layer is achieved by agreeing on a target node. The in-situ status of the magnetic accessory is sent to the sensor hardware abstraction layer, which in turn enables the sensor hardware abstraction layer to send the in-situ status to the target application.

[0279] Specifically, the sensor driver first agrees with the hardware abstraction layer on a node or a node path. After the sensor driver obtains the in-situ status of the magnetic accessory, it updates the status of the target node.

[0280] It is worth noting that the state of the target node can be consistent with the presence state of the magnetic accessory, both indicating whether the electronic device is wearing the magnetic accessory. In this way, the sensor hardware abstraction layer can determine whether the magnetic accessory is being worn or removed from the electronic device after detecting a change in the state of the target node. Alternatively, the state of the target node can be 0 or 1 to indicate a change in the presence state of the magnetic accessory. After determining that the presence state of the magnetic accessory has changed, the presence state of the magnetic accessory is then obtained from the sensor driver. This application does not impose any restrictions on this.

[0281] Figure 14 This is a second flowchart illustrating the interaction method between the sensor driver and the sensor hardware abstraction layer provided in an embodiment of this application.

[0282] In another implementation, combining Figure 14 As shown, the method for constructing communication between the sensor driver and the sensor hardware abstraction layer is as follows: steps S1401 and S1402.

[0283] In step S1401, the sensor driver broadcasts the presence status to the sensor hardware abstraction layer via the target event.

[0284] In step S1402, after the sensor hardware abstraction layer listens to the broadcast target event, it obtains the in-situ status through target event parsing.

[0285] In this embodiment, the presence status of the magnetic accessory is broadcast to the sensor hardware abstraction layer (HIPL) via a target event, enabling the HIPL to then transmit the presence status to the target application. Specifically, after receiving the presence status of the magnetic accessory, the sensor driver broadcasts it via a target event. When the HIPL listens to this target event, it parses the presence status of the magnetic accessory from the event. Thus, the HIPL can directly parse the presence status without needing to obtain it from the sensor driver.

[0286] For example, a driver in the kernel layer interacts with the hardware abstraction layer by sending uevent events. Specifically, a sensor driver in the kernel layer broadcasts the presence status of a magnetic accessory via a uevent event after receiving it. The sensor hardware abstraction layer continuously listens for this uevent event, and upon receiving it, it can parse the presence status of the magnetic accessory from the event.

[0287] It is understood that although the embodiments of this application propose a scheme to implement the sensor driver in the kernel layer, the original scheme of setting the sensor driver in the sensorhub can still be retained. This is because setting the sensor driver in the sensorhub has lower power consumption, so the sensor driver in the sensorhub can still be retained to determine temperature control parameters based on the presence of the magnetic accessory when the electronic device is in a screen-on state.

[0288] For example, at the software architecture level, step S32, which is the electronic device determining the wireless charging parameters based on the temperature control parameters and the in-situ state, includes the following steps S321 and S322.

[0289] In step S321, the target application sends the first temperature control parameter to the charging driver located in the operating system kernel layer.

[0290] In step S322, the charging driver determines the wireless charging parameters based on the first temperature control parameters and the in-situ state.

[0291] In this embodiment, such as Figure 7As shown, the target application sends the first temperature control parameter to the charging driver through the Hidden Layer (HIL) / Aidl interface located in the Hardware Abstraction Layer (HAL). The charging driver then determines the wireless charging parameters by comprehensively considering the first temperature control parameter and the presence status of the magnetic accessory. Specifically, this solution requires the target application to comprehensively consider the processes running within the electronic device when the screen is on, and provide the necessary first temperature control parameter for thermal management. Furthermore, the charging driver needs to comprehensively consider the first temperature control parameter and the presence status to regulate the wireless charging of the electronic device without affecting user operation, reducing issues such as charging failure and excessive heat caused by using the magnetic case for wireless charging.

[0292] Figure 15 A schematic diagram illustrating the process of adding a thread to monitor the target node in the sensor hardware abstraction layer provided in this application embodiment.

[0293] In one implementation, combining Figure 15 As shown, a listening thread is initiated in the sensor hardware abstraction layer (e.g., Figure 15 In step S1501), this thread is used to listen for target events or target nodes. This enables the sensor hardware abstraction layer to obtain the in-situ status of the magnetic accessory. Specifically, the diagram schematically illustrates adding a thread to the sensor hardware abstraction layer to use epoll to listen for the ap value node (the ap value node is the target node, such as...). Figure 15 In step S1502), if the apvalue node is updated (e.g.) Figure 15 In step S1503, the presence status of the magnetic accessory is obtained by parsing the ap value node (e.g., ...). Figure 15 After step S1504, the thread reports the presence status of the magnetic accessory to the target application (e.g., ...). Figure 15 (Step S1505).

[0294] For example, the target application also includes an application responsible for controlling the animation display on the electronic device's screen. The method further includes: the sensor driver sending an in-situ state to the application responsible for the animation display, and the application displaying different animations based on the in-situ state. This allows the electronic device to display different animations depending on whether the electronic device is wearing a magnetic protective case or has removed it, improving the system's interactivity.

[0295] Figure 16 This is a fifth flowchart illustrating the method for determining wireless charging parameters of an electronic device provided in an embodiment of this application.

[0296] Specifically, combined Figure 16 As shown in the embodiments of this application, the method for determining wireless charging parameters of an electronic device includes the following steps S1601 to S1606.

[0297] In step S1601, the sensor driver detects a change in the sensor signal.

[0298] The specific implementation method of step S1601 is the same as that of step S11 above, and will not be repeated here.

[0299] In step S1602, the sensor driver reads the sensor signal through a pre-registered first callback function.

[0300] The specific implementation method of step S1602 is the same as that of step S12 above, and will not be repeated here.

[0301] Step S1603: The sensor driver determines the level state of the sensor signal.

[0302] The specific implementation method of step S1603 is the same as that of step S21 above, and will not be repeated here.

[0303] In step S1604, the sensor driver determines the presence status of the magnetic accessory based on the level of the sensor signal.

[0304] The specific implementation method of step S1604 is the same as that of step S22 above, and will not be repeated here.

[0305] Step S1605: The electronic device acquires the temperature control parameters of the electronic device.

[0306] The specific implementation method of step S1605 is the same as that of step S33 above, and will not be repeated here.

[0307] In step S1606, the electronic device determines the wireless charging parameters based on the temperature control parameters and the in-situ status.

[0308] The specific implementation method of step S1606 is the same as that of step S34 above, and will not be repeated here.

[0309] Figure 17 This is a diagram illustrating the sensorhub initialization process where only the sensor driver is set up in the sensorhub. Figure 18 This is a schematic diagram illustrating the initialization process for setting up a sensor driver in a sensorhal configuration according to an embodiment of this application. This initialization process is used to detect a virtual magnetic sensor.

[0310] Combination Figure 17 As shown, the initialization process of sensorhub includes the following steps S1701 and S1702.

[0311] S1701, sensorhal finds the SUID of the magnetic sensor on the CP side; SUID is the device ID of the magnetic sensor.

[0312] S1702, if the SUID is obtained, a virtual magnetic sensor is created using the SUID. Obtaining the SUID indicates that the sensor driver of the sensorhub has been detected. The created virtual magnetic sensor is used to replace the sensor driver at the hardware abstraction layer.

[0313] Furthermore, in order to add a sensor driver set at the kernel level on the basis of the existing sensor hub sensor driver, and to integrate the kernel level sensor driver set at the kernel level in sensorhal, in one implementation, the method for determining the wireless charging parameters of the electronic device further includes the following step S4.

[0314] Step S4: Initialize the magnetic sensor in sensorhal to detect the magnetic sensor in sensorhal, thereby facilitating the starting thread of sensorhal to listen to the node of the magnetic sensor.

[0315] For example, the electronic device includes an application processor and a sensor hub, combined with Figure 18 As shown, step S4 includes steps S41 to S44.

[0316] Step S41, sensorhal finds the device ID of the magnetic sensor on the sensorhub side.

[0317] Step S42: If the device ID is not found, locate the target node on the main processor side; the target node is configured to be readable by sensorhal in its on-premises status.

[0318] Step S43: If the target node is found on the main processor side, construct an instance of the magnetic sensor with a virtual ID and rewrite the attributes of the magnetic sensor in the instance.

[0319] In steps S42 and S43, since the virtual ID of the magnetic sensor must be created at the hardware abstraction layer, it is first determined whether there is a sensor driver on the sensorhub side. If there is a sensor driver on the sensorhub side, the SUID of the sensor driver on the sensorhub side is used as the virtual ID for creating the magnetic sensor. If there is no sensor driver on the sensorhub side, it is necessary to search the target node to determine whether there is a sensor driver in the kernel layer. If there is a sensor driver in the kernel layer, the virtual ID of the magnetic sensor needs to be created using the dmd SUID. Furthermore, if the virtual ID of the magnetic sensor is created using the dmd SUID, the parsing results will all be dmd. Therefore, after creating the virtual ID of the magnetic sensor using the dmd SUID, the attributes of the virtual ID of the magnetic sensor also need to be rewritten to ensure that the attributes of the virtual ID of the magnetic sensor are correct. These attributes include information such as type and supported frequencies.

[0320] The original sensor-driven properties are written into SensorHub.

[0321] Step S44: Sensorhal starts a thread to listen to the target node.

[0322] Specifically, the target node in step S1302, the target node in step S43, and the target node in step S44 can be the same node or different nodes.

[0323] For example, the target node in step S43 is the first target node, the target node in step S1302 is the second target node, and the target node in step S44 is the third target node. The first target node is used to indicate whether the sensor driver exists, the second target node is used to indicate whether the level state of the magnetic sensor has changed, and the third target node is used to transmit the presence status of the magnetic accessory.

[0324] Sensorhal and the sensor driver agree on a first target node. Upon detecting this first target node, Sensorhal assumes the sensor driver exists in the kernel layer, facilitating the construction of a virtual magnetic sensor. Sensorhal and the sensor driver agree on a second target node. When the magnetic sensor's voltage level changes, the sensor driver updates the second target node. Sensorhal uses this update to determine that the magnetic sensor's voltage level has changed, indicating a change in the wearing status of the magnetic accessory. Sensorhal and the sensor driver agree on a third target node. When the magnetic sensor's voltage level changes, Sensorhal uses this third target node to read the latest presence status of the magnetic accessory.

[0325] If the magnetic sensor is required, it needs to be activated using the `activate` interface provided by Sensorhal. If the magnetic sensor is not needed, it needs to be deactivated using the `deactivate` interface provided by Sensorhal.

[0326] In one implementation, the method for determining the wireless charging parameters of the electronic device further includes the following step S5 to activate the magnetic sensor.

[0327] Step S5: If the magnetic sensor is registered, activate the magnetic sensor; the interrupt level of the magnetic sensor is used to characterize whether the electronic device is equipped with a magnetic housing.

[0328] In this way, the presence status of the magnetic accessories can be detected through the magnetic sensor.

[0329] Figure 19 This is a flowchart illustrating the method for activating a magnetic sensor provided in an embodiment of this application.

[0330] For example, such as Figure 19 As shown, step S5 includes steps S51 to S57.

[0331] Step S51: In response to the activation command of the magnetic sensor, query the sensor driver of the magnetic sensor on the sensorhub side.

[0332] In step S52, if the query for the magnetic sensor driver on the sensorhub side fails, the kernel-level sensor driver is used to report that the magnetic sensor is enabled and upload the sensor parameters of the magnetic sensor.

[0333] Step S53: If the sensor driver for the magnetic sensor is successfully queried on the sensorhub side, query the magnetic sensor at the kernel layer.

[0334] Step S54: If querying the magnetic sensor driver at the kernel level fails, report that the magnetic sensor is enabled using the hardware interface and upload the sensor parameters of the magnetic sensor. Specifically, the hardware interface is qsh:activate.

[0335] Step S55: If the kernel layer successfully queries the sensor driver of the magnetic sensor, use the kernel layer sensor driver to listen to and parse the target node sent by the kernel layer sensor driver to obtain the sensor parameters of the magnetic sensor.

[0336] Step S56: Use the hardware interface to report that the magnetic sensor is enabled and upload the sensor parameters of the magnetic sensor.

[0337] Step S57: The kernel-level sensor driver reports that the magnetic sensor is enabled and uploads the sensor parameters of the magnetic sensor.

[0338] Specifically, when uploading the sensor parameters of the magnetic sensor using a hardware interface, the sensor parameters include first sensor parameters. When uploading the sensor parameters of the magnetic sensor using a kernel-level sensor driver, the sensor parameters include second sensor parameters. Following steps S56 and S57, the process further includes: fusing the first sensor parameters and the second sensor parameters to obtain the target sensor parameters. The fusing is performed using an "OR" method, meaning the result of either the first sensor parameters or the second sensor parameters is the fused target sensor parameters.

[0339] It should be understood that if the sensor driver is set at the kernel layer, the first sensor parameter may be 0, and the second sensor parameter corresponds to the level signal of a normal magnetic sensor.

[0340] In one implementation, the method for determining the wireless charging parameters of the electronic device further includes the following step S6: to disable the magnetic sensor.

[0341] Step S6: If the Hall sensor is unregistered, disable the Hall sensor.

[0342] Figure 20 This is a schematic diagram of the process for disabling the magnetic sensor provided in an embodiment of this application.

[0343] For example, such as Figure 20 As shown, step S6 includes steps S61 to S68.

[0344] Step S61: In response to the activation command of the magnetic sensor, query the sensor driver of the magnetic sensor on the sensorhub side and the kernel layer respectively.

[0345] In step S62, if the sensor driver for the magnetic sensor is successfully queried on the sensorhub side, the magnetic sensor is reported as disabled using the hardware interface.

[0346] Step S63: If the kernel layer successfully queries the sensor driver of the magnetic sensor, the kernel layer sensor driver is used to report that the magnetic sensor is disabled.

[0347] In this way, whether it is a sensor driver with a magnetic sensor on the sensorhub side or a sensor driver with a magnetic sensor in the kernel layer, it can report the instruction to disable the magnetic sensor.

[0348] Figure 21 A schematic diagram of a device for determining wireless charging parameters of an electronic device provided in an embodiment of this application.

[0349] Combination Figure 21 As shown, corresponding to the method for determining wireless charging parameters of an electronic device provided in the above embodiments, this application embodiment also provides a device 2100 for determining wireless charging parameters of an electronic device, applied to an electronic device. The device includes: an acquisition module 2101, configured to: the electronic device acquire sensor signals of a magnetic sensor through a sensor driver located in the kernel layer of the operating system; and a determination module 2102, configured to: the electronic device determine the presence status of a magnetic accessory based on the sensor signal; the presence status indicates whether the electronic device is equipped with a magnetic accessory; and the electronic device determines the wireless charging parameters of the electronic device based on the presence status.

[0350] Figure 22 This is a schematic diagram of the chip system provided in the embodiments of this application.

[0351] like Figure 22 As shown, this application embodiment also provides a chip system 2200, such as a SoC, which includes at least one processor 2201 and at least one interface circuit 2202. The processor 2201 and the interface circuit 2202 can be interconnected via lines. For example, the interface circuit 2202 can be used to receive signals from other devices (e.g., the memory of an electronic device). As another example, the interface circuit 2202 can be used to send signals to other devices (e.g., the processor 2201 or the touchscreen of an electronic device). Exemplarily, the interface circuit 2202 can read instructions stored in the memory and send the instructions to the processor 2201. When the instructions are executed by the processor 2201, the electronic device can perform the steps in the above embodiments. Of course, the chip system may also include other discrete devices, which are not specifically limited in this application embodiment.

[0352] This application also provides a computer-readable storage medium including computer instructions that, when executed on the electronic device, cause the electronic device to perform various functions or steps performed by the electronic device in the above method embodiments.

[0353] This application also provides a computer program product that, when run on an electronic device, causes the electronic device to perform various functions or steps performed by the electronic device in the above method embodiments.

[0354] Through the above description of the embodiments, those skilled in the art can clearly understand that, for the sake of convenience and brevity, only the division of the above functional modules is used as an example. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above.

[0355] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another apparatus, or some features may be ignored or not executed. Furthermore, the mutual coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0356] The units described as separate components may or may not be physically separate. A component shown as a unit can be one or more physical units; that is, it can be located in one place or distributed in multiple different locations. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0357] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0358] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a readable storage medium. Based on this understanding, the technical solutions of the embodiments of this application, essentially or in other words, the parts that contribute to the prior art, or all or part of the technical solutions, can be embodied in the form of a software product. This software product is stored in a storage medium and includes several instructions to cause a device (which may be a microcontroller, chip, etc.) or processor to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0359] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any changes or substitutions within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0360] It should be noted that those skilled in the art, upon considering the specification and practicing the application disclosed herein, will readily conceive of other embodiments of this application. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein. The specification and embodiments are to be considered exemplary only, and the true scope of this application is indicated by the claims.

[0361] It should be understood that this application is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.

Claims

1. A method for determining wireless charging parameters for electronic devices, characterized in that, include: The electronic device acquires the sensor signal from the magnetic sensor through a sensor driver located in the operating system kernel layer; The electronic device determines the presence status of the magnetic accessory based on the sensor signal; the presence status indicates whether the electronic device is equipped with the magnetic accessory. The electronic device determines its wireless charging parameters based on its in-situ status.

2. The method according to claim 1, characterized in that, The electronic device determines its wireless charging parameters based on the in-situ state, including: The electronic device acquires the temperature control parameters of the electronic device; The electronic device determines the wireless charging parameters based on the temperature control parameters and the in-situ status.

3. The method according to claim 2, characterized in that, The electronic device acquires its temperature control parameters, including: The electronic device determines its temperature control parameters based on its operating status. The operating state of the electronic device includes at least one of the following: screen on, screen off, and power off.

4. The method according to claim 3, characterized in that, The electronic device determines its temperature control parameters based on its operating status, including: When the electronic device is in the screen-on state, the electronic device determines a first temperature control parameter; When the electronic device is in the screen-off state or the power-off state, the electronic device determines the second temperature control parameter; The first temperature control parameter is different from the second temperature control parameter.

5. The method according to claim 4, characterized in that, The electronic device determines the first temperature control parameter, including: The sensor driver sends the in-situ status to the sensor hardware abstraction layer located in the operating system hardware abstraction layer. The sensor hardware abstraction layer sends the in-situ status to the target application located in the operating system application layer; The target application determines the first temperature control parameter based on the in-situ state.

6. The method according to claim 5, characterized in that, The sensor driver sends the in-situ state to the sensor hardware abstraction layer located in the operating system hardware abstraction layer, including: The sensor driver updates the target node; the target node is a node or node path pre-agreed between the sensor driver and the sensor hardware abstraction layer. After the sensor hardware abstraction layer detects a state change in the target node, it obtains the in-situ state from the sensor driver.

7. The method according to claim 5, characterized in that, The sensor driver sends the in-situ state to the sensor hardware abstraction layer located in the operating system hardware abstraction layer, including: The sensor driver broadcasts the in-situ status via a target event; After the sensor hardware abstraction layer detects the target event, it parses the target event to obtain the in-situ state.

8. The method according to claim 5, characterized in that, The electronic device determines the wireless charging parameters based on the temperature control parameters and the in-situ status, including: The target application sends the first temperature control parameter to the charging driver located in the operating system kernel layer; The charging driver determines the wireless charging parameters based on the first temperature control parameter and the in-situ state.

9. The method according to any one of claims 1 to 8, characterized in that, The electronic device acquires the sensor signal from the magnetic sensor through a sensor driver located in the operating system kernel layer, including: The sensor driver detects a change in the sensor signal; The sensor driver reads the sensor signal through a pre-registered first callback function.

10. The method according to any one of claims 1 to 8, characterized in that, The electronic device determines the presence status of the magnetic accessory based on the sensor signal, including: The sensor driver determines the level state of the sensor signal; The sensor driver determines the in-situ state of the magnetic accessory based on the level state of the sensor signal.

11. The method according to claim 10, characterized in that, The sensor driver determines the presence state of the magnetic accessory based on the level state of the sensor signal, including: When the level is high, it is determined that the presence state is that the electronic device is equipped with the magnetic accessory; When the level is low, the presence status is determined to be that the electronic device is not equipped with the magnetic accessory.

12. The method according to any one of claims 1 to 8, characterized in that, The electronic device determines its wireless charging parameters based on the in-situ state, and further includes: The sensor driver sends the in-situ status to the charging driver located in the operating system kernel layer; The charging driver determines the wireless charging parameters of the electronic device based on the in-situ state.

13. The method according to claim 12, characterized in that, The sensor driver sends the in-situ state to the charging driver located in the operating system kernel layer, including: The sensor driver creates the first interface; The charging driver registers a second callback function on the first interface; The sensor driver sends the in-situ status to the charging driver via the second callback function.

14. The method according to claim 12, characterized in that, The sensor driver sends the in-situ state to the charging driver located in the operating system kernel layer, including: The charging driver creates a second interface; The sensor driver sends the in-situ status to the charging driver via the second interface.

15. An electronic device, characterized in that, include: A memory and one or more processors; the memory is coupled to the processors; wherein the memory stores computer program code, the computer program code including computer instructions, which, when executed by the processor, cause the electronic device to perform a method for determining wireless charging parameters of the electronic device as claimed in any one of claims 1 to 14.

16. A computer-readable storage medium, characterized in that, Includes computer instructions that, when executed on an electronic device, cause the electronic device to perform a method for determining wireless charging parameters of the electronic device as described in any one of claims 1 to 14.

17. A computer program product, characterized in that, When the computer program product is run on a computer, it causes the computer to perform the method for determining wireless charging parameters of an electronic device as described in any one of claims 1 to 14.

Images