Application installation processing method, device and vehicle

Abstract

This application provides an application installation processing method, device, and vehicle, relating to the field of data processing technology. The method generates an installation task record for the first application when downloading it. The installation task record includes the current installation status and expected version identifier of the first application. During the installation or update of the first application, if preset conditions are met, the actual version identifier of the first application is obtained. The preset conditions are used to determine whether the current installation status of the first application is abnormal. Based on the expected version identifier and the actual version identifier, the current installation status is updated to obtain the actual installation status of the first application. This avoids situations where the true installation status cannot be accurately obtained during application installation or update, improving the user's application installation experience.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and in particular to an application installation processing method, equipment, and vehicle. Background Technology

[0002] With the rapid development of smart terminal technology, various applications are emerging in an endless stream, and users can download, install, or update applications through multiple channels. For example, users can install or update applications (APPs) through application management software (such as app stores) that provide application distribution, download, and installation services to obtain the corresponding application services.

[0003] In related technologies, when downloading, installing, or updating applications, taking a user downloading, installing, or updating a navigation application on an in-vehicle terminal using a vehicle-mounted app store as an example, the in-vehicle app store typically installs or updates the navigation application by calling the system's application installation service and creating an installation session, and obtains the installation result (such as successful installation or installation failure) through an installation callback. However, the actual installation status of the application may not be accurately obtained. For example, the aforementioned in-vehicle app store may malfunction for some reason, thus failing to accurately obtain the actual installation status of the navigation application, resulting in abnormal display of the application's installation status and affecting the user's installation experience. Summary of the Invention

[0004] This application provides an application installation processing method, device, and vehicle to solve the problem in related technologies that it is impossible to accurately obtain the actual installation status of the application, which affects the user's installation experience.

[0005] In a first aspect, embodiments of this application provide an application installation processing method, including: When downloading the first application, an installation task record for the first application is generated; the installation task record includes the current installation status and expected version identifier of the first application. During the installation or update process of the first application, if a preset condition is met, the actual version identifier of the first application is obtained; wherein, the preset condition is used to determine whether the current installation status of the first application is abnormal. Based on the expected version identifier and the actual version identifier, the current installation status is updated to obtain the actual installation status of the first application.

[0006] Based on the above technical content, this application embodiment generates an installation task record including the current installation status and expected version identifier of the first application when downloading the first application. This allows for updates to the current installation status by obtaining the actual version identifier of the first application and comparing it with the expected version identifier stored in the installation task record. This comparison ensures the current installation status accurately reflects the actual installation status of the first application, preventing situations where the true installation status cannot be accurately obtained during application installation or updates. By displaying the true installation status during the application installation or update process, this avoids installation function malfunctions caused by abnormal installation status display, thus improving the user's application installation experience.

[0007] In one possible implementation, the method further includes: Monitor the process status of the second application; the second application is used to create an installation task table to store the installation task records of the application, and after the application is installed or updated, it receives the application installation status feedback from the application and updates the corresponding installation task records. If the process status indicates that the second application has been terminated, then the preset condition is determined to be met; wherein, when the second application is terminated, the application installation status feedback from the application is stopped.

[0008] In this embodiment of the application, for the case where an installation task table is created and installation task records are stored using a second application, and the application installation status is received in response, the application installation status will not be received when the second application is terminated. That is, the current installation status in the corresponding installation task record cannot be updated. This means that the current installation status in the installation task record may not represent the actual installation status of the application. Therefore, by monitoring whether the process status of the second application indicates that the second application has been terminated, the determination of whether the installation or update process of the first application meets the preset conditions can be achieved. Thus, when the installation task table is created and installation task records are stored using the second application, it can be accurately determined whether the installation or update process of the first application has encountered a situation that causes the current installation status in the installation task record to be abnormal.

[0009] In one possible implementation, the installation task record also includes a timestamp indicating the generation of the installation task record; The method further includes: Based on the generated timestamp, determine the download and installation time of the first application from the start of download to the current moment; If the download and installation time exceeds the first preset time threshold, then the preset condition is determined to be met.

[0010] Here, by adding the generation timestamp information of the installation task record to the installation task record, the download and installation time of the first application from the start of download to the current time is counted. In order to provide a general logic for judging whether the installation or update process of the first application meets the preset conditions from the dimension of the time required for application download and installation, so as to meet the judgment of preset conditions in different installation or update scenarios and improve the applicability of the application installation processing method.

[0011] In one possible implementation, updating the current installation state based on the expected version identifier and the actual version identifier to obtain the actual installation state of the first application includes: Compare the actual version identifier with the expected version identifier; Based on the comparison results, determine the installation or update result of the first application; The current installation status is updated to the installation or update result of the first application, which serves as the actual installation status of the first application. The installation or update result refers to a status indicating that the installation, update, or download is complete.

[0012] In this embodiment, by comparing the actual version identifier and the expected version identifier, the installation or update result of the first application is refined into the states of installed, updated, or downloaded. Then, by using the states of installed, updated, or downloaded, different situations may occur when the current installation status of the first application is abnormal during the installation or update process, so as to carry out different processing for different situations in the future.

