Position data acquisition method, vehicle, and storage medium

Abstract

Embodiments of the present application provide a position data acquisition method, a vehicle and a storage medium. The method comprises: in response to a vehicle-mounted application initiating a position service request, acquiring a caller identifier, an application package name and context information corresponding to the position service request; classifying the caller identifier, the application package name and the context information based on a preset classification rule to obtain an application scenario category corresponding to the position service request; determining a position precision level according to the application scenario category; and acquiring target position data according to the application scenario category and the position precision level. The present application solves the technical problems of serious distortion of vehicle position data caused by excessively high protection strength and risk of leakage of vehicle position data caused by low protection strength in the related art.

Description

Technical Field

[0001] This application relates to the field of data privacy and security, specifically to a method for acquiring location data, a vehicle, and a storage medium. Background Technology

[0002] Vehicle data privacy protection refers to the use of technology and management to prevent the illegal acquisition, misuse, or leakage of sensitive information collected, transmitted, and stored by intelligent connected vehicles, including user identity, location trajectory, and driving behavior. This not only protects user privacy but also enhances user trust in intelligent vehicles. However, existing vehicle data privacy protection technologies suffer from two main problems: excessively strong protection leads to severe distortion of vehicle location data, while insufficient protection results in the risk of data leakage.

[0003] There is currently no good solution to the above problems. Summary of the Invention

[0004] This application provides a location data acquisition method, a vehicle, and a storage medium to at least solve the technical problems in related technologies where excessively high protection strength leads to severe distortion of vehicle location data, and insufficient protection strength leads to the risk of leakage of vehicle location data.

[0005] According to one aspect of the embodiments of this application, a location data acquisition method is provided, comprising: responding to a location service request initiated by an in-vehicle application, acquiring a caller identifier, an application package name, and context information corresponding to the location service request, wherein the caller identifier is used to represent the unique identity of the in-vehicle application in the vehicle system, the application package name is used to identify the specific application type of the in-vehicle application, and the context information is used to represent the environmental state characteristics when the location service request occurs; classifying the caller identifier, application package name, and context information based on a preset classification rule to obtain the application scenario category corresponding to the location service request; determining the location accuracy level according to the application scenario category, wherein the location accuracy level is used to determine the processing standard of the location data; and acquiring target location data according to the application scenario category and the location accuracy level.

[0006] Furthermore, target location data is obtained based on the application scenario category and the location accuracy level, including: in response to the application scenario category being the first category and the location accuracy level being the first level; target location data is obtained based on the first level.

[0007] Furthermore, the target location data is obtained based on the application scenario category and the location accuracy level, including: in response to the application scenario category being the second category and the location accuracy level being the first level, sending location authorization and authentication information to the user and obtaining the authorization and authentication result, wherein the urgency level of the scenario corresponding to the second category is lower than that of the scenario corresponding to the first category; and obtaining the target location data based on the authorization and authentication result.

[0008] Furthermore, obtaining target location data based on the authorization and authentication result includes: in response to the authorization and authentication result being authorized, obtaining target location data according to the first level; in response to the authorization and authentication result being unauthorized, obtaining target location data according to the second level, wherein the location accuracy corresponding to the second level is lower than the location accuracy corresponding to the first level.

[0009] Furthermore, the location data acquisition method also includes: refusing to acquire target location data in response to an authorization authentication result indicating that authorization has failed.

[0010] Furthermore, the location data acquisition method also includes: in response to the authorization authentication result being successful, recording the authorization authentication result to the authorization log.

[0011] Furthermore, target location data is obtained based on the application scenario category and the location accuracy level, including: in response to the application scenario category being the second category and the location accuracy level being the second level, target location data is obtained based on the second level.

[0012] Furthermore, the location data acquisition method also includes: in response to enabling the hidden location function, acquiring preset virtual coordinates, wherein the preset virtual coordinates are used to protect the user's location privacy; and sending the preset virtual coordinates to a preset application interface.

[0013] According to another aspect of the embodiments of this application, a location data acquisition device is also provided, comprising: a first acquisition module, configured to, in response to a location service request initiated by an in-vehicle application, acquire a caller identifier, an application package name, and context information corresponding to the location service request, wherein the caller identifier is used to represent the unique identity of the in-vehicle application in the vehicle system, the application package name is used to identify the specific application type of the in-vehicle application, and the context information is used to represent the environmental state characteristics when the location service request occurs; a classification module, configured to classify the caller identifier, the application package name, and the context information based on a preset classification rule to obtain the application scenario category corresponding to the location service request; a determination module, configured to determine the location accuracy level according to the application scenario category, wherein the location accuracy level is used to determine the processing standard of the location data; and a second acquisition module, configured to acquire target location data according to the application scenario category and the location accuracy level.

[0014] Furthermore, the second acquisition module is also used to acquire target location data in response to the application scenario category being the first category and the location accuracy level being the first level.

[0015] Furthermore, the second acquisition module is also used to send location authorization and authentication information to the user in response to the application scenario category being the second category and the location accuracy level being the first level, and to obtain the authorization and authentication result, wherein the urgency level of the scenario corresponding to the second category is lower than that of the scenario corresponding to the first category; and to obtain the target location data based on the authorization and authentication result.

[0016] Furthermore, the second acquisition module is also used to acquire target location data according to the first level in response to the authorization authentication result being authorization passed; and to acquire target location data according to the second level in response to the authorization authentication result being authorization failed, wherein the location accuracy corresponding to the second level is lower than the location accuracy corresponding to the first level.

[0017] Furthermore, the location data acquisition device also includes a rejection module, used to reject the acquisition of target location data in response to an authorization authentication result indicating that authorization has failed.

[0018] Furthermore, the location data acquisition device also includes a recording module, used to record the authorization authentication result to the authorization log in response to the authorization authentication result being successful.

[0019] Furthermore, the second acquisition module is also used to acquire target location data based on the second level when the application scenario category is the second category and the location accuracy level is the second level.

[0020] Furthermore, the location data acquisition device also includes: a sending module, used to acquire preset virtual coordinates in response to enabling the hidden location function, wherein the preset virtual coordinates are used to protect the user's location privacy; and to send the preset virtual coordinates to a preset application interface.

[0021] According to another aspect of the embodiments of this application, a vehicle is also provided, including: a memory storing an executable program; and a processor for running the executable program, wherein the executable program executes the location data acquisition method described in any of the above embodiments when running on the processor.

[0022] According to another aspect of the embodiments of this application, a computer-readable storage medium is also provided, the computer-readable storage medium including a stored executable program, wherein, when the executable program is running, it controls the device where the computer-readable storage medium is located to execute the location data acquisition method of various embodiments of this application.

