Telephony process optimization system and method of vehicle-mounted TBox, electronic equipment and storage medium
By introducing HAL and SOA units into the vehicle infotainment system and optimizing the Android Telephony architecture, the compatibility and maintenance cost issues of network status acquisition on the vehicle infotainment system were resolved, enabling friendly access for third-party applications and real-time network status updates.
Patent Information
- Application Number
- CN202510750228.0
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-06-06
- Publication Date
- 2025-10-17
AI Technical Summary
Android's native Telephony architecture struggles to support network status acquisition in in-vehicle systems, making it unfriendly for third-party application development, difficult to achieve universality and compatibility, and resulting in high maintenance costs.
By trimming the native telephony architecture, introducing HAL and SOA units, using Android's native telephony interface to obtain network status, designing a caching mechanism and standardized data structures, cross-process communication is achieved, simplifying hardware adaptation and version updates.
It achieves compatibility between third-party applications and native interfaces on the vehicle's infotainment system, reduces maintenance costs and development difficulty, improves the robustness and adaptability of the system, and ensures real-time updates and accuracy of network status information.
Smart Images
Figure CN120803567A_ABST
Abstract
Description
TECHNICAL FIELD
[0001] The application relates to the field of vehicle-mounted communication, in particular to a Telephony process optimization system of a vehicle-mounted TBox, a Telephony process optimization method of the vehicle-mounted TBox, an electronic device and a storage medium. BACKGROUND
[0002] The Android native Telephony architecture is based on a mobile phone, and on a vehicle machine, there is no RIL process and modem process, only a SIM card can be inserted into the TBox to access a 4G / 5G network, and then how an Android application obtains the network status of the TBox installed on the vehicle machine, such as signal strength, network standard and the like, is a problem that needs to be considered.
[0003] The Android native Telephony is not friendly to the vehicle machine, and the Telephony architecture itself is very complex, in order to support the acquisition of the TBox network status on the vehicle machine, some manufacturers may write an adaptation layer, and do not use the native Telephony interface, which is not friendly to third-party application development, and cannot be used for general development based on the ROM platform, and the ROM platform needs to open an interface to be used by the third-party application. SUMMARY
[0004] Therefore, the purpose of the application is to provide a Telephony process optimization system of a vehicle-mounted TBox, a Telephony process optimization method of the vehicle-mounted TBox, an electronic device and a storage medium, the application matches the TBox by cutting the native telephony architecture, uses the android native telephony interface to obtain the network status, and does not distinguish between manufacturer private applications and third-party applications, and both can be obtained, only the Telephony needs to be connected to the TBox in the Android system layer, in addition, the native Telephony architecture can be slightly changed, which is convenient for Android upgrading in the future, and at the same time, the interface change brought by the TBox upgrading can be compatible, and the maintenance cost is low.
[0005] The application provides the following scheme:
[0006] According to one aspect of the application, a Telephony process optimization system of a vehicle-mounted TBox is provided, comprising an Android application layer, a framework layer, a framework-services framework service layer, a HAL unit, a SOA unit and a TBox unit.
[0007] Android application layer, used for obtaining phone related information or listening to phone state changes by monitoring and obtaining operations, calling the TelephonyManager interface of the framework layer;
[0008] framework framework layer, comprising: TelephonyManager interface and TelephonyRegistryManager interface, used for accepting monitoring and obtaining requests from the Android application layer, and calling the TelephonyRegistry unit;
[0009] framework-services framework service layer, comprising: TelephonyRegistry unit, receiving requests of the framework framework layer, and calling the HAL unit;
[0010] HAL unit, used for calling data information of the SOA unit, and providing the called data information to
[0011] TelephonyRegistry unit;
[0012] SOA unit, used for calling data information of the TBox unit, and providing the called data information to
[0013] HAL unit;
[0014] TBox unit, used for providing network state information, and receiving calls of the SOA unit.
[0015] Further, comprising:
[0016] SOA unit obtains network state information of the TBox unit through the SOMEIP mechanism;
[0017] The system supports 4G / 5G network access of the TBox unit, and maps the network state information to the TelephonyRegistry unit through the HAL unit.
[0018] Further, comprising:
[0019] The SOA unit internally contains a designable cache mechanism, which receives network state information reported by the TBox unit through the SOMEIP mechanism in real time, and transmits the received data to the HAL unit after preprocessing.
[0020] Further, comprising:
[0021] Android application layer, comprising: car machine private application and third party application, calling network state information through the TelephonyManager interface.
[0022] Further comprising:
[0023] The TelephonyRegistry unit of the framework layer receives a listening request of the Android application layer through the TelephonyRegistryManager interface, and transmits network state information to the HAL unit through an AIDL mechanism.
[0024] Further comprising:
[0025] The HAL unit and the SOA unit adopt a lightweight communication protocol to transmit network state information by defining a standardized data structure;
[0026] The network state information includes signal strength, service state, cell information and cell location.
[0027] According to the two aspects of the present application, a Telephony process optimization method of a vehicle-mounted TBox is provided, and the Telephony process optimization method of the vehicle-mounted TBox comprises:
[0028] Initiating a network state listening or obtaining request through an Android application layer;
[0029] The TelephonyRegistry unit of the framework layer receives the listening or obtaining request, and forwards the listening or obtaining request to the HAL unit through a TelephonyRegistryManager interface;
[0030] The HAL unit receives the listening or obtaining request through an AIDL interface, adapts the data format and the interface, and generates a standardized network state query instruction;
[0031] The SOA unit sends the standardized network state query instruction to the TBox unit based on a vehicle-mounted Ethernet SOMEIP protocol, and receives network state information returned by the TBox unit in real time;
[0032] The SOA unit transmits the received network state information to the HAL unit after preprocessing;
[0033] The HAL unit returns the returned network state information to the TelephonyRegistry unit through the framework layer;
[0034] The TelephonyRegistry unit pushes the returned network state information to the Android application layer, and completes dynamic updating of the network state of the TBox unit.
[0035] The SOA unit pre-processes the received network state information, including: checking the network state information returned by the TBox unit, and eliminating abnormal values;
[0036] Converting the signal strength, network mode and cell location information into a standardized format;
[0037] Adding a timestamp and data source identifier to ensure data traceability.
[0038] According to the three aspects of the application, an electronic device is provided, comprising: a processor, a communication interface, a memory and a communication bus, wherein the processor, the communication interface and the memory complete communication with each other through the communication bus.
[0039] The memory stores a computer program, and when the computer program is executed by the processor, the processor executes the steps of the Telephony process optimization method of the vehicle-mounted TBox.
[0040] According to the four aspects of the application, a computer readable storage medium is provided, which stores a computer program executable by an electronic device, and when the computer program runs on the electronic device, the electronic device executes the steps of the Telephony process optimization method of the vehicle-mounted TBox.
[0041] Through the above scheme, the following beneficial technical effects are obtained:
[0042] The native interface provided by the APP is maintained unchanged, and the underlying maximizes the reuse of the Android Telephony native data structure and architecture, such as the native data structures SignalStrength signal strength, ServiceState service state, CellInfo cell information and CellLocation cell location information, etc. On the android Telephony framework side, only the newly added HAL process needs to be accessed through AIDL, and subsequent upgrades of the Android version can also be maintained with less manpower.
[0043] The application cuts the original Phone process and RIL process, introduces a newly added HAL process and SOA process, and the vehicle TBox unit is different from the original Phone process. For the vehicle TBox unit, the business processing is relatively simple, the function is relatively single, the TelephonyRegistry service is accessed, and subsequent maintenance is also convenient.
[0044] The application designs SOA process to communicate between vehicle-mounted Ethernet through SOMEIP, SOA is the signal integrated end as a whole, can receive or request the signal of each ECU in the vehicle machine, TBox is one of the ECUs in the vehicle machine, SOA can obtain the network state information of TBox through SOMEIP mechanism, the change of TBox network state information will also be timely informed to SOA process, the information in SOA process can be designed to have a cache mechanism; in this way, the SOA process can be adapted to TBox version update, signal change and the like, and the adaptability is enhanced. BRIEF DESCRIPTION OF DRAWINGS
[0045] Figure 1 is a flow chart of a Telephony process optimization system of a vehicle-mounted TBox provided by one or more embodiments of the application.
[0046] Figure 2 is a structural diagram of a Telephony process optimization method of a vehicle-mounted TBox provided by one or more embodiments of the application.
[0047] Figure 3 is a framework diagram of an Android Telephony native data structure of the prior art.
[0048] Figure 4 is a framework diagram of an improved Android Telephony data structure.
[0049] Figure 5 is a structural block diagram of an electronic device of a Telephony process optimization method of a vehicle-mounted TBox provided by one or more embodiments of the application. DETAILED DESCRIPTION
[0050] The technical solutions of the application will be described clearly and completely below with reference to the drawings, obviously, the described embodiments are part of the embodiments of the application, rather than all the embodiments. Based on the embodiments in the application, all other embodiments obtained by those skilled in the art without creative labor fall within the protection scope of the application.
[0051] Figure 1 is a flow chart of a Telephony process optimization system of a vehicle-mounted TBox provided by one or more embodiments of the application.
[0052] As Figure 1 shown, a Telephony process optimization system of a vehicle-mounted TBox includes:
[0053] Android application layer, framework layer, framework-services layer, HAL unit, SOA unit and TBox unit;
[0054] The Android application layer is configured to acquire phone related information or listen to phone state changes by monitoring and acquiring operations, calling the TelephonyManager interface of the framework layer;
[0055] The framework layer includes a TelephonyManager interface and a TelephonyRegistryManager interface, which are configured to accept monitoring and acquisition requests from the Android application layer and call the TelephonyRegistry unit;
[0056] The framework-services layer includes a TelephonyRegistry unit, which is configured to receive requests from the framework layer and call the HAL unit;
[0057] The HAL unit is configured to call data information of the SOA unit and provide the called data information to the
[0058] TelephonyRegistry unit;
[0059] The SOA unit is configured to call data information of the TBox unit and provide the called data information to the
[0060] HAL unit;
[0061] The TBox unit is configured to provide network state information and receive calls from the SOA unit.
[0062] Specifically, by adding the HAL unit, the problem of heterogeneous hardware adaptation difficulty is solved. The Telephony function (such as signal, service state) directly depends on the underlying hardware driver. The interface difference of different manufacturers' hardware (such as Modem, TBox) leads to Framework code redundancy and high adaptation cost. The newly added HAL process is used as an intermediate layer to encapsulate hardware details, so that Framework only needs to call a unified interface (such as getSignalStrength()), without the need to pay attention to the difference between hardware manufacturers, thereby solving the problem of multi-hardware adaptation.
[0063] In the original architecture, the Telephony function is deeply coupled with the Android system process (such as system_server), and hardware crashes can easily cause system service abnormalities. The HAL process is an independent daemon (such as telephony_hal_daemon) that is decoupled from the Android process, so even if the Framework crashes, it can still provide basic Telephony services (such as emergency call signal monitoring), improving system robustness.
[0064] In traditional code, hardware updates (such as Modem firmware upgrades) require synchronous modification of the Framework, leading to multi-version adaptation problems. The HAL layer focuses on hardware / SOA adaptation, and later hardware upgrades only need to update the HAL code, with zero modification of the Framework layer, reducing regression testing scope and maintenance costs.
[0065] HAL provides standardized interfaces, such as the ITelephonyHal defined by Hidl, and the Framework obtains state data in a unified format (such as SignalStrength, ServiceState) through the interface, achieving one-time development and multi-hardware adaptation.
[0066] The HAL unit converts data according to the SOA protocol, for example, parsing the TBox network state of SOA into the ServiceState of Framework, shielding the differences in underlying protocols and supporting rapid adaptation of multiple SOA versions.
[0067] The HAL process runs independently, and resource scheduling (CPU, memory) is separated from the Android process, avoiding mutual influence. Even if the Framework crashes, HAL can still maintain basic communication functions (such as signal monitoring), improving system reliability (similar to the design of the RILD daemon, refer to the Android RIL architecture).
[0068] Fault isolation: when the SOA process is abnormal, such as TBox communication interruption, HAL can cache historical data or trigger a retry mechanism, reducing the impact on the Framework and ensuring the continuity of Telephony services.
[0069] Further, through the SOA process, the vehicle-mounted Ethernet communicates through SOMEIP, and the SOA is the signal integration end of the whole system, which can receive or request the signals of each ECU in the car machine. The TBox is one of the ECUs in the car machine, and the SOA can obtain the network state information of the TBox through the SOMEIP mechanism. When the network state information of the TBox changes, the SOA process will be timely notified, and the information can be cached in the SOA process. In this way, the SOA process can adapt to the TBox version update and signal change. On the other hand, by adding a HAL process in the SOA process and the Telephony interface, the problem of SOA process version update and Android version update and the subsequent architecture compatibility problem can be solved.
[0070] 1. The SOA process is responsible for the signals between different ECUs in the car machine, and the version iteration is very frequent. Once the network state signal changes, the Telephony also needs to be modified synchronously.
[0071] 2. If the Android version is upgraded, the architecture and interface of the Telephony will probably change, and the adaptation workload of the androidtelephony framework will be large, and the cost of manpower and maintenance will also be large.
[0072] 3. If the SOA process is no longer used in the future, the adaptation workload of the Telephony will also be large.
[0073] In summary, a HAL process is added to adapt to the Telephony and the SOA process, and the HAL process is independent of the android process, and the version maintenance and iteration in the later stage are low, and the development efficiency of the android framework will be further improved.
[0074] Further, including:
[0075] The SOA unit obtains the network state information of the TBox unit through the SOMEIP mechanism.
[0076] The system supports 4G / 5G network access of the TBox unit, and maps the network state information to the TelephonyRegistry unit through the HAL unit.
[0077] Specifically, the TBox unit adopts different network standards such as 4G / 5G, and its internal communication protocol (such as private API, custom data format) is incompatible with the SOMEIP (Service-Oriented Middleware Protocol) of the SOA unit for service discovery and communication in scenarios such as Internet of Vehicles. The SOA unit encapsulates the network state acquisition logic of the TBox through the SOMEIP mechanism, and converts the heterogeneous network data of the TBox (such as the RRC state of 4G and the NR connection state of 5G) into a SOMEIP service interface (such as getNetworkState()), solving the protocol adaptation problem under multiple network standards and avoiding the SOA layer directly processing complex hardware network protocols.
[0078] The network state of the TBox (such as signal strength, connection mode) needs to be transmitted through multiple protocol stacks (such as CAN bus→gateway→Framework), resulting in state update lag (such as 4G / 5G switching, Framework cannot timely perceive). The service-oriented communication of SOMEIP (supporting event subscription, asynchronous notification) makes the network state change of the TBox real-time pushed to the SOA unit (such as TBox detects 5G connection establishment, immediately notifies SOA through SOMEIP event), reducing state synchronization delay and improving the timeliness of state update of the TelephonyRegistry unit (such as quickly updating the network type of ServiceState).
[0079] Different manufacturers' TBox (such as vehicle communication module, Internet of Things terminal) may adopt different hardware schemes (such as Qualcomm / MediaTek Modem chips), and their network state acquisition interfaces (such as AT instruction set, private driver API) differ greatly. The SOA unit abstracts the hardware details of the TBox through SOMEIP, providing standardized network state services (such as NetworkStateService) to the upper layer, so that the HAL unit only needs to call the SOMEIP service of the SOA (rather than directly operating the TBox hardware), reducing the hardware coupling degree of HAL and TBox, and simplifying the state mapping logic of TelephonyRegistry (such as unified processing of 4G / 5G CellInfo data).
[0080] The SOA unit performs redundant verification on the network state data of the TBox (such as multi-source data fusion, simultaneously acquiring Modem state and GNSS positioning data of the TBox, verifying the authenticity of network connection), when the TBox has communication failure (such as 4G signal loss), the SOA can cache historical state or switch to backup link (such as 5G fallback to 4G), ensuring the continuity of state data of TelephonyRegistry, and improving system reliability (such as signal state availability during emergency call).
[0081] TBox network state changes (such as signal strength mutation, 4G→5G switching) notify the SOA through SOMEIP events, and the HAL immediately updates the TelephonyRegistry, reducing the state synchronization delay from seconds to milliseconds, and improving user experience.
[0082] Further, comprising:
[0083] The SOA unit internally contains a cache mechanism that can be designed to receive real-time network status information reported by the TBox unit through the SOMEIP mechanism, and transmit the preprocessed data to the HAL unit after receiving the data.
[0084] Specifically, through the cache mechanism, the network status reported by TBox through SOMEIP (such as 4G / 5G signal, service state) is cached, and when HAL repeatedly requests, the preprocessed data (such as parsed into ServiceState objects) is directly read from the cache, avoiding repeated parsing of TBox original data (reducing CPU calculation) and SOMEIP network communication (reducing IO delay). For example, when querying 5G signal strength frequently, cache hit can make the response time from milliseconds to microseconds, improving the efficiency of TelephonyRegistry state update.
[0085] The preprocessed intermediate data (such as CellInfo format conversion results) is cached, and HAL does not need to wait for SOA to reprocess, and the data transmission efficiency is improved by more than 50% (especially suitable for TBox state high-frequency change scenarios such as base station switching when moving at high speed, reducing invalid data transmission).
[0086] Further, comprising:
[0087] The Android application layer includes: car private applications and third-party applications, which call network status information through the TelephonyManager interface.
[0088] Specifically, by cutting the original Phone process and RIL process, other APPs and Telephony remain unchanged, and car private applications and third-party applications can call the original Telephony interface for development.
[0089] Further, comprising:
[0090] The TelephonyRegistry unit of the framework layer receives the listening request of the Android application layer through the TelephonyRegistryManager interface, and transmits the network status information to the HAL unit through the AIDL mechanism.
[0091] Specifically, multiple data types (basic types, Parcelable, List / Map, etc.) are supported through the AIDL mechanism, and through automatic serialization / deserialization, the data format differences between different processes (Framework / HAL) are solved. For example, the SOMEIP protocol data (binary) of TBox can be converted into a CellInfo object recognizable by the Framework through AIDL, ensuring cross-process data consistency.
[0092] The AIDL interface serves as a contract, allowing the Framework (business logic) and the HAL (hardware adaptation) to be completely decoupled. Both sides only need to follow the interface and can be independently iterated (e.g., when the HAL is upgraded to SOA adaptation, the Framework does not need to be modified), improving code maintainability. For example, to add 5G network state reporting, only the AIDL interface and the HAL implementation need to be extended, and the Framework layer can access it transparently through the interface. The AIDL interface isolates business logic (Framework) from hardware adaptation (HAL), allowing both sides to be developed independently (e.g., the Framework team focuses on call functions, and the HAL team focuses on TBox / SOA adaptation), improving team collaboration efficiency.
[0093] AIDL automatically generates cross-process communication code, allowing developers to focus on business logic (e.g., the Framework side handles TelephonyRegistry status, and the HAL side analyzes TBox data), reducing development workload (compared to manual Binder development, code volume reduced by more than 50%). For example, to add network state listening functionality, only the AIDL interface needs to be defined, without the need to write the onTransact method of Binder.
[0094] Maintenance costs are reduced: interface definitions are clear, and modules can be independently upgraded (e.g., when the HAL adapts a new TBox, the Framework is compatible through the interface), reducing regression testing scope. For example, TBox protocol upgrades only require updating the AIDL implementation of the HAL, with zero modifications to the Framework layer.
[0095] Further, including:
[0096] The HAL unit and the SOA unit use a lightweight communication protocol to transfer network status information through the definition of standardized data structures;
[0097] The network status information includes: signal strength, service status, cell information, and cell location.
[0098] It is worth noting that although the system only discloses the Android application layer, the framework layer, the framework-services framework service layer, the HAL unit, the SOA unit and the TBox unit, it does not mean that the device is limited to the above basic function modules. On the contrary, the meaning expressed by the present application is that on the basis of the above basic function modules, those skilled in the art can add one or more function modules to form infinite embodiments or technical solutions in combination with the prior art. That is to say, the system is open rather than closed, and the protection scope of the present application claimed in the present embodiment cannot be limited to the above disclosed basic function modules.
[0099] Figure 2 is a flow chart of a Telephony process optimization method of a vehicle-mounted TBox provided by one or more embodiments of the present application.
[0100] As shown in Figure 2 , a Telephony process optimization method of a vehicle-mounted TBox includes:
[0101] Step S1, initiating a network state listening or obtaining request through the Android application layer;
[0102] Step S2, the TelephonyRegistry unit of the framework layer receives the listening or obtaining request, and forwards the listening or obtaining request to the HAL unit through the TelephonyRegistryManager interface;
[0103] Step S3, the HAL unit receives the listening or obtaining request through the AIDL interface, adapts the data format and interface, and generates a standardized network state query instruction;
[0104] Step S4, the SOA unit sends the standardized network state query instruction to the TBox unit based on the vehicle-mounted Ethernet SOMEIP protocol, and receives the network state information returned by the TBox unit in real time;
[0105] Step S5, the SOA unit transmits the received network state information to the HAL unit after preprocessing;
[0106] Step S6, the HAL unit returns the returned network state information to the TelephonyRegistry unit through the framework layer;
[0107] Step S7, the TelephonyRegistry unit pushes the returned network status information to the Android application layer, completing the dynamic update of the network status of the TBox unit.
[0108] Specifically, by the above method, the technical problem of how to optimize access to Android Telephony, both providing the original interface to the APP unchanged, and accessing TBox, is solved.
[0109] By cutting the original Phone process and RIL process, and using the newly added HAL process and SOA process, it is convenient for later maintenance. Because the functions of TBox and the original Modem are similar, chip manufacturers can develop independently, improving the development efficiency. And the original Telephony interface can be called by the car machine private application and the third party application for development. Through the use of SOA process, the TBox version is more easily adapted.
[0110] By adding the HAL process, the Telephony can be adapted, and the SOA process can be adapted. Moreover, the HAL process is independent of the android process, and the later version maintenance and iteration is very low, and the android framework development process will also be improved.
[0111] Further, it includes:
[0112] Step S51, the SOA unit pre-processes the received network status information, including: checking the network status information returned by the TBox unit, and eliminating abnormal values;
[0113] Converting signal strength, network mode and cell location information into a standardized format;
[0114] Adding a timestamp and data source identifier to ensure data traceability.
[0115] Among them, the network status (such as signal strength, cell location) returned by TBox may have abnormal values (such as signal strength of-200dBm) due to hardware failure, environmental interference (such as electromagnetic shielding). SOA eliminates abnormal values through threshold checking (such as signal strength range-110dBm to-30dBm), time series continuity detection (such as mutation exceeding 50dBm / s), avoiding false data pollution to the Framework layer (such as TelephonyRegistry misjudging as "no signal" leading to call interruption).
[0116] Check the integrity of the TBox reporting information (such as checking whether CellInfo contains necessary fields) to prevent Framework parsing crashes due to missing fields (such as the missing nrCellIdentity field in 5G networks). Verify that data has not been tampered with through CRC checks or message signature (such as preventing man-in-the-middle attacks from forging network status).
[0117] Different manufacturers' TBox network status data formats differ greatly (such as Qualcomm Modem returning LTE_SIGNAL_STRENGTH and Mediatek returning RSSI). SOA standardizes signal strength (such as RSRP, RSRQ), network type (4G / 5G), cell location (CI, PCI), and other information into a unified format (such as the getDbm() method of the SignalStrength class), allowing the Framework layer to focus on hardware differences and reducing adaptation costs (new TBox only needs to extend SOA parsing logic).
[0118] Add precise timestamps (such as UTC time) to record the absolute time of state changes, solving the timing ambiguity problem when synchronizing data across layers (TBox→SOA→HAL→Framework) (such as locating 5G handover failures by correlating logs at each layer using timestamps).
[0119] Mark data sources (such as TBox model and firmware version) to quickly trace the source of problems (such as signal analysis defects in a batch of TBox firmware) when network anomalies occur (such as frequent disconnections), improving troubleshooting efficiency (from hours to minutes).
[0120] Timestamps and data source identifiers shorten the time to locate faults from hours to minutes. For example, by correlating the 5G handover failure time reported by TBox with SOA logs using timestamps, we quickly discover defects in the 5G camping algorithm of a certain model of TBox, accelerating problem resolution (from 24 hours to 2 hours).
[0121] Perform time-consuming operations such as data validation and format conversion in the SOA layer to avoid repeated processing in the Framework layer (such as HAL only needs to receive standardized data and pass it directly to TelephonyRegistry), reducing cross-process communication data volume (such as compressing original SOMEIP messages from KB level to Byte level for standardized objects), and reducing system resource consumption (CPU and memory usage reduced by more than 30%).
[0122] Figure 3 Framework diagram of Android Telephony native data structure in the prior art.
[0123] In the prior art, the Android native Telephony architecture includes:
[0124] App sets listen and get through the TelephonyManager interface, and TelephonyManager calls different modules according to different functions:
[0125] The network state is set to the TelephonyRegistry service, and the network state reported by the Modem is transmitted to the TelephonyRegistry through RILD-->RILJ-->ServiceStateTracker-->Phone-->DefaultPhoneNotifier-->TelephonyRegistryManager, and the TelephonyRegistry service notifies the APP of the corresponding network state, such as SignalStrength (signal strength), ServiceState (service state), CellInfo (cell information), CellLocation (cell location), and other telephone-related state information, so that the APP can listen to the change of the Modem network state. Among them, the TelephonyRegistry service is one of the core components for listening to the network state, and the TelephonyRegistry acts as a central hub to receive state changes from RIL and then uniformly distribute them to all registered listeners, avoiding repeated queries and conflicts.
[0126] RILJ interacts with RILD (C++ layer radio interface layer daemon process), and RILD ultimately communicates with Modem (modem, hardware layer) to realize the control and information acquisition of the telephone hardware.
[0127] TelephonyRegistry acts as an intermediate layer, encapsulates the implementation details of the bottom layer, and provides a stable interface to the upper layer. For example, whether the bottom layer uses RIL or HAL, the application always receives the state through PhoneStateListener.
[0128] The network state is set to the TelephonyRegistry service, and the network state reported by the Modem is transmitted to the TelephonyRegistry through RILD-->RILJ-->ServiceStateTracker-->Phone-->DefaultPhoneNotifier-->TelephonyRegistryManager, and the TelephonyRegistry service notifies the APP of the corresponding network state, such as SignalStrength (signal strength), ServiceState (service state), CellInfo (cell information), CellLocation (cell location), and other telephone-related state information, so that the APP can listen to the change of the Modem network state. Among them, the TelephonyRegistry service is one of the core components for listening to the network state, and the TelephonyRegistry acts as a central hub to receive state changes from RIL and then uniformly distribute them to all registered listeners, avoiding repeated queries and conflicts.
[0129] Wherein, PhoneInterfaceManager is a core component in Android Telephony Framework, responsible for handling the communication between application layer and phone service. It runs as a system service, manages all interactions related to phone status, call control, SIM card operation, and is the main entry point for upper layer applications to access underlying communication functions.
[0130] Figure 4 The framework diagram of the improved Android Telephony data structure of the application.
[0131] Unlike the prior art, the original Phone process and RIL process are cut, and the HAL process and SOA process are used instead.
[0132] The listen interface remains unchanged and is set to the TelephonyRegistry service. The newly added HAL process is also reported to the TelephonyRegistry through the TelephonyRegistryManager interface.
[0133] By changing the get interface, it is set to the TelephonyRegistry service through the TelephonyRegistryManager interface, and then called into the newly added HAL process through the AIDL mechanism. However, the interface provided to the APP remains unchanged, and the APP can continue to use the original interface. The original Phone process carries many businesses, not only listening and getting network status, but also making and receiving calls, data switching, etc. Moreover, the original Android supports multiple SIM cards, and distinguishes IMS, GSM, CDMA, etc. according to network standards. For the TBox, the business is relatively simple, and the function is relatively single, so it is not necessary to connect the Phone process. We can directly access the TelephonyRegistry service, which is convenient for maintenance in the future.
[0134] Figure 5 The electronic device structure block diagram of the Telephony process optimization method of the vehicle-mounted TBox provided by one or more embodiments of the application.
[0135] As shown in Figure 5 The application provides an electronic device, which comprises a processor, a communication interface, a memory and a communication bus, wherein the processor, the communication interface and the memory complete mutual communication through the communication bus.
[0136] The memory stores a computer program, and when the computer program is executed by the processor, the processor executes the steps of the Telephony process optimization method of the vehicle-mounted TBox.
[0137] The application also provides a computer readable storage medium, which stores a computer program executable by an electronic device, and when the computer program runs on the electronic device, causes the electronic device to execute the steps of the method for optimizing the Telephony process of the vehicle-mounted TBox.
[0138] For the method embodiments, in order to simply describe, they are all expressed as a series of action combinations, but those skilled in the art should know that the embodiments of the present application are not limited to the order of the actions described, because according to the embodiments of the present application, certain steps can be performed in other order or simultaneously. Secondly, those skilled in the art should know that the embodiments described in the specification all belong to preferred embodiments, and the actions involved are not necessarily essential for the embodiments of the present application.
[0139] From the above description of the embodiments, those skilled in the art can clearly understand that the present application can be implemented by means of software and the necessary universal hardware platform. Based on such understanding, the technical solutions of the present application can be embodied in the form of a software product, which can be stored in a storage medium, such as a ROM / RAM, a magnetic disk, an optical disk, etc., and includes a number of instructions for causing a computer device (which can be a personal computer, a server or a network device, etc.) to execute the methods described in the various embodiments or some parts of the embodiments of the present application.
[0140] Finally, it should be noted that: the above embodiments are only used to illustrate the technical solutions of the present application, and not to limit them; although the present application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that: it can still modify the technical solutions recorded in the foregoing embodiments, or make equivalent replacement for some or all of the technical features; and these modifications or replacements do not make the essence of the corresponding technical solutions deviate from the scope of the technical solutions of the embodiments of the present application.
Claims
1. A telephony process optimization system for a vehicle-mounted TBox, characterized in that: include: Android application layer, framework layer, framework-services framework service layer, HAL unit, SOA unit and TBox unit; The Android application layer is used to obtain phone-related information or monitor phone status changes by calling the TelephonyManager interface of the framework layer through monitoring and acquisition operations; The framework layer includes the TelephonyManager interface and the TelephonyRegistryManager interface, which are used to accept monitoring and acquisition requests from the Android application layer and call the TelephonyRegistry unit; The framework-services framework service layer includes the TelephonyRegistry unit, which receives requests from the framework layer and calls the HAL unit; The HAL unit is used to call the SOA unit data information and provide the called data information to the TelephonyRegistry unit; The SOA unit is used to call the data information of the TBox unit and provide the called data information to the HAL unit; The TBox unit is used to provide network status information and receive calls from the SOA unit.
2. The telephony process optimization system for a vehicle-mounted TBox according to claim 1, characterized in that: include: The SOA unit obtains the network status information of the TBox unit through the SOMEIP mechanism; The system supports 4G / 5G network access of the TBox unit and maps network status information to the TelephonyRegistry unit through the HAL unit.
3. The telephony process optimization system for a vehicle-mounted TBox according to claim 2, characterized in that: include: The SOA unit contains a designable cache mechanism, which receives the network status information reported by the TBox unit through the SOMEIP mechanism in real time, and pre-processes the received data before transmitting it to the HAL unit.
4. The telephony process optimization system for a vehicle-mounted TBox according to claim 1, characterized in that: include: The Android application layer includes: vehicle-specific applications and third-party applications, which call network status information through the TelephonyManager interface.
5. The telephony process optimization system for a vehicle-mounted TBox according to claim 1, characterized in that: include: The TelephonyRegistry unit of the framework layer receives the monitoring request of the Android application layer through the TelephonyRegistryManager interface, and transmits the network status information to the HAL unit through the AIDL mechanism.
6. The telephony process optimization system for a vehicle-mounted TBox according to claim 1, characterized in that: include: The HAL unit and the SOA unit use a lightweight communication protocol to transmit network status information by defining a standardized data structure; The network status information includes: signal strength, service status, cell information and cell location.
7. A method for optimizing the Telephony process of a vehicle-mounted TBox, characterized in that: The following steps are involved: Initiate network status monitoring or acquisition requests through the Android application layer; The TelephonyRegistry unit of the framework layer receives the monitoring or acquisition request and forwards the monitoring or acquisition request to the HAL unit through the TelephonyRegistryManager interface; The HAL unit receives the monitoring or acquisition request through the AIDL interface, adapts the data format and interface, and generates a standardized network status query instruction; The SOA unit sends the standardized network status query instruction to the TBox unit based on the in-vehicle Ethernet SOMEIP protocol, and receives the network status information returned by the TBox unit in real time; The SOA unit pre-processes the received network status information and transmits it to the HAL unit; The HAL unit transmits the returned network status information back to the TelephonyRegistry unit through the framework layer; The TelephonyRegistry unit pushes the returned network status information to the Android application layer to complete the dynamic update of the network status of the TBox unit.
8. The method for optimizing the Telephony process of a vehicle-mounted TBox according to claim 9, characterized in that: include: The SOA unit pre-processes the received network status information, including: verifying the network status information returned by the TBox unit and eliminating abnormal values; Convert signal strength, network standard and cell location information into a standardized format; Add timestamps and data source identification to ensure data traceability.
9. An electronic device, characterized in that: include: A processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other via the communication bus; The memory stores a computer program, and when the computer program is executed by the processor, the processor executes the steps of the Telephony process optimization method of the vehicle-mounted TBox according to any one of claims 7 to 8.
10. A computer-readable storage medium, characterized in that It stores a computer program that can be executed by an electronic device. When the computer program runs on the electronic device, the electronic device executes the steps of the Telephony process optimization method of the vehicle-mounted TBox as described in any one of claims 7 to 8.