[0013] In one possible implementation, the version identifier includes a version number, with higher version numbers indicating higher version levels; Determining the installation or update result of the first application based on the comparison results includes: If the actual version number is equal to or greater than the expected version number, then the installation or update result of the first application is determined to be an installed or updated state. If the actual version number is less than the expected version number, then the installation or update result of the first application is determined to be a complete download.

[0014] Here, the comparison between the actual version number in the actual version identifier and the expected version number in the expected version identifier is transformed into a comparison of the size of the actual version number and the expected version number. Based on the logic that a higher version number indicates a higher version level, if the actual version number is equal to or greater than the expected version number, it means that the actually installed version is the expected version, or the actually installed version is higher than the expected version. In this case, the installation or update result of the first application is determined to be in an installed or updated state. If the actual version number is less than the expected version number, it means that the actually installed version is lower than the expected version, that is, the installation or update process of the first application has not been completed normally. In this case, the installation or update result of the first application is determined to be in a downloaded state, so as to accurately reflect the true installation status of the first application.

[0015] In one possible implementation, the installation task record also includes the installation session identifier of the first application; After updating the current installation status to the installation or update result of the first application, the method further includes: If the actual installation status of the first application is installed, updated, or downloaded, then the session abandonment interface is called. The installation session corresponding to the installation session identifier is cleaned up using the abandoned session interface.

[0016] Based on the above technical content, by adding an installation session identifier to the installation task record, after the first application's installation or update process meets preset conditions and its current installation status is updated based on the obtained actual version identifier and expected version identifier, the installation session created during the installation or update process of the first application can be cleaned up by calling the abandon session interface. This avoids situations where the installation session cannot be properly cleaned up due to an abnormal current installation status during the installation or update process of the first application. Furthermore, timely cleanup of installation sessions can also reduce the memory consumption caused by invalid installation sessions, allowing subsequent installation or update operations to proceed normally and preventing the installation function from freezing.

[0017] In one possible implementation, after the preset conditions are met, the following is also included: Determine whether the current installation status indicates that the first application is being installed; If the current installation status indicates that the first application is being installed, then the step of obtaining the actual version identifier of the first application is executed.

[0018] Here, after determining that the installation or update process of the first application meets the preset conditions, it is considered that if the current installation status is not in progress, such as when a failure callback has been received or the application has been updated to be installed, obtaining the actual version identifier would be meaningless. Therefore, the current installation status in the installation task record of the first application is further judged. The actual version identifier of the first application is obtained only when the current installation status indicates that the first application is in progress, so as to avoid introducing subsequent redundant processing when the current installation status indicates that the first application has been downloaded or installed, thus saving system resources.

[0019] In one possible implementation, the installation task record also includes a timestamp indicating the generation of the installation task record; The step of determining whether the current installation status indicates that the first application is being installed includes: If the current installation status indicates that the first application is being installed, then the download and installation time of the first application from the start of download to the current moment is determined according to the generated timestamp; If the download and installation time does not exceed the second preset time threshold, then the step of obtaining the actual version identifier of the first application is executed.

[0020] Here, based on the current installation status of the first application, a timestamp is generated for time window filtering to determine whether the first application is in a "worthwhile probe" safe window period, avoiding invalid probes and significantly reducing system resource consumption.

[0021] Secondly, embodiments of this application provide an application installation processing apparatus, including: A generation module is used to generate an installation task record for the first application when the first application is downloaded; the installation task record includes the current installation status and expected version identifier of the first application. The acquisition module is used to acquire the actual version identifier of the first application if a preset condition is met during the installation or update process of the first application; wherein the preset condition is used to determine whether the current installation status of the first application is abnormal. The update module is used to update the current installation status according to the expected version identifier and the actual version identifier to obtain the actual installation status of the first application.

[0022] Thirdly, embodiments of this application provide a vehicle including a memory and a processor. The memory stores a computer program that can run on the processor. When the processor executes the computer program, it implements the application installation processing method as described in any of the first aspects.

[0023] Fourthly, embodiments of this application provide a computer-readable storage medium storing a computer program that, when executed by a processor, implements the application installation processing method as described in any of the first aspects.

[0024] It is understood that the beneficial effects of the second to fourth aspects mentioned above can be found in the relevant descriptions in the first aspect mentioned above, and will not be repeated here.

[0025] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit this specification. Attached Figure Description

[0026] To more clearly illustrate the technical solutions in the embodiments of this application, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0027] Figure 1 This is a schematic diagram of an application scenario provided by an embodiment of this application; Figure 2 This is a schematic flowchart of an application installation processing method provided in an embodiment of this application; Figure 3 This is a flowchart illustrating an application installation process according to another embodiment of this application; Figure 4 This is a schematic diagram of the structure of an application installation processing device provided in an embodiment of this application; Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0028] The present application will be described more clearly below with reference to specific embodiments. These embodiments will help those skilled in the art to further understand the function of the present application, but do not limit the present application in any way. It should be noted that those skilled in the art can make several modifications and improvements without departing from the concept of the present application. These all fall within the protection scope of the present application.

[0029] It should be understood that, when used in this application specification and the appended claims, the term "comprising" indicates the presence of the described features, integrals, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or a collection thereof.

[0030] It should also be understood that the term “and / or” as used in this application specification and the appended claims means any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0031] In the description of this application and the appended claims, the terms "first," "second," "third," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0032] References to "one embodiment" or "some embodiments" as described in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.