[0023] According to another aspect of the embodiments of this application, a computer program product is also provided, including a computer program that, when executed by a processor, implements the location data acquisition method of various embodiments of this application.

[0024] According to another aspect of the embodiments of this application, a computer program product is also provided, including a non-volatile computer-readable storage medium storing a computer program, which, when executed by a processor, implements the location data acquisition method in various embodiments of this application.

[0025] According to another aspect of the embodiments of this application, a computer program is also provided, which, when executed by a processor, implements the location data acquisition method of various embodiments of this application.

[0026] In this embodiment, when an in-vehicle application initiates a location service request, it obtains the caller identifier, application package name, and context information corresponding to the location service request. The caller identifier represents the unique identity of the in-vehicle application within the vehicle system, the application package name identifies the specific application type of the in-vehicle application, and the context information represents the environmental state characteristics at the time the location service request occurs. Then, based on preset classification rules, the caller identifier, application package name, and context information are classified to obtain the application scenario category corresponding to the location service request. Next, the location accuracy level is determined according to the application scenario category, whereby the location accuracy level determines the processing standard for location data. Finally, the target location data is obtained based on the application scenario category and the location accuracy level. This achieves the goal of dynamically matching differentiated privacy protection strategies for vehicle data according to the category of the application scenario, thereby achieving a technical effect that balances the protection strength of vehicle data privacy with data availability. This solves the technical problems in related technologies where excessive protection strength leads to severe distortion of vehicle location data, and insufficient protection strength leads to the risk of leakage of vehicle location data. Attached Figure Description

[0027] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0028] Figure 1 This is a flowchart of a location data acquisition method according to an embodiment of this application;

[0029] Figure 2 This is a schematic diagram of an optional high-precision location request scenario according to an embodiment of this application;

[0030] Figure 3 This is a schematic diagram of an optional low-precision location request scenario according to an embodiment of this application;

[0031] Figure 4 This is a schematic diagram of an optional virtual location request scenario according to an embodiment of this application;

[0032] Figure 5 This is a schematic diagram of the architecture of an optional location data protection system according to an embodiment of this application;

[0033] Figure 6 This is a schematic diagram of a location data acquisition device according to an embodiment of this application. Detailed Implementation

[0034] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present application.

[0035] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0036] According to an embodiment of this application, an embodiment of a location data acquisition method is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0037] This embodiment provides a method for acquiring location data. Figure 1 This is a flowchart of a location data acquisition method according to an embodiment of this application, such as... Figure 1 As shown, the process includes the following steps:

[0038] Step S11: In response to the location service request initiated by the vehicle application, obtain the caller identifier, application package name and context information corresponding to the location service request. The caller identifier is used to represent the unique identity of the vehicle application in the vehicle system, the application package name is used to identify the specific application type of the vehicle application, and the context information is used to represent the environmental state characteristics when the location service request occurs.

[0039] In this embodiment, in-vehicle applications refer to various software programs running on the in-vehicle infotainment system or related computing terminal of intelligent connected vehicles. These may include, but are not limited to, system-built-in application settings, core service applications such as emergency rescue, and third-party applications such as navigation, weather, social networking, and entertainment. For example, in-vehicle applications can call location services through system interfaces to obtain real-time geographic information of the vehicle.

[0040] A location service request refers to a call instruction initiated by an in-vehicle application to the underlying Location Management Service (LMS) of the vehicle's operating system when it needs to obtain the vehicle's current location. For example, it manifests as a request for latitude and longitude coordinates issued through the Binder communication mechanism or an Application Programming Interface (API). Location service requests can be triggered by user actions, background tasks, or emergency events; this is not a limitation.

[0041] The caller identifier is a digital identity code used within the vehicle's operating system to uniquely distinguish and identify the application instance that initiated the location request; it is typically represented as a process's user identifier. The caller identifier is used for low-level permission verification to ensure the legitimacy of the request source and prevent application impersonation.

[0042] An application package name is a unique string identifier used for registering an in-vehicle application, typically following reverse domain name conventions. Parsing the application package name identifies the application's specific owner, developer, and category (such as navigation, social, or unknown applications), thus providing a basis for subsequent matching of differentiated privacy protection strategies.

[0043] Contextual information refers to the dynamic environment and state data set generated along with location service requests. For example, contextual information includes, but is not limited to, the vehicle's current operating state (such as driving or parking), the user-defined system mode (such as driving mode or privacy mode), the scenario type that triggered the request (such as user-initiated query, emergency call, or background synchronization), and time dimension, etc., which are used to comprehensively determine the sensitivity of the current request and the required level of privacy protection.

[0044] In response to a location service request initiated by an in-vehicle application, obtaining the caller identifier, application package name, and context information corresponding to the location service request can be understood as follows: When an in-vehicle application requests location services, it first obtains the caller identifier through the Binder mechanism to uniquely identify the application process initiating the request, ensuring the accuracy of permission verification. Simultaneously, it parses the application package name to identify the specific category of the application (such as navigation, weather, or third-party applications), thereby matching the appropriate privacy policy. Furthermore, it captures contextual information, including environmental characteristics such as vehicle status, user mode, and triggering scenarios, to comprehensively determine the sensitivity of the request, thereby enabling differentiated privacy protection and balancing data availability with user privacy security.

[0045] As can be seen, by obtaining the caller identifier, application package name, and context information, fine-grained identification and environmental awareness of the source of location requests are achieved. The caller identifier ensures uniqueness, the application package name supports application categorization, and the context information reflects scenario sensitivity. This ensures high-precision availability in necessary scenarios such as navigation while effectively suppressing the risk of privacy leaks in non-sensitive applications, achieving a balance between the strength of privacy protection and data availability.

[0046] Step S12: Classify the caller identifier, application package name and context information based on preset classification rules to obtain the application scenario category corresponding to the location service request;

[0047] In this embodiment, the preset classification rule refers to the logical judgment criteria stored in the vehicle's local policy library, which is an algorithm or mapping table used to comprehensively determine the nature of the request based on the caller identifier, application package name, and context information. For example, it is stipulated that "the application package name belongs to the navigation category and the vehicle is in motion" is classified as a high-precision necessary scenario, while "the application package name belongs to the weather category and the user is in parking mode" is classified as a low-precision generalized scenario, which is not restricted here.

[0048] Application scenario categories refer to standardized scenario labels obtained by mapping the original location service request after processing according to preset classification rules. These labels represent the specific business purpose and privacy sensitivity level of the location service request. For example, application scenario categories include, but are not limited to, high-precision scenarios (such as emergency rescue and navigation), "specific scenarios" (such as vehicle monitoring and insurance based on driving behavior), low-precision scenarios (such as weather and news), or virtual scenarios (such as malicious applications and privacy stealth modes).