[0033] Furthermore, the term "multiple" mentioned in the embodiments of this application should be interpreted as two or more.

[0034] First, the terms used in the embodiments of this application will be explained: Application: Also known as a software application, it refers to a computer program or software product that can be installed and run on in-vehicle terminals, smartphones, tablets or other forms of electronic devices to provide specific application functions.

[0035] The inventors discovered that currently, when installing or updating applications, such as through application management software (e.g., app stores, app marketplaces, self-update modules), the installation is typically triggered by calling the system's application installation service and creating an installation session, with the installation result (e.g., successful or failed) obtained through an installation callback. However, this method has limitations in accurately obtaining the actual installation status of the application.

[0036] For example, after an app store initiates an installation request, the entire installation process typically takes several seconds to tens of seconds. If the app store process is terminated during this period due to reasons such as memory reclamation, user forced termination, or abnormal crash, the installation result will not be obtained from the installation callback. At this time, the actual installation process of the application may have succeeded or failed, but after the app store restarts, the interface may still display an "Installing" progress bar, which does not match the actual installation status of the application. This prevents the user from obtaining the true installation status of the application, and consequently, if the application installation fails, the user will not be able to re-trigger the application installation operation, causing the installation function to freeze.

[0037] Furthermore, when the app store process is abnormally terminated, even if the app status can be actively monitored, only the "whether the app is currently installed" and the "current version number" can be determined. Since the "expected target version" is not saved, the "current version number" alone cannot accurately define the following scenarios: if the current version number matches the expected version, it's impossible to distinguish whether the installation was successful this time or if the version already existed; if the current version number is lower than expected, it's impossible to determine whether the installation failed or the system has not yet completed processing; if the current version number is higher than expected, it's impossible to determine whether it was a manual upgrade by the user or an installation overwritten by a third-party channel. This uncertainty further impacts the user's installation experience.

[0038] Furthermore, when the installation process terminates abnormally, the installation session will continue to occupy system storage space and file descriptors, resulting in residual system resources. As such residual resources accumulate with each occurrence of the anomaly, they will not only consume a large amount of storage space, but may also cause subsequent installation requests to fail completely due to file descriptor exhaustion.

[0039] To address the aforementioned issues, the following technologies exist in the relevant fields: Application restore point technology: This type of technology creates a system state snapshot (including the expected version) before installation, and allows users to roll back to the snapshot state after installation. The goal of this type of technology is to achieve system-level state rollback, rather than fixing inconsistencies in business state caused by app store process anomalies. Its implementation heavily relies on a complete snapshot of the underlying system state.

[0040] Scheduled installation package cleanup techniques: These techniques use timed scans to delete installation package files that do not meet retention criteria. These techniques clean up the original installation packages in the file system, rather than active installation session objects within the system.

[0041] The system's built-in rollback mechanism: This mechanism is a system-level service that mainly serves the update rollback of system modules and is unrelated to the repair of the app store's own business status.

[0042] In other words, none of the relevant technologies can solve the problem that the actual installation status of an application may not be accurately obtained during the installation or update process. For example, if the application store process terminates unexpectedly, the installation status may remain and cannot be recovered.

[0043] Therefore, in the embodiments of this application, by generating an installation task record including the current installation status and expected version identifier of the application during application download, when preset conditions are met during the application installation or update process, i.e., when the application installation or update process may cause the current installation status in the installation task record to be abnormal, the actual version identifier of the application is obtained, and compared with the expected version identifier stored in the installation task record. By comparing the actual version identifier with the expected version identifier, the current installation status is updated so that it can accurately represent the actual installation status of the application. This avoids the situation where the true installation status cannot be accurately obtained during the application installation or update process, and displays the true installation status during the application installation or update process, avoiding installation function abnormalities caused by abnormal installation status display, and improving the user's application installation experience.

[0044] First refer to Figure 1 , Figure 1 The illustration shows an application scenario diagram provided according to the embodiments of this application. The device involved in the application scenario can be an electronic device such as an in-vehicle terminal or a mobile terminal.

[0045] For example, taking an in-vehicle terminal as an example, the execution subject of the application installation processing method provided in this application embodiment can be the in-vehicle application store in the in-vehicle terminal.

[0046] Specifically, when downloading an app, the in-vehicle app store can generate an installation task record that includes the app's current installation status and the expected version identifier. If the in-vehicle app store unexpectedly terminates during the app's installation or update process, it will obtain the app's actual version identifier. Then, based on the expected version identifier and the actual version identifier, it will update the app's current installation status to obtain the app's actual installation status.

[0047] In some embodiments, the execution subject of the application installation process may be the application to be installed or updated itself, or it may be a third-party application independent of the app store or the application itself, such as a system application. This embodiment does not limit this.

[0048] The following is combined Figure 1 Application scenarios, refer to Figures 2-3 This application describes an application installation processing method provided according to exemplary embodiments of the present application. It should be noted that the above application scenarios are shown only to facilitate understanding of the spirit and principles of the present application, and the embodiments of the present application are not limited in any way. Rather, the embodiments of the present application can be applied to any applicable scenario.

[0049] refer to Figure 2 , Figure 2 This is a schematic flowchart illustrating an application installation process provided in an embodiment of this application. Figure 2 As shown, the method in the embodiments of this application may include: Step 201: When downloading the first application, generate an installation task record for the first application.

[0050] The installation task record includes the current installation status and expected version identifier of the first application.

[0051] Here, the first application refers to the application that needs to be installed or updated, such as navigation applications or music applications in vehicle terminals or mobile terminals.

[0052] For example, the download and installation request for the first application can be initiated by the first application itself, or by the application management software (such as an app store or app market) in the vehicle terminal or mobile terminal that needs to install the first application, or by a third-party application (such as a webpage or system application in a browser) that is independent of the first application and the application management software. This embodiment does not limit the subject that initiates the download and installation request for the first application.

[0053] Similarly, the application that generates the installation task record for the first application (referred to as the second application) can also be the first application, application management software, or a standalone third-party application. In other words, the specific process of generating the installation task record for the first application when it is downloaded can be as follows: Scenario 1: After the first application initiates an update request, it starts requesting to download the installation package of the first application, and at the same time generates the installation task record of the first application.

[0054] Scenario 2: After the application management software initiates an installation or update request for the first application, it starts requesting to download the installation package of the first application and generates an installation task record for the first application at the same time.

[0055] Scenario 3: After the browser initiates an installation or update request for the first application, it starts requesting to download the installation package of the first application and at the same time generates an installation task record for the first application.

[0056] Scenario 4: After the first application initiates an update request, it begins to request the download of the first application's installation package. At the same time, the application management software or a third-party application generates an installation task record for the first application.

[0057] It is understood that the above example scenarios are only used to illustrate the subject that initiates the application download request and the subject that generates the installation task record. The embodiments of this application can also be used in other scenarios with the need to install or update applications.

[0058] Based on this, when generating the installation task record for the first application, the current installation status and expected version identifier of the first application can be stored in the installation task record.

[0059] The current installation status represents the current installation progress of the first application. For example, when a request to download the first application begins, the current installation status can be "Downloading". After the first application is downloaded, the current installation status can be "Downloading Completed". When the system's application installation service is invoked, the current installation status can be "Installing". After receiving the installation result from the installation callback, the current installation status can be either "Installed" or "Installation Failed".

[0060] The expected version identifier represents the target version expected for this installation or update, which can be the versionCode written before the installation is initiated.

[0061] In this embodiment, by generating an installation task record that includes the current installation status and expected version identifier of the first application when downloading the first application, a basis for determining the actual installation status of the first application can be provided.

[0062] Step 202: During the installation or update of the first application, if the preset conditions are met, the actual version identifier of the first application is obtained.

[0063] The preset conditions are used to determine whether the current installation status of the first application is abnormal.

[0064] Here, by using preset conditions, the system evaluates whether the current installation status in the installation task record is abnormal during the installation or update process of the first application. This serves as the trigger condition for obtaining the actual version identifier. When the current installation status in the installation task record is determined to be abnormal, i.e., when the preset conditions are met during the installation or update process of the first application, the operation of obtaining the actual version identifier of the first application is triggered. This identifier is then used for subsequent comparison processing to determine the true actual installation status of the first application. When the current installation status in the installation task record is determined to be normal, no further processing is performed. By determining whether the installation or update process of the first application meets the preset conditions, subsequent processing is performed on cases that meet the preset conditions, avoiding the waste of system resources by continuously obtaining the actual version identifier and performing subsequent processing without any conditional restrictions.

[0065] For example, the preset condition could be that the download and installation time of the first application from the start of download to the current moment exceeds a first preset time threshold.

[0066] In this scenario, when generating the installation task record for the first application, in addition to storing the current installation status and desired version identifier, the generation timestamp of the installation task record can also be stored. Based on the generation timestamp, the download and installation time of the first application from the start of download to the current moment can be determined. Then, the download and installation time is compared with a first preset time threshold. If the download and installation time exceeds the first preset time threshold, the preset condition is determined to be met. If the download and installation time does not exceed the first preset time threshold, the preset condition is determined not to be met.

[0067] Here, the first preset time threshold can be determined based on the time required for the first application to go from download to installation. For example, if the time required for the first application to go from download to installation is generally 1 minute, then the first preset time threshold can be 1 minute. Then, by comparing the download and installation time with the first preset time threshold, it is determined whether the download and installation time of the first application exceeds the normal download and installation time. If the download and installation time exceeds the normal download and installation time, it is determined that the current installation status of the first application is abnormal, that is, the installation or update process of the first application meets the preset conditions.

[0068] In some embodiments, a preset time margin can also be set to determine a first preset time threshold based on the time required for the first application to go from download to installation and the corresponding preset time margin. For example, if the time required for the first application to go from download to installation is generally 1 minute and the preset time margin is 10 seconds, then the first preset time threshold can be 70 seconds.

[0069] In some embodiments, the application type to which the first application belongs can also be determined so as to determine the first preset time threshold based on the time required for the application of the corresponding application type to go from download to installation and the corresponding preset time margin.

[0070] This embodiment provides a general logic for determining whether the installation or update process of a first application meets preset conditions from the perspective of the time required for application download and installation. This logic satisfies the judgment of preset conditions under different installation or update scenarios and improves the applicability of the application installation processing method.

[0071] In some embodiments, it can also be determined whether the installation or update process of the first application meets preset conditions through other means. For example, when generating the installation task record of the first application through the second application and receiving feedback on the application installation status, it can also be determined whether the installation or update process of the first application meets preset conditions by monitoring the process status of the second application.