[0049] Classifying the caller identifier, application package name, and context information based on preset classification rules to obtain the application scenario category corresponding to the location service request can be understood as performing refined scenario identification of the location service request through preset classification rules. For example, firstly, the caller identifier, application package name, and context information are extracted and input into the local policy engine. Then, based on multi-dimensional features such as application type (e.g., navigation, weather, emergency rescue), triggering conditions (e.g., user-initiated, system-triggered, emergency event), and environmental state (e.g., driving, parking, signal loss), logical judgment and matching are performed. For example, the application category is determined by identifying the application package name, and combined with the context to determine whether it is an emergency scenario, thereby classifying the application scenario category into specific application scenario categories such as "high-precision scenario," "low-precision scenario," or "virtual positioning scenario," without limitation here.

[0050] As can be seen, scene recognition through multi-dimensional feature fusion can dynamically match differentiated de-identification strategies for different scenarios (such as emergency rescue requiring high precision and weather queries requiring low precision), ensuring the data availability of critical businesses and effectively suppressing the risk of privacy leakage in unnecessary scenarios. This achieves a dynamic balance between the strength of privacy protection and application needs, and improves the user experience.

[0051] Step S13: Determine the location accuracy level according to the application scenario category, wherein the location accuracy level is used to determine the processing standard of location data;

[0052] In this application embodiment, the location accuracy level refers to the specific standard level determined according to the application scenario category and used to standardize the location data processing method. In this application, it is mainly divided into high accuracy, low accuracy and virtual positioning.

[0053] For example, high-precision levels correspond to real coordinates with errors ≤50m or ≤10m, suitable for necessary scenarios such as navigation and emergency rescue. Low-precision levels correspond to generalized coordinates or virtual points in city centers with errors ≤1km or ≤2km, suitable for non-sensitive applications such as weather and news. Virtual positioning levels return fixed zero-value coordinates (e.g., 0,0) or preset virtual positioning coordinates, used for malicious application interception or user-initiated stealth mode, and are not restricted here.

[0054] Determining the location accuracy level based on the application scenario category can be understood as matching the application scenario category identified in the above steps with a preset accuracy standard to determine the final location accuracy level. For example, a high accuracy level is determined for "emergency rescue" scenarios, a low accuracy level is determined for "weather query" scenarios, and a virtual location level is determined for "malicious applications" or "privacy concealment" scenarios; there are no restrictions here.

[0055] It can be seen that by mapping scene categories to specific location accuracy levels, the privacy leaks or data distortions caused by traditional technical solutions are avoided. This not only ensures the data availability of critical businesses such as navigation and rescue, but also effectively suppresses privacy risks in non-sensitive scenarios, achieving a dynamic balance between privacy security and functional requirements.

[0056] Step S14: Obtain target location data according to the application scenario category and location accuracy level.

[0057] In this embodiment of the application, target location data refers to the location information that is generated and will eventually be returned to the caller after being processed by corresponding strategies (such as direct acquisition, differential privacy perturbation, regional generalization, or returning a fixed virtual point) according to the determined application scenario category and location accuracy level.

[0058] For example, the target location data is not the original real Global Positioning System (GPS) coordinates, but a data format that meets the privacy protection requirements of the current scenario. For example, in an emergency rescue scenario, it is a real high-precision coordinate with an error of ≤10m; in a weather query scenario, it is a virtual coordinate of the city center with an error of ≤1km; or in a privacy stealth mode, it is a virtual coordinate with all zeros. This is intended to balance business function requirements with user privacy and security.

[0059] Obtaining target location data based on application scenario category and location accuracy level can be understood as calling the corresponding processing module according to the determined application scenario and accuracy level. For example, if it is high accuracy, the actual GPS coordinates are read directly. If it is low accuracy, area generalization or differential perturbation is performed to generate fuzzy coordinates. If it is virtual positioning, a preset zero value or virtual location is returned, which is not limited here.

[0060] It can be seen that by dynamically generating target location data that meets specific accuracy levels, the availability of high-precision data in critical scenarios such as navigation and rescue is ensured, while effectively preventing privacy leaks in non-sensitive scenarios. This achieves a balance between privacy security and the value of data functionality while ensuring compliance.

[0061] Through the above steps, when an in-vehicle application initiates a location service request, it obtains the caller identifier, application package name, and context information corresponding to the location service request. The caller identifier represents the unique identity of the in-vehicle application within the vehicle's infotainment system, the application package name identifies the specific application type, and the context information represents the environmental state characteristics at the time the location service request occurs. Then, based on preset classification rules, the caller identifier, application package name, and context information are classified to obtain the application scenario category corresponding to the location service request. Next, the location accuracy level is determined based on the application scenario category, whereby the location accuracy level determines the processing standard for location data. Finally, the target location data is obtained based on the application scenario category and the location accuracy level. This achieves the goal of dynamically matching differentiated privacy protection strategies for vehicle data according to the category of the application scenario, thereby achieving a technical effect that balances the protection strength of vehicle data privacy with data availability. This solves the technical problems in related technologies where excessive protection strength leads to severe distortion of vehicle location data, and insufficient protection strength leads to the risk of leakage of vehicle location data.

[0062] Further, in step S14, target location data is obtained according to the application scenario category and location accuracy level, including the following steps:

[0063] Step S141, in response to the application scenario category being the first category and the location accuracy level being the first level;

[0064] Step S142: Obtain target location data based on the first level.

[0065] In this application embodiment, the first category refers to specific business scenarios that require high-precision location information. Exemplarily, this application mainly covers scenarios such as users actively viewing vehicle locations (e.g., parking navigation), initial launch of navigation applications, emergency rescue, collision reporting, and enterprise-level fleet management authorized by users, etc., which are not limited here. Scenarios in the first category typically involve driving safety, emergency assistance, or core navigation functions, and have strict requirements for the real-time nature and accuracy of location information.

[0066] The first level refers to a high-precision location data processing standard, which returns true geographic coordinates with minimal error. For example, latitude and longitude errors are typically required to be within 50 meters, and in critical scenarios such as emergency rescue or accident reporting, the error can be controlled within 10 meters, but there is no limit here.

[0067] For example, at the first level, the GPS module can be directly invoked to obtain the raw coordinates, and may be combined with secondary authentication (such as fingerprints, passwords) or emergency exemption mechanisms to ensure that the location data is available in high-risk or necessary scenarios.