[0072] Step 203: Update the current installation status based on the expected version identifier and the actual version identifier to obtain the actual installation status of the first application.

[0073] Here, the expected version identifier represents the target version that the first application is expected to be installed or updated in this process, and the actual version identifier represents the current actual version of the first application. By using the expected version identifier and the actual version identifier, it can be determined whether the current actual version of the first application is consistent with the expected target version, and thus determine the actual installation status of the first application.

[0074] In this embodiment, by generating an installation task record including the current installation status and expected version identifier of the first application during the download of the first application, when preset conditions are met during the installation or update of the first application (i.e., when the installation or update process of the first application may cause the current installation status in the installation task record to be abnormal), the actual version identifier of the first application is obtained and compared with the expected version identifier stored in the installation task record. This comparison allows the current installation status to be updated, ensuring it accurately represents the actual installation status of the first application. This avoids situations where the true installation status cannot be accurately obtained during the application's installation or update process, and displays the true installation status during the application's installation or update process. It also prevents installation function malfunctions caused by abnormal installation status display, thus improving the user's application installation experience.

[0075] In another embodiment of this application, an application installation process is considered where, while downloading the first application, an installation task table is created using the second application and installation task records are stored, and feedback on the application installation status is received. Figure 3 A flowchart illustrating an application installation process method provided in another embodiment of this application is shown below. Figure 3 As shown, the method includes: Step 301: When downloading the first application, generate an installation task record for the first application.

[0076] The installation task record includes the current installation status and expected version identifier of the first application.

[0077] Here, for the implementation of step 301, please refer to [link / reference]. Figure 2 The relevant descriptions in the embodiments will not be repeated here.

[0078] Step 302: During the installation or update of the first application, monitor the process status of the second application.

[0079] The second application is used to create an installation task table to store the installation task records of the application, and after the application is installed or updated, it receives feedback on the application installation status and updates the corresponding installation task records.

[0080] Here, the installation task record of the first application is generated through the second application, and the application installation status feedback is received to update the current installation status in the installation task record.

[0081] It should be noted that the second application can be the same as the first application. For example, when updating within the navigation application, the navigation application initiates a download update request, generates an installation task record, and monitors the process status of the navigation application.

[0082] Alternatively, the second application can be different from the first application. For example, when installing or updating a navigation application in the in-vehicle app store, the in-vehicle app store initiates the installation or update request for the navigation application and generates an installation task record, while monitoring the process status of the in-vehicle app store.

[0083] Alternatively, when installing or updating a navigation app within the in-vehicle app store, the in-vehicle app store can initiate the installation or update request for the navigation app, and an independent third-party app (such as a system app) can generate an installation task record while monitoring the process status of that third-party app.

[0084] For example, taking a navigation application as the first application and an in-vehicle app store as the second application, the above process will be explained as follows: First, an installation task table can be created in the private database of the in-vehicle app store to store the installation task records of the navigation app after the in-vehicle app store initiates an installation or update request for the navigation app.

[0085] For example, the installation task record may include, but is not limited to, the following fields: the package name of the application to be installed (i.e., the navigation application), the version number expected to be reached in this installation (i.e., the expected version identifier), the current installation status (the value can be download completed, installation in progress, or installed / updated), the timestamp when the installation task record was created (which can be accurate to milliseconds), and the corresponding installation session identifier, which is used for subsequent installation session cleanup.

[0086] Here, by creating an installation task table in the private database of the in-vehicle app store and storing the installation task records of the corresponding applications, installation task-related information, including the expected version identifier, can be recorded at the application layer through a lightweight database.

[0087] Next, after initiating an installation or update request for the navigation app in the in-vehicle app store, an installation task record is generated. At this point, the current installation status in the installation task record can be "Downloading". Once the navigation app is downloaded, the current installation status can be updated to "Download Completed". When the system's application installation service is invoked to submit the installation, the current installation status can be updated to "Installing".

[0088] During the installation process of a navigation app, the in-vehicle app store monitors its own process status to determine whether it can accurately update the current installation status in the installation task record corresponding to the navigation app.

[0089] Step 303: If the process status indicates that the second application has been terminated, then it is determined that the preset conditions are met, and the actual version identifier of the first application is obtained.

[0090] When the second application is terminated, the application installation status feedback will be stopped.

[0091] Here, consider the scenario where the process status of the second application indicates that the second application has been terminated, meaning that the second application can no longer receive the application installation status of the first application. In this case, the current installation status in the installation task record updated by the second application is highly likely to be inconsistent with the actual installation status of the corresponding application. Therefore, it is determined that other processing procedures need to be adopted to update the current installation status in the installation task record to avoid the problem of not being able to accurately obtain the true installation status of the first application when the second application is terminated.

[0092] In one embodiment, considering that the termination time of the second application varies, the reliability of the current installation status in the installation task record updated by the second application also varies. Therefore, after the process status of the second application indicates that the second application has been terminated, the download termination time of the first application from the start of download to the termination of the second application is also obtained. When the download termination time exceeds a third preset time threshold, it can be considered that when the second application is terminated, the download and installation process or download and update process of the first application has ended. Therefore, the reliability of the current installation status in the installation task record updated by the second application is high, and there is no need to obtain the actual version identifier of the first application for further judgment.

[0093] If the download termination time does not exceed the third preset time threshold, it can be considered that the second application was terminated earlier. At this time, the current installation status in the installation task record may not have been updated yet, so it is necessary to obtain the actual version identifier of the first application for further judgment.

[0094] For example, the third preset time threshold can be the same as the first preset time threshold. Alternatively, to ensure the accuracy of the actual installation status of the first application, the third preset time threshold can be greater than the first preset time threshold.

[0095] In some embodiments, after preset conditions are met during the installation or update of the first application, in order to make subsequent processing meaningful and avoid wasting resources, the current installation status and / or generated timestamp in the installation task record can be further verified.

[0096] For example, after the preset conditions are met, it can be further determined whether the current installation status indicates that the first application is being installed; if the current installation status indicates that the first application is being installed, then the step of obtaining the actual version identifier of the first application is executed.

[0097] Here, after determining that the installation or update process of the first application meets the preset conditions, it is considered that if the current installation status is not in progress, such as when a failure callback has been received or the application has been updated to be installed, obtaining the actual version identifier would be meaningless. Therefore, the current installation status in the installation task record of the first application is further judged. The actual version identifier of the first application is obtained only when the current installation status indicates that the first application is in progress, so as to avoid introducing subsequent redundant processing when the current installation status indicates that the first application has been downloaded or installed, thus saving system resources.

[0098] Alternatively, after the preset conditions are met, it is further determined whether the current installation status indicates that the first application is being installed, and whether the download and installation time of the first application from the start of download to the current moment exceeds the second preset time threshold (the second preset time threshold can be greater than the first preset time threshold). If the current installation status indicates that the first application is being installed, and the download and installation time does not exceed the second preset time threshold, then the step of obtaining the actual version identifier of the first application is executed.

[0099] Here, based on the current installation status of the first application, a timestamp is generated for time window filtering to determine whether the first application is in a "worthwhile probe" safe window period, avoiding invalid probes and significantly reducing system resource consumption.

[0100] It is understandable that when introducing the generation timestamp for time window filtering, in addition to determining the download and installation time of the first application from the start of download to the current moment, a time range can also be directly determined based on the current moment, such as the range from the preset time (such as 12 hours or 24 hours) before the current moment to the current moment, so as to determine whether the generation timestamp of the installation task record is within the corresponding time range, so as to determine whether the first application is in a "worthwhile detection" safe window period.

[0101] It should be noted that, considering the second application generating the installation task record of the first application while simultaneously monitoring its own process status, after the process status indicates that the second application has been terminated, it is possible to wait for the second application to be restarted before obtaining the actual version identifier of the first application. Alternatively, after the process status indicates that the second application has been terminated, a third-party application can be called to obtain the actual version identifier of the first application.

[0102] In some embodiments, if the second application is not terminated and a successful installation callback of the first application is received during the monitoring of the process status of the second application, the current installation status can be directly updated to indicate that the first application has been installed or updated, without further processing.

[0103] Step 304: Update the current installation status based on the expected version identifier and the actual version identifier to obtain the actual installation status of the first application.

[0104] Specifically, the actual version identifier and the expected version identifier can be compared; based on the comparison result, the installation or update result of the first application can be determined; the current installation status can be updated to the installation or update result of the first application as the actual installation status of the first application; wherein, the installation or update result is the status of being installed, updated, or downloaded.

[0105] For example, the version identifier may include a version number, where a higher version number indicates a higher version level. When determining the installation or update result of the first application, if the actual version number is equal to or greater than the expected version number, the installation or update result of the first application is determined to be "installed" or "updated"; if the actual version number is less than the expected version number, the installation or update result of the first application is determined to be "download complete".

[0106] In this embodiment, after judging based on preset conditions, a time window filter can be performed first to query only installation task records whose creation time (i.e., generation timestamp) is within the preset window (e.g., 24 hours) and whose status is "installing". Then, the version number of the currently installed first application is obtained as the actual version number. Finally, the actual version number is compared with the expected version number, and different processing is performed according to the comparison result: If the actual version number equals the expected version number, the installation has been successfully completed, and the status in the database will be updated to "Installed or Updated".

[0107] If the actual version number is less than the expected version number, the installation has failed. The status will be updated to "Download Complete" so that the user can try to install again, and any remaining installation sessions will be cleaned up.

[0108] If the actual version number is greater than the expected version number, it means that a higher version than expected has appeared in the system (possibly due to manual update by the user or installation through other channels). In this case, delete the installation task recorded by this application and clean up any remaining sessions.

[0109] In one embodiment, considering the case that the first application is a newly installed application, after obtaining the actual version identifier of the first application, if the actual version number of the first application is empty, it means that the first application has not been installed, and the installation or update result of the first application can be determined to be that the download is complete.

[0110] This embodiment considers the case where the first application has not yet been installed and there is no old version. In this case, the installation or update result of the first application is also determined as the download is complete so that the first application can be reinstalled.

[0111] In one embodiment, in order to further accurately determine the actual installation status of the first application based on the actual version number and the expected version number, signature verification can also be performed. For example, when the actual version number is equal to the expected version number, signature verification can be used to further determine whether the first application was installed through the corresponding installation session.