[0068] The response that the application scenario category is Category 1 and the location accuracy level is Level 1 can be understood as follows: when the application scenario category is identified as Category 1 (such as emergency rescue, core navigation, or high-precision demand scenarios actively authorized by the user), the location accuracy level is determined to be Level 1 based on the application scenario category. At this time, the high-precision location data acquisition channel is entered, usually accompanied by secondary identity authentication (such as fingerprint / password verification) or an automatic emergency event triggering mechanism, to ensure that the restrictions on the obfuscation of location data are lifted while protecting the user's right to know or in case of emergency.

[0069] Obtaining target location data based on the first level can be understood as directly calling the underlying GPS hardware or high-precision positioning service to obtain the vehicle's true latitude and longitude coordinates, according to the error range defined by the first level (usually ≤50m or ≤10m in emergency scenarios). For example, after obtaining the true location coordinates, based on scenario characteristics (such as automatic encrypted reporting in emergency scenarios, and return after user confirmation in non-emergency scenarios), the target location data conforming to high-precision standards is returned to the caller. This ensures that critical business functions receive sufficiently accurate location support within a compliant framework, meeting the stringent location accuracy requirements of practical applications such as rescue and navigation.

[0070] As can be seen, by identifying the first category (such as emergency rescue and core navigation) and matching it with the first level, the system can break through conventional privacy restrictions and directly obtain real coordinates with minimal error while ensuring security and compliance (such as secondary authentication or emergency exemption). This effectively solves the problem of key functions failing due to over-generalization of existing technologies. It not only meets the stringent requirements of rescue, navigation and other businesses for data accuracy, but also prevents privacy leaks through a strict scenario judgment mechanism.

[0071] For example, Figure 2 This is a schematic diagram of an optional high-precision location request scenario according to an embodiment of this application, such as... Figure 2 As shown in Table 1, when high-precision location coordinates are needed, the system must automatically identify the identity of the user requesting the location information and then determine whether to provide the high-precision coordinates based on that identity. Specifically, when a user actively requests to view the vehicle's current location, secondary authentication is required before high-precision location coordinates (error ≤ 50m) can be returned. In the event of an emergency (rescue / collision), secondary authentication is not required, and high-precision location coordinates are returned directly. When a vehicle manufacturer's service requests high-precision location coordinates, user authorization is required before returning the high-precision location coordinates. If the user has not authorized the request to obtain high-precision location coordinates, the request will be rejected or low-precision location coordinates will be returned.

[0072] Table 1

[0073]

[0074] As shown in Table 1, high-precision location coordinates are only enabled in necessary scenarios to balance security and privacy. To ensure both functional availability and compliance, this application also supports the following mechanisms: High-precision requests must trigger secondary authentication (password / fingerprint), and users can choose "only this time" or "always" authorization. Emergency event exemption (rescue / collision): The system does not require user authentication and can automatically obtain high-precision location, but must notify the user afterward via in-vehicle notification. Automaker safety service authorization (collision reporting): Automaker safety services require prior user authorization, and high-precision coordinates are returned after authorization. Accuracy guarantee (high-precision coordinate error ≤ 50m) is used for critical functions (such as rescue, accident analysis). Strict distinction from low precision: Low precision (≤ 1km) is used for non-essential scenarios, while high precision (≤ 50m) is only used for necessary scenarios. Furthermore, all strategies in this application are executed locally on the in-vehicle system, without relying on the network, ensuring offline availability and real-time response.

[0075] For example, taking a user viewing vehicle location as an example, the user clicks "View Vehicle Location" in the vehicle's settings, requesting access to the LMS (Location Management System). The LMS, after obtaining the caller's identifier, application package name, and context information through preset instructions, determines the execution strategy as "user-initiated request, accuracy level: high (error < 50m)". At this point, a secondary authentication pop-up (password / fingerprint) is triggered. After successful authentication, the system obtains the actual coordinates (39.9042, 116.4074) from the GPS provider and returns high-precision coordinates to the vehicle's system (error ≤ 50m, e.g., 39.9042 ± 0.0005, 116.4074 ± 0.0007). Thus, the user's privacy is protected.

[0076] For example, taking an emergency rescue call as an example, when a user triggers the emergency rescue button on the steering wheel, the user requests to enter the LMS. The LMS recognizes the emergency as an emergency event, automatically obtains high-precision coordinates (no authentication required), with an error of ≤50m, encrypts the high-precision coordinates and reports them to the rescue center, and then notifies the user afterwards: SOS has been triggered and the location has been reported.

[0077] Further, in step S14, target location data is obtained according to the application scenario category and location accuracy level, including the following steps:

[0078] Step S143: In response to the application scenario category being the second category and the location accuracy level being the first level, location authorization authentication information is sent to the user to obtain the authorization authentication result. The urgency level of the scenario corresponding to the second category is lower than that of the scenario corresponding to the first category.

[0079] Step S144: Obtain target location data based on the authorization and authentication results.

[0080] In this application embodiment, the second category refers to business scenarios that have a certain requirement for location accuracy, but whose urgency and necessity are lower than those of the first category (such as emergency rescue and core navigation). For example, in this application, the second category typically includes scenarios such as users actively viewing vehicle locations (such as finding a vehicle), car owners sharing locations in groups, and specific third-party applications (such as weather and maps), which are not limited here.

[0081] Authorization and authentication information is an interactive prompt or verification request sent to the user terminal (vehicle infotainment screen) when the application scenario is identified as belonging to the second category and requiring high-precision location data. For example, authorization and authentication information is used to inform the user that an application is requesting high-precision location data and prompts the user to confirm their identity. Specific forms may include pop-up prompts (e.g., "[Application Name] requests precise location data to provide services, do you allow it?"), biometric verification interfaces (such as fingerprint recognition, facial recognition, or password input boxes), or secondary confirmation buttons, thereby enabling users to actively control their privacy data with informed consent.

[0082] The authorization authentication result is the final action feedback from the user regarding the authorization authentication information, which is received and parsed by the system. For example, the authorization authentication result is typically a Boolean value or a specific status code, representing "authorization consent" or "rejection / cancellation". If the user completes verification via fingerprint, password, or clicking the "Allow" button, the authorization authentication result is "passed," and the system determines the request is legitimate, allowing entry into the high-precision data acquisition process. If the user fails to operate within the specified time, selects "reject," or verification fails, the authorization authentication result is "failed," and the system will refuse to return high-precision data, typically returning low-precision data or a virtual location instead, thus ensuring that high-precision privacy data is not leaked without the user's explicit consent.

[0083] In response to an application scenario category of Category 2 and a location accuracy level of Level 1, location authorization and authentication information is sent to the user. The authorization and authentication result can be understood as follows: when the application scenario category is identified as Category 2 (such as user-initiated vehicle search, third-party application request, etc.) and Level 1 (high-precision) data is required, location authorization and authentication information is sent to the user's terminal through pop-up windows, biometrics, or password input, clearly informing the user that an application is requesting high-precision location and requiring the user to confirm again. This ensures that data provision is based on the user's informed consent, balancing functional requirements and privacy protection.