[0112] In one embodiment, the installation task record also includes an installation session identifier for the first application; after updating the current installation status to the installation or update result of the first application, if the actual installation status of the first application is installed, updated, or downloaded, the session abandonment interface is called; the session abandonment interface is used to clean up the installation session corresponding to the installation session identifier.

[0113] Here, by adding an installation session identifier to the installation task record, after the first application's installation or update process meets preset conditions and its current installation status is updated based on the obtained actual version identifier and expected version identifier, the installation session created during the installation or update process of the first application can be cleaned up by calling the abandon session interface. This avoids situations where the installation session cannot be properly cleaned up due to an abnormal current installation status during the installation or update process of the first application. Furthermore, timely cleanup of installation sessions can also reduce the memory consumption caused by invalid installation sessions, allowing subsequent installation or update operations to proceed normally and preventing the installation function from freezing.

[0114] For example, in order to achieve precise cleanup of installation sessions, all active installation sessions in the system can be obtained, and installation sessions whose creator is the target application (such as a second application) can be filtered out. Then, the session abandonment interface can be called for each installation session that meets the criteria to release the system resources it occupies.

[0115] This embodiment addresses the issue of inaccurately obtaining the true installation status of applications during installation, such as the loss of the actual installation status of applications to be installed or updated due to unexpected termination of the app store process. By pre-recording the expected version number using installation task records and associating it with the generation timestamp of the installation task records, the actual installation result (success / failure / higher version / tampering) of the application to be installed or updated is accurately determined when the app store restarts through version number comparison, signature verification, and time window filtering. This ensures that the installation status recorded in the database automatically matches the actual system installation status, allowing the interface to immediately return to the correct state and always reflect the true situation without user intervention. Simultaneously, all installation sessions created by this application but not properly closed are automatically cleaned up upon restart, preventing storage leaks. This approach is suitable for various installation scenarios, including app store updates and self-updates.

[0116] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0117] Figure 4 This is a schematic diagram of the structure of an application installation processing device provided in one embodiment of this application. For example... Figure 4 As shown, the application installation processing device provided in this embodiment may include: a generation module 401, an acquisition module 402, and an update module 403.

[0118] The generation module 401 is used to generate an installation task record for the first application when downloading the first application; the installation task record includes the current installation status and expected version identifier of the first application.

[0119] The acquisition module 402 is used to acquire the actual version identifier of the first application if a preset condition is met during the installation or update process of the first application; wherein the preset condition is used to determine whether the current installation status of the first application is abnormal.

[0120] The update module 403 is used to update the current installation status according to the expected version identifier and the actual version identifier to obtain the actual installation status of the first application.

[0121] In one possible implementation, module 402 is also used for: Monitor the process status of the second application; the second application is used to create an installation task table to store the installation task records of the application, and after the application is installed or updated, it receives the application installation status feedback from the application and updates the corresponding installation task records. If the process status indicates that the second application has been terminated, then the preset condition is determined to be met; wherein, when the second application is terminated, the application installation status feedback from the application is stopped.

[0122] In one possible implementation, the installation task record further includes a timestamp indicating the generation of the installation task record; the acquisition module 402 is further configured to: Based on the generated timestamp, determine the download and installation time of the first application from the start of download to the current moment; If the download and installation time exceeds the first preset time threshold, then the preset condition is determined to be met.

[0123] In one possible implementation, update module 403 is specifically used for: Compare the actual version identifier with the expected version identifier; Based on the comparison results, determine the installation or update result of the first application; The current installation status is updated to the installation or update result of the first application, which serves as the actual installation status of the first application. The installation or update result refers to a status indicating that the installation, update, or download is complete.

[0124] In one possible implementation, the version identifier includes a version number, with higher version numbers indicating higher version levels; update module 403 is specifically used for: If the actual version number is equal to or greater than the expected version number, then the installation or update result of the first application is determined to be an installed or updated state. If the actual version number is less than the expected version number, then the installation or update result of the first application is determined to be a complete download.

[0125] In one possible implementation, the installation task record further includes the installation session identifier of the first application; the update module 403 is also used for: If the actual installation status of the first application is installed, updated, or downloaded, then the session abandonment interface is called. The installation session corresponding to the installation session identifier is cleaned up using the abandoned session interface.

[0126] In one possible implementation, module 402 is also used for: Determine whether the current installation status indicates that the first application is being installed; If the current installation status indicates that the first application is being installed, then the step of obtaining the actual version identifier of the first application is executed.

[0127] In one possible implementation, the installation task record further includes a timestamp indicating the generation of the installation task record; the acquisition module 402 is specifically used for: If the current installation status indicates that the first application is being installed, then the download and installation time of the first application from the start of download to the current moment is determined according to the generated timestamp; If the download and installation time does not exceed the second preset time threshold, then the step of obtaining the actual version identifier of the first application is executed.

[0128] It should be noted that the information interaction and execution process between the above-mentioned devices / units are based on the same concept as the method embodiments of this application. For details on their specific functions and technical effects, please refer to the method embodiments section, and they will not be repeated here.

[0129] Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. For example... Figure 5As shown, the electronic device 500 of this embodiment includes a processor 510 and a memory 520, wherein the memory 520 stores a computer program 521 that can run on the processor 510. When the processor 510 executes the computer program 521, it implements the steps in any of the above-described method embodiments, for example... Figure 2 Steps 201 to 203 are shown. Alternatively, when processor 510 executes computer program 521, it implements the functions of each module / unit in the above-described device embodiments, for example... Figure 4 The functions of modules 401 to 403 are shown.

[0130] For example, computer program 521 may be divided into one or more modules / units, one or more of which are stored in memory 520 and executed by processor 510 to complete this application. The one or more modules / units may be a series of computer program instruction segments capable of performing a specific function, which describe the execution process of computer program 521 in electronic device 500.

[0131] Those skilled in the art will understand that Figure 5 This is merely an example of an electronic device and does not constitute a limitation on the electronic device. It may include more or fewer components than shown, or combinations of certain components, or different components, such as input / output devices, network access devices, buses, etc.

[0132] The processor 510 can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or any conventional processor.

[0133] The memory 520 can be an internal storage unit of the electronic device, such as a hard drive or memory, or an external storage device, such as a plug-in hard drive, SmartMedia Card (SMC), Secure Digital (SD) card, or Flash Card. The memory 520 can also include both internal and external storage units. The memory 520 is used to store computer programs and other programs and data required by the vehicle. The memory 520 can also be used to temporarily store data that has been output or will be output.

[0134] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments 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. Furthermore, the specific names of the functional units and modules are only for easy differentiation and are not intended to limit the scope of protection of this application. The specific working process of the units and modules in the above system can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0135] An embodiment of this application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the application installation processing method described above.

[0136] An embodiment of this application also provides a vehicle that includes the aforementioned electronic equipment.

[0137] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail or recorded in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0138] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

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

[0140] 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 network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

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

[0142] If the integrated module / 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, all or part of the processes in the methods of the above embodiments can also be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable medium can include: any entity or device capable of carrying the computer program code, a recording medium, a USB flash drive, a portable hard drive, a magnetic disk, an optical disk, a computer memory, a read-only memory (ROM), a random access memory (RAM), an electrical carrier signal, a telecommunication signal, and a software distribution medium, etc.

[0143] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. An application installation processing method, characterized in that, include: When the first application is downloaded, an installation task record for the first application is generated; The installation task record includes the current installation status and expected version identifier of the first application; During the installation or update process of the first application, if a preset condition is met, the actual version identifier of the first application is obtained; wherein, the preset condition is used to determine whether the current installation status of the first application is abnormal. Based on the expected version identifier and the actual version identifier, the current installation status is updated to obtain the actual installation status of the first application.

2. The application installation processing method according to claim 1, characterized in that, The method further includes: Monitor the process status of the second application; the second application is used to create an installation task table to store the installation task records of the application, and after the application is installed or updated, it receives the application installation status feedback from the application and updates the corresponding installation task records. If the process status indicates that the second application has been terminated, then the preset condition is determined to be met; wherein, when the second application is terminated, the application installation status feedback from the application is stopped.

3. The application installation processing method according to claim 1, characterized in that, The installation task record also includes a timestamp indicating when the installation task record was generated; The method further includes: Based on the generated timestamp, determine the download and installation time of the first application from the start of download to the current moment; If the download and installation time exceeds the first preset time threshold, then the preset condition is determined to be met.

4. The application installation processing method according to any one of claims 1 to 3, characterized in that, The step of updating the current installation status based on the expected version identifier and the actual version identifier to obtain the actual installation status of the first application includes: Compare the actual version identifier with the expected version identifier; Based on the comparison results, determine the installation or update result of the first application; The current installation status is updated to the installation or update result of the first application, which serves as the actual installation status of the first application. The installation or update result refers to a status indicating that the installation, update, or download is complete.

5. The application installation processing method according to claim 4, characterized in that, Version identification includes a version number; the higher the version number, the higher the version level. Determining the installation or update result of the first application based on the comparison results includes: If the actual version number is equal to or greater than the expected version number, then the installation or update result of the first application is determined to be an installed or updated state. If the actual version number is less than the expected version number, then the installation or update result of the first application is determined to be a complete download.

6. The application installation processing method according to claim 4, characterized in that, The installation task record also includes the installation session identifier of the first application; After updating the current installation status to the installation or update result of the first application, the method further includes: If the actual installation status of the first application is installed, updated, or downloaded, then the session abandonment interface is called. The installation session corresponding to the installation session identifier is cleaned up using the abandoned session interface.

7. The application installation processing method according to any one of claims 1 to 3, characterized in that, After the preset conditions are met, the following is also included: Determine whether the current installation status indicates that the first application is being installed; If the current installation status indicates that the first application is being installed, then the step of obtaining the actual version identifier of the first application is executed.

8. The application installation processing method according to claim 7, characterized in that, The installation task record also includes a timestamp indicating when the installation task record was generated; The step of determining whether the current installation status indicates that the first application is being installed includes: If the current installation status indicates that the first application is being installed, then the download and installation time of the first application from the start of download to the current moment is determined according to the generated timestamp; If the download and installation time does not exceed the second preset time threshold, then the step of obtaining the actual version identifier of the first application is executed.

9. An electronic device comprising a memory and a processor, wherein the memory stores a computer program executable on the processor, characterized in that, When the processor executes the computer program, it implements the application installation processing method as described in any one of claims 1 to 8.

10. A vehicle, characterized in that, Including the electronic device as described in claim 9.

Images