[0084] Obtaining target location data based on authorization and authentication results can be understood as follows: If the user passes biometric verification or explicitly clicks "Allow," the authorization and authentication result is "Passed." In this case, a high-precision GPS module is invoked to obtain the actual coordinates and return them to the requester, meeting the business's accuracy requirements. If the user refuses, fails to perform an operation within the time limit, or the verification fails, the authorization and authentication result is "Failed." The system will refuse to return high-precision data and instead return low-precision generalized data or a virtual location. This ensures that only high-precision requests explicitly authorized by the user are satisfied, effectively preventing unauthorized privacy data leaks.

[0085] As can be seen, by intercepting the second type of high-precision requests and triggering secondary authentication, the system effectively prevents third-party applications or malicious programs from obtaining precise trajectories without the user's knowledge, significantly reducing the risk of privacy leaks. Simultaneously, dynamically determining data output based on explicit authorization results respects the user's data control rights while ensuring that the high-precision requirements of functions such as navigation and vehicle tracking are met with the user's consent.

[0086] Further, in step S144, the target location data is obtained based on the authorization and authentication result, including the following steps:

[0087] In response to the authorization and authentication result being successful, the target location data is obtained based on the first level.

[0088] In response to the authorization authentication result being unsuccessful, target location data is obtained based on the second level, where the location accuracy corresponding to the second level is lower than that corresponding to the first level.

[0089] In this embodiment, the second level refers to a processing standard representing low-precision or fuzzy location data, such as reducing the accuracy of geographic location to protect user privacy. In this application, the second level typically corresponds to returning coordinates after regional generalization, gridding, or virtualization processing, such as generalizing a specific street to a city-level area or street-level area, or directly returning a specific virtual coordinate point (such as zero-value coordinates or a preset virtual location), which is not limited here.

[0090] For example, unlike the high-precision real coordinates of the first level (error ≤ 50m), the data of the second level cannot accurately locate the specific real-time position of the vehicle, but usually still retains a certain geographical range information (such as city or district level). Thus, even when the user does not authorize high-precision access, it can still provide basic location-related services for non-sensitive applications such as weather and news, achieving a balance between privacy protection and the availability of basic functions.

[0091] In response to the authorization authentication result being approved, obtaining the target location data according to the first level can be understood as follows: if the authorization authentication result is approved, it means that the user has explicitly agreed to share high-precision location information. At this time, the underlying GPS or high-precision positioning service is directly called according to the data standard of the first level to obtain the real latitude and longitude coordinates with extremely small errors (usually ≤50m). This ensures that, under the premise of compliance, it meets the business scenarios with strict requirements for data accuracy, such as navigation and emergency rescue, and returns complete and accurate target location data to the requester, ensuring the normal operation of key functions and user experience.

[0092] In response to an authorization failure result, obtaining target location data according to the second level can be understood as follows: if the authorization failure result indicates that the user refuses to provide high-precision data or the verification fails, the original location can be anonymized according to the data standards of the second level, such as regional generalization (returning the city or street-level center point), adding noise, or returning virtual coordinates. This can prevent privacy leaks while still providing basic geolocation services for non-sensitive applications such as weather and information, achieving a functional balance between privacy and security.

[0093] As can be seen, through the authorization and authentication results, this application provides differentiated services while ensuring user control over their data. When the authorization and authentication results are successful, high-precision data is provided to meet core business needs and improve the user experience. When the authorization and authentication results are unsuccessful, the data is automatically downgraded to low-precision data, effectively preventing privacy leaks. This not only avoids functional limitations caused by excessive privacy protection but also avoids the risk of unauthorized precise location tracking, enhancing users' trust in the use of smart car data.

[0094] Furthermore, the location data acquisition method also includes the following steps:

[0095] In response to the authorization failure result, the acquisition of target location data is refused.

[0096] In this embodiment of the application, responding to the authorization authentication result of authorization failure and refusing to obtain target location data can be understood as follows: when the authorization authentication result is unsuccessful, it indicates that the user has explicitly refused or not authorized the current application to obtain vehicle location information. The system immediately interrupts the high-precision data request process, no longer performs any location acquisition operation, and directly returns an empty value or a default rejection state. This blocks the privacy data leakage path in unauthorized scenarios and ensures that the vehicle application cannot indirectly obtain the vehicle location by any means without the user granting permission, thus fundamentally protecting the user's location privacy and security.

[0097] As can be seen, through this step, when the user refuses authorization, the system directly blocks data acquisition, completely eliminating the risk of location leakage in unauthorized scenarios. This not only strengthens the user's control over personal data and ensures privacy and security, but also avoids functional degradation caused by over-protection, thereby increasing the user's trust in the in-vehicle privacy system.

[0098] Furthermore, the location data acquisition method also includes the following steps:

[0099] If the authorization authentication result is successful, the authorization authentication result will be recorded in the authorization log.

[0100] In this embodiment, the authorization log is used to record the entire lifecycle audit trail data of location privacy authorization behavior. For example, the authorization log records in detail the timestamp of the authorization, the application package name that triggered the request, the scenario category of the request, the authentication result selected by the user (pass / reject), and the specific scope of authorization permissions.

[0101] For example, authorization logs are stored locally on the vehicle or in an encrypted cloud, allowing users to view historical authorization records at any time. These logs also serve as key evidence for compliance reviews and security traceability, ensuring that all high-precision location data is acquired with explicit and traceable user consent, thus enhancing the transparency and controllability of privacy management.

[0102] Responding to the authorization authentication result being successful, recording the authorization authentication result to the authorization log can be understood as the persistent storage of key information of this authorization, including timestamp, requesting application identifier, authorization type and result, in the local authorization log when the user's authorization is successful. This not only achieves the traceability of privacy operations, allowing users to clearly view historical authorization records to supervise and manage data usage, but also provides data support for the automaker's subsequent security audits, compliance reviews and abnormal behavior analysis, enhancing the transparency and credibility of user privacy protection.

[0103] As can be seen, by recording the authorization results, users can clearly understand the history of their privacy data usage, enhancing transparency and trust. At the same time, it facilitates car manufacturers in conducting security monitoring and anomaly investigation, ensuring that all high-precision location acquisitions comply with regulatory requirements, providing data support for closed-loop management of privacy protection, and effectively preventing the risk of data misuse.

[0104] Further, in step S14, target location data is obtained according to the application scenario category and location accuracy level, including the following steps:

[0105] In response to the application scenario category being the second category and the location accuracy level being the second level, target location data is obtained based on the second level.

[0106] In this embodiment of the application, in response to the application scenario category being the second category and the location accuracy level being the second level, obtaining target location data based on the second level can be understood as follows: if the current application scenario category belongs to the second category (such as non-sensitive applications such as weather and news), and the location accuracy level is determined to be the second level, target location data with larger errors (such as city-level or street-level) is generated through methods such as regional generalization, gridding, or returning virtual coordinates. This reduces the risk of privacy leakage while meeting the basic business function requirements, and achieves a fine balance between the strength of privacy protection and data availability.

[0107] It can be seen that when the application scenario category is the second category and the required location accuracy level is the second level, generalizing the real coordinates into a fuzzy location effectively blocks the risk of third-party applications obtaining precise trajectories. This ensures the availability of basic services while improving user privacy and security, and avoids service unavailability caused by excessive data anonymization.

[0108] For example, Figure 3 This is a schematic diagram of an optional low-precision location request scenario according to an embodiment of this application, such as... Figure 3 As shown in Table 2, when low-precision location coordinates are needed, the system needs to automatically identify the identity information of the location caller and then decide whether to provide the low-precision location coordinates based on the identity information. Specifically, when a weather / news application requests low-precision location coordinates, the system returns a generalized location (error ≤ 2km). When an undefined third-party software requests low-precision location coordinates, an authorization request pop-up prompt is sent to the vehicle screen. After the user agrees to the authorization, the system returns the low-precision location.

[0109] Table 2

[0110]

[0111] As shown in Table 2, by default, low-precision city-level locations are returned for non-navigation third-party applications to protect user privacy. To ensure functionality and usability, the system also supports the following mechanisms: Temporary high precision, requiring user authorization: When a non-navigation application requests a high-precision location, a pop-up window obtains the user's consent, allowing for either "this time only" or "always" higher precision. Purpose-aware hierarchical classification: Based on pre-defined application categories and purpose tags, street-level generalization is provided for "functional" requests (such as weather or traffic restrictions), while only city-level or rejected for "analytical" requests. Security event exemption: In emergency scenarios such as collisions or theft, the vehicle manufacturer's security services can bypass the anonymization strategy to obtain the original location, but the user must be informed afterward. Furthermore, all policies are executed locally on the vehicle's infotainment system, without relying on the network, ensuring offline availability.

[0112] For example, taking weather apps as an example, the weather app requests the low-precision location of the vehicle from the LMS according to a preset instruction. After obtaining the caller's identifier, application package name, and context information, the LMS determines the execution strategy as "weather app, accuracy level: low (error <2000m)", obtains the real coordinates (39.9042, 116.4074) from the GPS provider, and generates low-precision location coordinates (39.9000, 116.4000). The low-precision location coordinates are then fed back to the weather app, thereby protecting the user's privacy.

[0113] Furthermore, the location data acquisition method also includes the following steps:

[0114] In response to enabling the hidden location feature, a preset virtual coordinate is obtained, which is used to protect the user's location privacy;

[0115] Send the preset virtual coordinates to the preset application interface.

[0116] In this embodiment, the location hiding function is a privacy protection mechanism actively triggered by the user, allowing the driver or vehicle owner to activate "stealth mode" with a single click through the vehicle's infotainment system settings. For example, the location hiding function eliminates the risk of exposing the vehicle's true location information. When this function is enabled, the system will intercept all regular location service requests and forcibly replace the location return content, ensuring that third-party applications, social software, or network services cannot obtain the user's real-time geographic coordinates, thereby preventing sensitive privacy information such as address and frequently visited locations from being associated with or leaked.

[0117] Preset virtual coordinates are alternative geographic location data generated when the hidden location function is enabled. They are typically represented by specific invalid coordinates (such as a "zero point" with both latitude and longitude of 0.0) or a user-defined city center point. For example, preset virtual coordinates do not have actual geographic directionality and are mainly used to return a vague or meaningless location result to the caller, causing map applications to display a default area or be unable to locate, thereby severing the association between the real location and the vehicle's current location at the application logic level.

[0118] The default application interface refers to the interactive interface in the vehicle system used to manage and display privacy protection status. It typically includes a privacy settings panel, a location permission management page, or a page containing a one-click invisibility switch. For example, the default application interface not only provides a toggle control for the location hiding function, but also allows users to configure the specific content of the default virtual coordinates (such as custom coordinates), ensuring that users have intuitive and controllable management permissions over privacy protection policies.

[0119] In response to enabling the hidden location feature, obtaining preset virtual coordinates can be understood as follows: when a user actively triggers the "hide location" or "one-click invisibility" function through the vehicle's infotainment system settings, the system immediately intercepts all subsequent location requests from applications. At this time, the location management service no longer calls the real GPS module to obtain real-time latitude and longitude, but instead reads preset virtual coordinate data from the local configuration, thereby cutting off the privacy leakage path at the source.

[0120] Sending preset virtual coordinates to a preset application interface can be understood as follows: after obtaining the preset virtual coordinates, the preset virtual coordinates are sent as standard location data to the third-party application or the vehicle's built-in application that requests the location. This avoids functional failure caused by directly refusing service and achieves a balance between privacy protection and user experience.

[0121] As can be seen, by enabling the hidden location feature and returning preset virtual coordinates, the leakage of real location data is effectively blocked, preventing third-party applications from tracking or associating it with sensitive information. At the same time, returning the preset virtual coordinates maintains the normal display and basic operation of the application interface, avoiding experience interruptions caused by direct denial of service. This achieves a balance between privacy protection and functional usability while ensuring user privacy and security.

[0122] Figure 4 This is a schematic diagram of an optional virtual location request scenario according to an embodiment of this application, such as... Figure 4 As shown in Table 3, when a user needs to hide their current vehicle location, a fixed virtual coordinate must be automatically returned whenever any in-vehicle application requests the vehicle's location, thus preventing the vehicle's location information from being stolen or leaked. Specifically, when the vehicle is located in a sensitive area (residential area / commercial area / park), a fixed virtual coordinate is automatically returned. When software with unknown security risks requests the vehicle's location, a fixed virtual coordinate is automatically returned. When the user actively hides their location, a fixed virtual coordinate is automatically returned. When the user sets privacy protection in the vehicle's infotainment system, a fixed virtual coordinate is automatically returned. Furthermore, all virtual location requests are intercepted by a system-level proxy module, which application software cannot bypass, ensuring that virtual coordinates are sent only in the relevant scenarios.

[0123] Table 3

[0124]

[0125] As shown in Table 3, the system defaults to returning a city-level virtual location for non-navigation third-party applications to protect user privacy. To ensure functionality and usability, the system also supports the following mechanisms: Temporary high-precision authorization: When an application requests a high-precision location, a pop-up window obtains the user's consent, allowing for either "this time only" or "always" higher accuracy. Purpose-aware hierarchical classification: Based on pre-defined application categories and purpose tags, street-level generalization is provided for "functional" requests (such as weather or traffic restrictions), while city-level or rejected requests are only provided for "analytical" requests. Security event exemption: In emergency scenarios such as collisions or theft, the vehicle manufacturer's security services can bypass the anonymization strategy to obtain the original location, but the user must be informed afterward. All policies are executed locally on the vehicle's infotainment system, without relying on the network, ensuring offline availability.

[0126] For example, taking the request for location by unknown / risky software as an example, when a user parks in a residential area, the unknown / risky software requests location. The LMS identifies this as a sensitive area and automatically triggers the request. The system returns fixed virtual coordinates, which are displayed on the WeChat map as location coordinates unrelated to the current address.

[0127] For example, taking a preset virtual location as an example, a user can set the privacy virtual location to "Location 1". The system will pop up a secondary authentication pop-up window ("Confirm the preset 'Location 1' as a virtual location?"). After the user passes the authentication, the system records the preset virtual location as "Location 1".

[0128] Figure 5 This is a schematic diagram of the architecture of an optional location data protection system according to an embodiment of this application, such as... Figure 5 As shown, the location data protection system includes: navigation software (for requesting location), weather software (for requesting last location), third-party software (for requesting location updates), a location management service, a location privacy proxy module, policy configuration and management, a GPS provider, a GPS hardware abstraction layer, a network provider, and a wireless network. Specifically, the navigation software, weather software, and third-party software are connected to the location management service; the location management service is connected to the location privacy proxy module; the location privacy proxy module is connected to the policy configuration and management system; the location privacy proxy module is also connected to the GPS provider and the network provider; the GPS provider is connected to the GPS hardware abstraction layer; and the network provider is connected to the wireless network.

[0129] The location data protection system implements location privacy protection through a layered architecture. Application layer software (navigation software, weather software, and third-party software) sends requests to the location management service, which then calls the location privacy proxy module for interception and processing. The proxy module determines whether to return high-precision, low-precision, or virtual coordinates based on dynamic rules set by the policy configuration and management module (such as application type, scenario, and user permissions). If the real location is required, the proxy module obtains data by calling the GPS hardware abstraction layer through the GPS provider, or by obtaining auxiliary information from the wireless network using the network provider. If anonymization is required, the processed data is returned directly, ensuring that all location requests are filtered by privacy policies, thus achieving fine-grained location privacy protection while safeguarding business functions.

[0130] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use and processing of the relevant data must comply with the relevant laws, regulations and standards of the relevant countries and regions, and corresponding operation entry points are provided for users to choose to authorize or refuse.

[0131] According to an embodiment of this application, an embodiment of a location data acquisition device is provided. It should be noted that the device can be used to perform the above-described location data acquisition method.

[0132] Figure 6 This is a schematic diagram of a location data acquisition device according to an embodiment of this application, such as... Figure 6 As shown, the location data acquisition device 600 includes: a first acquisition module 601, used to respond to a location service request initiated by an in-vehicle application, and acquire the caller identifier, application package name, and context information corresponding to the location service request, wherein the caller identifier is used to represent the unique identity of the in-vehicle application in the vehicle system, the application package name is used to identify the specific application type of the in-vehicle application, and the context information is used to represent the environmental state characteristics when the location service request occurs; a classification module 602, used to classify the caller identifier, application package name, and context information based on a preset classification rule to obtain the application scenario category corresponding to the location service request; a determination module 603, used to determine the location accuracy level according to the application scenario category, wherein the location accuracy level is used to determine the processing standard of the location data; and a second acquisition module 604, used to acquire target location data according to the application scenario category and the location accuracy level.

[0133] Furthermore, the second acquisition module 604 is also used to acquire target location data in response to the application scenario category being the first category and the location accuracy level being the first level.

[0134] Furthermore, the second acquisition module 604 is also used to send location authorization and authentication information to the user in response to the application scenario category being the second category and the location accuracy level being the first level, and to obtain the authorization and authentication result, wherein the urgency level of the scenario corresponding to the second category is lower than that of the scenario corresponding to the first category; and to obtain the target location data based on the authorization and authentication result.

[0135] Furthermore, the second acquisition module 604 is also used to acquire target location data according to the first level in response to the authorization authentication result being authorization passed; and to acquire target location data according to the second level in response to the authorization authentication result being authorization failed, wherein the location accuracy corresponding to the second level is lower than the location accuracy corresponding to the first level.

[0136] Furthermore, the location data acquisition device also includes a rejection module, used to reject the acquisition of target location data in response to an authorization authentication result indicating that authorization has failed.

[0137] Furthermore, the location data acquisition device also includes a recording module, used to record the authorization authentication result to the authorization log in response to the authorization authentication result being successful.

[0138] Furthermore, the second acquisition module 604 is also used to acquire target location data based on the second level in response to the application scenario category being the second category and the location accuracy level being the second level.

[0139] Furthermore, the location data acquisition device also includes: a sending module, used to acquire preset virtual coordinates in response to enabling the hidden location function, wherein the preset virtual coordinates are used to protect the user's location privacy; and to send the preset virtual coordinates to a preset application interface.

[0140] According to another aspect of the embodiments of this application, a vehicle is also provided, including: a memory storing an executable program; and a processor for running the executable program, wherein the executable program executes the location data acquisition method described in any of the above embodiments when running on the processor.

[0141] Optionally, in this embodiment, the processor in the vehicle can be configured to run a computer program to perform the following steps:

[0142] Step S11: In response to the location service request initiated by the vehicle application, obtain the caller identifier, application package name and context information corresponding to the location service request. The caller identifier is used to represent the unique identity of the vehicle application in the vehicle system, the application package name is used to identify the specific application type of the vehicle application, and the context information is used to represent the environmental state characteristics when the location service request occurs.

[0143] Step S12: Classify the caller identifier, application package name and context information based on preset classification rules to obtain the application scenario category corresponding to the location service request;

[0144] Step S13: Determine the location accuracy level according to the application scenario category, wherein the location accuracy level is used to determine the processing standard of location data;

[0145] Step S14: Obtain target location data according to the application scenario category and location accuracy level.

[0146] According to another aspect of the embodiments of this application, a computer-readable storage medium is also provided, wherein a computer program is stored in the computer-readable storage medium, and the computer program is configured to execute the location data acquisition method in any of the above embodiments when running on a computer or processor.

[0147] Optionally, in this embodiment, the computer-readable storage medium may be configured to store a computer program for performing the following steps:

[0148] Step S11: In response to the location service request initiated by the vehicle application, obtain the caller identifier, application package name and context information corresponding to the location service request. The caller identifier is used to represent the unique identity of the vehicle application in the vehicle system, the application package name is used to identify the specific application type of the vehicle application, and the context information is used to represent the environmental state characteristics when the location service request occurs.

[0149] Step S12: Classify the caller identifier, application package name and context information based on preset classification rules to obtain the application scenario category corresponding to the location service request;

[0150] Step S13: Determine the location accuracy level according to the application scenario category, wherein the location accuracy level is used to determine the processing standard of location data;

[0151] Step S14: Obtain target location data according to the application scenario category and location accuracy level.

[0152] According to another aspect of the embodiments of this application, a computer program product is also provided, including a computer program that, when executed by a processor, implements the location data acquisition method of various embodiments of this application.

[0153] Optionally, in this embodiment, the computer program in the above-described computer program product can be configured to perform the following steps when executed by a processor:

[0154] Step S11: In response to the location service request initiated by the vehicle application, obtain the caller identifier, application package name and context information corresponding to the location service request. The caller identifier is used to represent the unique identity of the vehicle application in the vehicle system, the application package name is used to identify the specific application type of the vehicle application, and the context information is used to represent the environmental state characteristics when the location service request occurs.

[0155] Step S12: Classify the caller identifier, application package name and context information based on preset classification rules to obtain the application scenario category corresponding to the location service request;

[0156] Step S13: Determine the location accuracy level according to the application scenario category, wherein the location accuracy level is used to determine the processing standard of location data;

[0157] Step S14: Obtain target location data according to the application scenario category and location accuracy level.

[0158] According to another aspect of the embodiments of this application, a computer program product is also provided, including a non-volatile computer-readable storage medium storing a computer program, which, when executed by a processor, implements the location data acquisition method in various embodiments of this application.

[0159] Optionally, in this embodiment, the computer program in the above-described computer program product can be configured to perform the following steps when executed by a processor:

[0160] Step S11: In response to the location service request initiated by the vehicle application, obtain the caller identifier, application package name and context information corresponding to the location service request. The caller identifier is used to represent the unique identity of the vehicle application in the vehicle system, the application package name is used to identify the specific application type of the vehicle application, and the context information is used to represent the environmental state characteristics when the location service request occurs.

[0161] Step S12: Classify the caller identifier, application package name and context information based on preset classification rules to obtain the application scenario category corresponding to the location service request;

[0162] Step S13: Determine the location accuracy level according to the application scenario category, wherein the location accuracy level is used to determine the processing standard of location data;

[0163] Step S14: Obtain target location data according to the application scenario category and location accuracy level.

[0164] According to another aspect of the embodiments of this application, a computer program is also provided, which, when executed by a processor, implements the location data acquisition method of various embodiments of this application.

[0165] Optionally, in this embodiment, the computer program described above can be configured to perform the following steps when executed by the processor:

[0166] Step S11: In response to the location service request initiated by the vehicle application, obtain the caller identifier, application package name and context information corresponding to the location service request. The caller identifier is used to represent the unique identity of the vehicle application in the vehicle system, the application package name is used to identify the specific application type of the vehicle application, and the context information is used to represent the environmental state characteristics when the location service request occurs.

[0167] Step S12: Classify the caller identifier, application package name and context information based on preset classification rules to obtain the application scenario category corresponding to the location service request;

[0168] Step S13: Determine the location accuracy level according to the application scenario category, wherein the location accuracy level is used to determine the processing standard of location data;

[0169] Step S14: Obtain target location data according to the application scenario category and location accuracy level.

[0170] In the above embodiments of this application, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

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

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

[0173] 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.

[0174] 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 computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, read-only memory (ROM), random access memory (RAM), portable hard drives, magnetic disks, or optical disks.

[0175] The above description is only a preferred embodiment of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A method for acquiring location data, characterized in that, include: In response to a location service request initiated by an in-vehicle application, the caller identifier, application package name, and context information corresponding to the location service request are obtained. The caller identifier is used to represent the unique identity of the in-vehicle application in the vehicle system, the application package name is used to identify the specific application type of the in-vehicle application, and the context information is used to represent the environmental state characteristics when the location service request occurs. The caller identifier, the application package name, and the context information are classified according to preset classification rules to obtain the application scenario category corresponding to the location service request; The location accuracy level is determined based on the application scenario category, wherein the location accuracy level is used to determine the processing standard for location data; Target location data is obtained based on the application scenario category and the location accuracy level.

2. The method according to claim 1, characterized in that, The step of obtaining target location data based on the application scenario category and the location accuracy level includes: In response to the application scenario category being the first category and the location accuracy level being the first level; The target location data is obtained based on the first level.

3. The method according to claim 1, characterized in that, The step of obtaining target location data based on the application scenario category and the location accuracy level includes: In response to the application scenario category being the second category and the location accuracy level being the first level, location authorization and authentication information is sent to the user to obtain the authorization and authentication result, wherein the urgency level of the scenario corresponding to the second category is lower than that of the scenario corresponding to the first category; The target location data is obtained based on the authorization and authentication results.

4. The method according to claim 3, characterized in that, The step of obtaining the target location data based on the authorization and authentication result includes: In response to the authorization authentication result being successful, the target location data is obtained according to the first level; In response to the authorization authentication result being that the authorization failed, the target location data is obtained according to the second level, wherein the location accuracy corresponding to the second level is lower than the location accuracy corresponding to the first level.

5. The method according to claim 4, characterized in that, The method further includes: In response to the authorization authentication result being unsuccessful, the acquisition of the target location data is refused.

6. The method according to claim 5, characterized in that, The method further includes: In response to the authorization authentication result being successful, the authorization authentication result is recorded in the authorization log.

7. The method according to claim 1, characterized in that, The step of obtaining target location data based on the application scenario category and the location accuracy level includes: In response to the application scenario category being the second category and the location accuracy level being the second level, the target location data is obtained based on the second level.

8. The method according to claim 1, characterized in that, The method further includes: In response to enabling the hidden location function, a preset virtual coordinate is obtained, wherein the preset virtual coordinate is used to protect the user's location privacy; Send the preset virtual coordinates to the preset application interface.

9. A vehicle, characterized in that, include: Memory, which stores executable programs; A processor for running the executable program, wherein the executable program, when running on the processor, performs the location data acquisition method as described in any one of claims 1 to 8.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, wherein the computer program is configured to execute the location data acquisition method described in any one of claims 1 to 8 when run on a computer or processor.

Images