Cross-process media file path notification method

Abstract

The invention provides a cross-process media file path notification method, and relates to the technical field of software development, and the method comprises the steps: transmitting a file path through path parameters newly added by various methods in a first transmission process of notification, and recording the file path through a Bundle object newly added in an internal notification method; calling a notification change method of newly added additional parameters in the content parser through an internal notification method so as to send a notification containing a file path to a content service; carrying a file path through additional parameters newly added by various methods in a second transmission process of the notification, and recording the file path through additional variables newly added in a Key class of the content; and based on the Key class, distributing notifications containing the file paths to corresponding observers. The objective of the invention is to improve the extended data transmission capability in cross-process notification.

Description

Technical Field

[0001] This application relates to the field of software development technology, specifically to a cross-process media file path notification method. Background Technology

[0002] Due to its open-source nature and ease of development, Android is now widely used in various intelligent devices (such as terminals and in-vehicle systems). The cross-process notifications of ContentProvider and ContentService in Android, through abstraction and interface standardization, decouple the specific implementation of data / services from the calling method. This ensures that even if the underlying process implementation or Android version changes, the externally provided access interface remains stable, thereby enhancing system compatibility.

[0003] However, the traditional ContentProvider and ContentService cross-process notifications in the current Android system have at least two drawbacks when handling media notification delivery (such as a library monitoring USB drives and local media data). The first drawback is the lack of a strict authentication mechanism, which poses a risk of forgery and theft. Currently, the notifyChange method in ContentService in the Android system is insufficient for authentication. An application only needs basic permissions such as WRITE_EXTERNAL_STORAGE to call notifyChange and send fake notifications (e.g., forging fake events like "USB drive inserted" or "new photo generated"). The second drawback is the lack of extended data delivery capabilities, making it unsuitable for various scenarios. For example, a library cannot determine whether a new file comes from local storage or a USB drive through the notification; it needs to update both local files and USB drive content, or perform additional queries to differentiate, increasing process complexity and time consumption. Summary of the Invention

[0004] In view of this, this application provides a cross-process media file path notification method, which aims to solve or partially solve the problems existing in the background art.

[0005] This application provides a cross-process media file path notification method, the method comprising: During the first transmission of the notification, the file path information is transmitted through the path parameters added by various methods in the first transmission process, and the file path information is received and recorded by the Bundle object added in the notifySingleChangeInternal method. The first transmission process is the process of the notification being transmitted to the notifySingleChangeInternal method. The notifySingleChangeInternal method calls the notifyChange method of the ContentResolver instance with the added additional parameter, and sends a notification containing the file path information to the ContentService. The file path information stored in the newly added Bundle object is carried by the additional parameter added in the notifyChange method. During the second transmission of the notification, the file path information is carried by the additional parameters added by various methods in the second transmission process, and the file path information is received and recorded by the additional variable added in the Key class of ContentService. The second transmission process is the process of transmitting the notification to the Key class of ContentService after receiving the notification. Based on the Key class, a notification containing the file path information is distributed to the corresponding ContentObserver, so that the registrant of the ContentObserver can obtain the notification containing the file path information through the Key class.

[0006] The cross-process media file path notification method provided in this application has the following advantages: The cross-process media file path notification method provided in this application supports extended data carrying. When notifyingChange is called, file metadata, such as storage type ("is_usb": true or false) and file path ("path": path), is attached through a Bundle object. After receiving the notification, the application (e.g., a library) can directly distinguish whether the file comes from a USB drive or the local machine based on the storage type "is_usb", and directly query the updated USB drive content or local machine content, reducing the query process time.

[0007] Furthermore, the cross-process media file path notification method provided in this application employs a two-way authentication mechanism. Only pre-authorized trusted applications, such as the system's MediaProvider, are allowed to call `notifyChange`. This involves matching the package name against the pre-authorized list and verifying the application's signature hash. Before the ContentService distributes the notification, the package name is obtained via the recipient's UID. It is then verified whether the recipient is on the pre-authorized recipient list (e.g., a gallery application) and whether the signature matches. Notifications are only distributed to recipients if the recipient is on the pre-authorized recipient list (e.g., a gallery application) and the signature matches. This two-way authentication mechanism performs double verification of the package name and signature, allowing only pre-authorized legitimate applications to participate in the notification process. This prevents malicious applications from impersonating senders / recipients, improving the security of cross-process notifications and resisting malicious attacks. Simultaneously, under this two-way authentication mechanism, notifications containing the path are only distributed to trusted recipients such as gallery applications. Unauthorized applications (e.g., malicious utility apps) are directly filtered out, preventing path information leakage at the source, thereby protecting user privacy and enabling precise filtering of recipients. Attached Figure Description

[0008] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the description of the embodiments of this application will be briefly introduced below. Obviously, the accompanying 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.

[0009] Figure 1 A flowchart illustrating a cross-process media file path notification method according to one embodiment of this application; Figure 2 The diagram illustrates the core classes related to a cross-process media file path notification method in one embodiment of this application. Figure 3 This application illustrates a timing diagram for triggering notification and verifying sender access in a cross-process media file path notification method according to one embodiment of the present application. Figure 4 This is a timing diagram illustrating a cross-process media file path notification method according to one embodiment of this application, showing the verification of the recipient and the distribution of the notification to the gallery application; Figure 5 This is another flowchart illustrating a cross-process media file path notification method according to one embodiment of this application. Detailed Implementation

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

[0011] Definitions: Media Provider: The Android Media Provider is an important component in the Android system used to manage media files and related information.

[0012] DataBaseHelper: Android DataBaseHelper is a class used in Android development to assist in database management. It is typically responsible for creating the database, performing initialization operations such as table creation, and providing basic operations such as adding, deleting, modifying, and querying data. Using DataBaseHelper makes database-related development and maintenance much easier.

[0013] ContentService: In the Android system, ContentService is the core system service responsible for managing cross-application data sharing and notification mechanisms, serving as the "central nervous system" of the ContentProvider framework. It coordinates data access permissions, distributes data change notifications, and ensures the security and orderliness of cross-process data interaction through a unified interface.

[0014] ContentResolver: In Android development, ContentResolver is a "unified interface" for applications to access cross-process data and is the core interaction layer of the ContentProvider framework. It hides the complex details of cross-process communication, providing developers with a simple and consistent API for querying, inserting, updating, or deleting data (such as media files, contacts, SMS messages, etc.) exposed by other applications through ContentProvider.

[0015] ContentObserver: In Android development, ContentObserver is a mechanism used to listen for changes in data in a ContentProvider. It allows applications to be aware of operations such as insertion, update, and deletion of target data in real time without actively polling. It is a core tool for achieving the linkage between "data change and UI refresh".

[0016] Key class description: ContentService Core responsibility: Implement two-way authentication logic to filter unauthorized senders and receivers and ensure secure notification distribution.

[0017] Core functionality: Observers are managed through ObserverCollector, and notifications are distributed by calling the ContentObserver interface.

[0018] MediaProvider Core responsibility: As the media data sender, trigger a notification after inserting data and attach extended information such as file path.

[0019] Core Relationship: Relies on DatabaseHelper to query file paths and calls ContentService's notifyChange to send notifications.

[0020] ContentService.ObserverCollector Core responsibilities: Manage the list of pre-authorized senders / receivers, provide signature hash verification capabilities, collect matching observers, filter unauthorized recipients, and finally distribute notifications to legitimate recipients.

[0021] Core connection: Internal storage of ContentObserver instances (receivers), which rely on the validation methods of ContentService for filtering.

[0022] ContentObserver and GalleryContentObserver ContentObserver: Defines the standard method for receiving notifications (onChangeEtc).

[0023] GalleryContentObserver: The specific implementation of the receiving application (such as a gallery), which processes notifications and refreshes data.

[0024] DatabaseHelper Core responsibility: Providing database access capabilities, which the MediaProvider uses to query the path of inserted files (the DATA field). For example... Figure 2 As shown, Figure 2 The diagram shows the core class diagram for cross-process notifications in the Android system.

[0025] Before describing the cross-process media file path notification method provided in this application, the background of this application should be explained. This application finds that the current Android system's ContentProvider and ContentService cross-process notifications have the following drawbacks when handling media notification delivery (such as the library listening to USB flash drive and local media data): First, there is a lack of strict authentication mechanism, which poses a risk of forgery and theft. Currently, the notifyChange method in the ContentService of the Android system is insufficient in authenticating the sender and receiver. As long as the application obtains basic permissions such as WRITE_EXTERNAL_STORAGE, it can call notifyChange to send fake notifications (such as forging fake events such as "USB flash drive inserted" or "new photo generated"). This will cause the library and other receivers to receive invalid notifications, triggering meaningless refreshes (such as displaying non-existent files), or even causing crashes due to invalid paths. Applications can register ContentObserver to listen for changes in the media library without verifying its legitimacy. Malicious applications can use this to steal sensitive file paths (such as the path of private photos on a USB flash drive), and then access or tamper with files through the path, causing user data leakage. The second issue is the lack of extended data transmission capabilities, which fails to adapt to diverse scenario requirements. For example, image libraries cannot determine whether a new file originates from local storage or a USB drive through notifications, requiring updates to both local files and USB drive content, or additional queries to differentiate them, increasing process complexity and time consumption. Based on this, this application proposes a cross-process media file path notification method to address the aforementioned problems.

[0026] refer to Figure 1 , Figure 1 This is a flowchart illustrating a cross-process media file path notification method according to one embodiment of this application. Figure 1 As shown, the method includes: Step S01: In the first transmission process of the notification, the file path information is transmitted through the path parameters added by various methods in the first transmission process, and the file path information is received and recorded by the Bundle object added in the notifySingleChangeInternal method. The first transmission process is the process of the notification being transmitted to the notifySingleChangeInternal method.

[0027] In this embodiment, in the cross-process notification of the Android system, the notification is first actively triggered by the business logic of the ContentProvider after the database operation is successful. This application divides the process of generating a notification and passing it to the notifySingleChangeInternal method through a series of methods into the first transmission process. To ensure that the file path information of the media corresponding to the update action is also transmitted during the transmission process of the notification generated after the system media library updates the database, this application adds path parameters to various methods involved in notification transmission in the first transmission process. The path parameters added in each type of method are used to transmit the file path information of the media corresponding to the notification. At the same time, a Bundle object is added to the notifySingleChangeInternal method. When the notification is transmitted to the notifySingleChangeInternal method, the Bundle object added in the notifySingleChangeInternal method receives and records the file path information of the media corresponding to the notification.

[0028] Step S02: Call the notifyChange method of the ContentResolver instance with the added additional parameter through the notifySingleChangeInternal method to send a notification containing the file path information to the ContentService. The file path information stored in the newly added Bundle object is carried by the additional parameter added in the notifyChange method.

[0029] In this embodiment, to pass the file path information corresponding to the notification to the ContentService, this application adds an additional parameter (i.e., adds an extras parameter) to the notifyChange method in the ContentResolver instance. After the notification is passed to the notifySingleChangeInternal method, and the Bundle object added by the notifySingleChangeInternal method receives and records the file path information, the notifySingleChangeInternal method calls the notifyChange method with the added additional parameter in the ContentResolver instance to send the notification containing the file path information to the ContentService.

[0030] Step S03: In the second transmission process of the notification, the file path information is carried by the additional parameters added by various methods in the second transmission process, and the file path information is received and recorded by the additional variable added in the Key class of ContentService. The second transmission process is the process of transmitting the notification to the Key class of ContentService after receiving the notification.

[0031] In this embodiment, the process of transmitting a notification from the ContentService to its Key class after receiving it is divided into a second transmission process. To ensure that the file path information corresponding to the notification can be transmitted to the ContentObserver, this application adds additional parameters (i.e., adds extras parameters) to various methods involved in notification transmission during the second transmission process. These additional parameters in each method are used to transmit the file path information of the media corresponding to the notification. Simultaneously, additional variables are added to the Key class of the ContentService. After the notification is transmitted to the ContentService, the file path information corresponding to the notification is ultimately received and recorded by these additional variables in the Key class of the ContentService through internal method calls. The ContentService has an inner class ObserverCollector, which has a member variable `collected` (of type ArrayMap). <Key, List <uri>>), the Key class belongs to the collected collection.

[0032] Step S04: Based on the Key class, distribute the notification containing the file path information to the corresponding ContentObserver, so that the registrant of the ContentObserver can obtain the notification containing the file path information through the Key class.

[0033] In this embodiment, after recording the file path information corresponding to the notification in the additional variable added to the Key class, the notification containing the file path information can be distributed to the corresponding ContentObserver based on the information recorded in the Key class, so that the registrant of the ContentObserver can obtain the notification containing the file path information through the information recorded in the Key class. The notification contains at least URI, file path information and flags.

[0034] The cross-process media file path notification method provided in this application supports extended data carrying. When notifyChange is called, file metadata, such as the file path ("path": path), is attached via a Bundle object. After receiving the notification, the application (e.g., a library) can directly query the updated USB drive content or local content, reducing the query process time.

[0035] In conjunction with the above embodiments, in one implementation, this application also provides a cross-process media file path notification method. In this cross-process media file path notification method, step S01 may include steps S01_1 to S01_4: Step S01_1: During the first transmission of the notification, the notification method in DatabaseHelper that adds a path parameter is called through the callback method in the listener of MediaProvider. The file path information in the callback method is passed by the path parameter added by the notification method.

[0036] In this embodiment, during the first notification transmission process, the various methods involved in notification transmission include the `notifyChange` method in the `DatabaseHelper` class. Therefore, this application modifies the `notifyChange` method in the `DatabaseHelper` class by adding a path parameter. The original definition of the `notifyChange` method in the `DatabaseHelper` class was `notifyChange(@NonNull Uriuri, int flags)`. This application adds a path parameter (i.e., a `String path` parameter, used to transmit the file path information corresponding to the notification). The modified definition of the `notifyChange` method in the `DatabaseHelper` class is now `notifyChange(@NonNull Uri uri, String path, int flags)`.

[0037] In this embodiment, the three notification methods (notifyInsert, notifyDelete, and notifyUpdate) in DatabaseHelper directly call the notifyChange method in the DatabaseHelper class. Therefore, in the first notification transmission process, the various methods involved in notification transmission also include the three notification methods in DatabaseHelper. Accordingly, this application adds a path parameter (i.e., a String path parameter, used to pass the file path information corresponding to the notification) to each of these three notification methods. The modified definitions of the three notification methods are as follows: notifyInsert(@NonNull Uri uri, String path); notifyDelete(@NonNull Uri uri, String path); notifyUpdate(@NonNull Uri uri, String path).

[0038] In this embodiment, the MediaProvider contains an OnFilesChangeListener file listener. When a file is added, modified, or deleted, the onInsert, onUpdate, and onDelete callback methods in the listener are triggered respectively. These three notification methods are executed within their respective callback methods. The notifyInsert notification method is called within the onInsert callback method; the notifyUpdate notification method is called within the onUpdate callback method; and the notifyDelete notification method is called within the onDelete callback method. During the first notification transmission process, the corresponding callback method in the DatabaseHelper that adds the path parameter is called through the corresponding callback method within the MediaProvider's listener (which carries the file path information corresponding to the notification). The file path information from the corresponding callback method is then passed through the path parameter added in the corresponding notification method. Specifically, when the callback method is onInsert, it calls the notifyInsert notification method in DatabaseHelper that adds a path parameter; when the callback method is onUpdate, it calls the notifyUpdate notification method in DatabaseHelper that adds a path parameter; and when the callback method is onDelete, it calls the notifyDelete notification method in DatabaseHelper that adds a path parameter.

[0039] Step S01_2: Call the notifyChange method of DatabaseHelper with the newly added path parameter through the notification method, and pass the file path information in the notification method through the newly added path parameter of the notifyChange method.

[0040] In this embodiment, after the corresponding notification method is called by the corresponding callback method in step S01_1 to pass the file path information corresponding to the notification method, the corresponding notification method calls the notifyChange method of the DatabaseHelper which adds a new path parameter. The new path parameter added in the notifyChange method of the DatabaseHelper passes the file path information in the corresponding notification method.

[0041] Step S01_3: Call the notifySingleChangeInternal method with the newly added path parameter through the notifyChange method of the DatabaseHelper. The file path information in the notifyChange method of the DatabaseHelper is passed by the newly added path parameter in the notifySingleChangeInternal method.

[0042] In this embodiment, during the first notification transmission process, the various methods involved in notification transmission also include the `notifySingleChangeInternal` method. Since the `notifyChange` method of `DatabaseHelper` calls the `notifySingleChangeInternal` method, to ensure that file path information can be transmitted to the system's `ContentService`, a path parameter is first added to the `notifySingleChangeInternal` method. The original definition of the `notifySingleChangeInternal` method was `notifySingleChangeInternal(uri, flags)`, and its modified definition is `notifySingleChangeInternal(uri, path, flags)`. Secondly, extended data is encapsulated in the `notifySingleChangeInternal` method. Specifically, a new `Bundle` object is created (used to store additional information). This new `Bundle` object stores the key data—the file path information corresponding to the notification—using the "file_path" key to store the file path information corresponding to the notification (i.e., the `path` parameter added in the `notifySingleChangeInternal` method).

[0043] Step S01_4: Receive and record the file path information through the newly added Bundle object in the notifySingleChangeInternal method.

[0044] In this embodiment, after the notifySingleChangeInternal method receives the file path information corresponding to the notification through the newly added path parameter, it receives and records the file path information through the Bundle object newly added in the notifySingleChangeInternal method for subsequent notification transmission.

[0045] In conjunction with the above embodiments, in one implementation, this application also provides a cross-process media file path notification method. In this cross-process media file path notification method, when the callback method is an onInsert callback method, the method further includes: connecting to a database object by calling the getReadableDatabase method through DatabaseHelper in the onInsert callback method; and querying the file path information stored in the database object using the query method to obtain the file path information in the onInsert callback method.

[0046] In this embodiment, since the onUpdate and onDelete callback methods already include the path (file path) in their parameters, the callback methods can directly pass the existing path to the corresponding notification methods when they call the corresponding notifyUpdate and notifyDelete notification methods. However, the onInsert callback method does not include the path (file path) in its parameters. Therefore, to ensure that the path can be passed to the notifyInsert notification method when the onInsert callback method calls it, this application provides an optional implementation method as follows: The database object is connected by calling the getReadableDatabase method through DatabaseHelper in the onInsert callback method, and then the corresponding file path information (the field storing the path in the database) is queried from the database object using the query method.

[0047] In conjunction with the above embodiments, in one implementation, this application also provides a cross-process media file path notification method. In this cross-process media file path notification method, step S02 may include steps S02_1 to S02_3: Step S02_1: The notifySingleChangeInternal method obtains the ContentResolver instance through the system context object mContext in DatabaseHelper.

[0048] In this embodiment, the notification containing file path information is passed from the notifySingleChangeInternal method to the system's ContentService using ContentResolver. Since ContentResolver is a component in the Android system source code, this application modifies the system source code to complete the parameter passing. The specific modifications are as follows: First, the notifyChange method in ContentResolver, used for sending notifications, is modified by adding additional parameters of a Bundle object (i.e., Bundle extras, used to carry extended data passed by the Bundle object added by the notifySingleChangeInternal method). The modified definition of the notifyChange method for sending notifications is notifyChange(@NonNull Uri uri, Bundleextras, @Nullable ContentObserver observer). Because this method calls other notifyChange overloaded methods inside ContentResolver level by level (which will eventually call the method that handles multiple URIs), this application will also add boolean object parameters to these overloaded methods, down to the lowest level implementation method. The modified definition of this method is notifyChange(@NonNull Uri[]uris, Bundle extras,ContentObserver observer, @NotifyFlags int flags, @UserIdInt int userHandle).

[0049] In this embodiment, since the notifyChange method of ContentResolver ultimately calls the notifyChange method of the system service ContentService, this application will also add additional parameters (i.e., Bundle extras) of the Bundle object to the notifyChange method of ContentService. The modified notifyChange method in ContentService is defined as notifyChange(Uri[] uris, Bundle extras, IContentObserver observer, boolean observerWantsSelfNotifications, int flags, int userId, int targetSdkVersion, String callingPackage).

[0050] In this embodiment, the notifySingleChangeInternal method first obtains the ContentResolver instance using the system context object mContext in DatabaseHelper.

[0051] Step S02_2: Based on the obtained ContentResolver instance, call the notifyChange method of the ContentResolver instance with the added additional parameters. The added additional parameters in the notifyChange method carry the file path information stored in the newly added Bundle object.

[0052] In this embodiment, based on the obtained ContentResolver instance, the notifyChange method with the added additional parameters in the ContentResolver instance is called. The additional parameters added in the notifyChange method carry the file path information stored in the Bundle object added in the notifySingleChangeInternal method.

[0053] Step S02_3: Call the notifyChange method of ContentService with the added additional parameter through the notifyChange method of the ContentResolver instance to send a notification containing file path information to ContentService. The file path information in the notifyChange method of the ContentResolver instance is passed by the added additional parameter in the notifyChange method of ContentService.

[0054] In this embodiment, since the `notifyChange` method of the `ContentResolver` instance calls the `notifyChange` method of the `ContentService` during the notification transmission process, this application also adds additional parameters to the `notifyChange` method of the `ContentService`. Then, the `notifyChange` method of the `ContentResolver` instance calls the `notifyChange` method of the `ContentService` with the added additional parameters. This allows the `notifyChange` method of the `ContentResolver` instance to send a notification containing file path information to the `ContentService`, and the `notifyChange` method of the `ContentService` receives and transmits the file path information from the `notifyChange` method of the `ContentResolver` instance using the added additional parameters.

[0055] In conjunction with the above embodiments, in one implementation, this application also provides a cross-process media file path notification method. In this cross-process media file path notification method, step S03 may include: Step S03_1: The notifyChange method of ContentService calls the collectObserversLocked method of ObserverNode to collect all ContentObservers that have received the notification.

[0056] In this embodiment, during the second notification transmission process, the various methods involved in notification transmission include the `notifyChange` method of `ContentService`. This application adds an additional parameter to the `notifyChange` method of `ContentService` to transmit the file path information corresponding to the notification. Additionally, `ContentService` has an inner class `ObserverCollector`, which has a member variable `collected` (of type `ArrayMap`). <Key, List <uri>The Key class of the collected collection is used to store observers and associated data. In order to save extended data along with the Key, this application adds an additional variable of Bundle object (i.e., Bundle extras variable, which is used to store file path information) to the Key class.

[0057] In this embodiment, the notifyChange method, which adds additional parameters in ContentService, first calls the collectObserversLocked method of ObserverNode. The collectObserversLocked method collects all ContentObservers that need to receive notifications. This application allows the additional parameters to be passed all the way to this method.

[0058] Step S03_2: Call the collectMyObserversLocked method through the collectObserversLocked method to trigger the collect method of ObserverCollector.

[0059] In this embodiment, the collectObserversLocked method will further call the collectMyObserversLocked method, which will eventually trigger the collect method of ObserverCollector.

[0060] Step S03_3: Establish the mapping relationship between the notification and the corresponding ContentObserver through the collect method and store it in the collected collection. Also, store the file path information carried by the additional parameter added in the notifyChange method of the ContentService into the additional variable added in the Key class of the collected collection.

[0061] In this embodiment, the `collect` method stores the "data + observer" mapping into the `collected` collection. The `collect` method stores the externally passed extras content (i.e., at least including file path information). Specifically, the `collect` method establishes a mapping relationship between the notification and the corresponding ContentObserver and stores it in the `collected` collection. Furthermore, the file path information carried by the additional parameter added in the `notifyChange` method of `ContentService` is stored in the additional variable added to the `Key` class of the `collected` collection.

[0062] The code for the `collect` function is as follows: public void collect(IContentObserver observer, int uid, booleanselfChange, Bundle extras, Uri uri, int flags, int userId) { final Key key = new Key(observer, extras,uid, selfChange, flags,userId); List <uri>value = collected.get(key); if (value == null) { value = new ArrayList<>(); `collected.put(key, value);` / / Stores the data in the `collected` collection. } … } In conjunction with the above embodiments, in one implementation, this application also provides a cross-process media file path notification method. In this cross-process media file path notification method, step S04 may include steps S04_1 to S04_3: Step S04_1: In the notifyChange method of the contentservice, execute the dispatch method of ObserverCollecter to obtain the notification containing the file path information stored in the key class of the collected collection.

[0063] In this embodiment, after the ObserverCollector's collect method is triggered and the corresponding processing is completed, the ObserverCollecter's dispatch method is executed in the contentservice's notifyChange method. This method retrieves the stored data, that is, it obtains the notification data containing file path information stored in the key class of the collected collection.

[0064] Step S04_2: Call the onChangeEtc method of ContentObserver through the dispatch method to send a notification containing the file path information to the corresponding ContentObserver.

[0065] In this embodiment, after the `dispatch` method obtains the data, it calls the `onChangeEtc` method of `ContentObserver` to send a notification containing file path information to the corresponding `ContentObserver` in the system. Thus, when the notification is dispatched to the `ContentObserver`, the observer can retrieve the previously passed extended data through the `extras` field in the `Key`. Partial code is as follows: private static class Key { final IContentObserver observer; … final Bundle extras; } Step S04_3: The dispatchChange method is called through the onChangeEtc method of the ContentObserver, and the dispatchChange method calls the onChange method, so that the registrant of the ContentObserver can obtain a notification containing the file path information through the onChange method.

[0066] In this embodiment, after the `onChangeEtc` method of `ContentObserver` receives the notification containing the file path information, it calls the `dispatchChange` method, which then passes the notification to the `onChange` method. The `onChange` method is the callback method that the application (e.g., the gallery) uses after defining its own `GalleryContentObserver` class, implementing and registering `ContentObserver`, receives a change in the system's media file. The gallery application can obtain the changed file path information within the `onChange` method.

[0067] In conjunction with the above embodiments, in one implementation, this application also provides a cross-process media file path notification method. In this cross-process media file path notification method, when the Bundle object includes a first key-value pair recording file path information and a second key-value pair recording storage type, the method further includes: identifying the storage type of the media file based on the file path information using a newly added isUsbStorage(filePath) method, and recording it in the second key-value pair of the Bundle object; the storage type includes internal storage or external device storage; each method, when passing the file path information through its newly added additional parameters, also passes the storage type through its newly added additional parameters; and a newly added additional variable in the Key class simultaneously receives and records the file path information and the storage type, so that the registrant of the ContentObserver receives a notification containing the file path information and the storage type through the Key class.

[0068] In this embodiment, in another optional implementation, the present application can also transmit extended data such as the storage type of the media file while transmitting the extended data of the file path information of the notification. Specifically, the Bundle object added in the notifySingleChangeInternal method is used to store two key data: a first key-value pair storing the file path information corresponding to the notification using the "file_path" key; and a Boolean value (i.e., a second key-value pair) storing the storage type using the "is_usb" key, which indicates whether the media file corresponding to the notification is a USB flash drive file.

[0069] In this embodiment, when the Bundle object added in the notifySingleChangeInternal method is used to store two key data points, this application will add an isUsbStorage(filePath) method. This isUsbStorage(filePath) method identifies the storage type of the media file corresponding to the notification (i.e., whether it's a file on an external USB drive or a file in internal storage) based on the passed file path information. The isUsbStorage(filePath) method identifies the storage type based on features such as the prefix of the file path information. Using the system context object mContext in DatabaseHelper, a ContentResolver instance is obtained, and then the notifyChange method with added parameters in the ContentResolver instance is called, passing in the URI, the Bundle object containing the file path information and storage type, and flags. This ensures that the complete information is passed to the system's ContentService, guaranteeing that the storage type information is transmitted to the system's ContentService. The code snippet is as follows: / / Create a Bundle to carry extended data Bundle extras = new Bundle(); extras.putString("file_path", path); / / File path extras.putBoolean("is_usb", isUsbStorage(filePath)); / / Mark whether it is a file on a USB drive mContext.getContentResolver().notifyChange(uri, extras, null, flag); / / Send the notification to the system's Content Resolver In this embodiment, when the Bundle object added in the notifySingleChangeInternal method is used to store the first key-value pair of file path information and the second key-value pair of storage type, in order to also pass the extended data of media file storage type during the notification transmission process, for each method with added additional parameters, the added additional parameters are used not only to record the transmitted file path information, but also to record the storage type of the media file corresponding to the transmitted notification. Simultaneously, the added additional variable in the Key class not only receives and records the file path information, but also receives and records the storage type of the transmitted media file, so that the registrant of the final registered ContentObserver can obtain the notification containing the file path information and media file storage type through the Key class. Finally, the gallery application can obtain the changed media file storage type and file path information in the onChange method. Depending on whether the changed content is USB drive data or local data, corresponding page data queries and UI updates are performed. If the USB drive file changes, the media data stored on the USB drive is queried and the corresponding UI area is updated; if the local file changes, the local display content is refreshed. In this way, the gallery can accurately update the interface according to different storage sources, thereby reducing the time spent in the query process.

[0070] In conjunction with the above embodiments, in one implementation, this application also provides a cross-process media file path notification method. In this cross-process media file path notification method, step S02_3 may include steps S02_3a to S02_3c: Step S02_3a: When the application calls the notifyChange method with added parameters in ContentService through the notifyChange method of the ContentResolver instance, the application's package name is obtained from the application's callingUid through the newly added getPackageNameForUid(callingUid) method in ContentService, and the package name is converted to obtain the corresponding signature hash.

[0071] In this embodiment, to enhance the security of cross-process notifications, this application implements a validation of the sender's (the application calling the notifyChange method) legitimacy in the notifyChange method of ContentService to prevent malicious applications from spoofing information. The sending application is the one calling the notifyChange method of ContentResolver, and this application verifies the legitimacy of the sender application's package name. Verification logic is added to the notifyChange method of ContentService: first, the application package name is obtained through the sending application's callingUid; then, the obtained package name is compared with the list of trusted applications maintained in the system. If no match is found, the subsequent logic is not executed. Figure 3 As shown, firstly, a new `getPackageNameForUid(callingUid)` method is added to `ContentService` to obtain the application package name by Uid. This `getPackageNameForUid(callingUid)` method is used to obtain the application's package name from its `callingUid` when the application (i.e., the sender) calls the `notifyChange` method with added additional parameters in `ContentService` through the `notifyChange` method of the `ContentResolver` instance, and then converts the package name to obtain the signature hash corresponding to the application.

[0072] Step S02_3b: The obtained package name and signature hash are matched with the authorized sender's package name and signature hash in the first map set of the newly added loadTrustedApps method in ContentService using the validateSender(realSenderPackage) method in the notifyChange method of ContentService.

[0073] In this embodiment, the application further adds a `validateSender(realSenderPackage)` method to the `notifyChange` method of `ContentService` to verify the package name and signature hash of the sending application. Simultaneously, a `loadTrustedApps` method is added to `ContentService`, maintaining a first map set within it. This first map set records the package names and signature hashes of authorized senders. The `validateSender(realSenderPackage)` method matches the package name and signature hash of the sending application obtained by the `getPackageNameForUid(callingUid)` method with the package names and signature hashes of each authorized sender in the first map set within the `loadTrustedApps` method. Only when the package name of the sending application matches the package name of an authorized sender in the first map set, and the signature hash of the sending application matches the signature hash of that authorized sender in the first map set, is it determined that the sending application has successfully matched the authorized sender in the first map set. A successful match indicates that the sending application is a legitimate authorized sender.

[0074] Step S02_3c: If the package name and the signature hash successfully match the package name and signature hash of the authorized sender in the first map set, the application is allowed to call the notifyChange method of the ContentService with the added additional parameters through the notifyChange method of the ContentResolver instance.

[0075] In this embodiment, if the packet name and signature hash of the obtained sending application can be successfully matched with the packet name and signature hash of an authorized sender in the first map set, it is determined that the sending application is a legitimate authorized sender. At this time, the sending application is allowed to call the notifyChange method with added additional parameters in ContentService through the notifyChange method of the ContentResolver instance to complete the subsequent notification delivery.

[0076] The following is a partial code snippet: / / ====== Added: Retrieve basic information of the sender ====== / / Get the actual packet name of the sender (to avoid forgery of the incoming calling package) String realSenderPackage = getPackageNameForUid(callingUid); if (realSenderPackage == null) { Slog.e(TAG, "Invalid sender UID: " + callingUid); return; / / Invalid sender, return immediately. } / / ====== Added: Sender verification (pre-authorization + signature verification) ====== if (!validateSender(realSenderPackage)) { Slog.e(TAG, "Sender not authorized: " + realSenderPackage); return; / / The sender has not authorized the notification, so the notification is terminated. } / / Sender verification: Check if it is in the pre-authorization list and if the signature matches private boolean validateSender(String senderPackage) { / / 1. Check if it is in the pre-authorized sender list if (!mTrustedSenders.containsKey(senderPackage)) { return false; } / / 2. Verify signature hash match String actualHash = getAppSignatureHash(senderPackage); String expectedHash = mTrustedSenders.get(senderPackage); return expectedHash.equals(actualHash); } In conjunction with the above embodiments, in one implementation, this application also provides a cross-process media file path notification method. In this cross-process media file path notification method, after step S03_3, the method further includes steps S03_3_a to S03_3_c: Step S03_3_a: Filter the data entries corresponding to the ContentObserver of the invalid receiver in the collected collection using the newly added filterUnauthorizedReceivers method in ContentService.

[0077] In this embodiment, to enhance the security of cross-process notifications, this application implements a validation of the recipient's (the application that registered the ContentObserver) legitimacy in the `notifyChange` method of `ContentService` to prevent malicious applications from impersonating and stealing information. Specifically, as follows... Figure 4 As shown, first, a filterUnauthorizedReceivers method is added to ContentService. This filterUnauthorizedReceivers method filters out the data entries corresponding to the invalid recipients in the collected collection of all the recipients' ContentObservers.

[0078] The following is a partial code snippet: / ** * Filter out unauthorized receivers in the ObserverCollector (based on UID verification of package name and signature). / private void filterUnauthorizedReceivers(ObserverCollector collector){ / / Create a new ArrayMap to store the filtered results ArrayMap <ObserverCollector.Key, List <uri>>filteredCollected = newArrayMap<>(); / / Iterate through all collected observer keys for (int i = 0; i <collector.collected.size(); i++) { ObserverCollector.Key key = collector.collected.keyAt(i); List <uri>uris = collector.collected.valueAt(i); / / 1. Obtain the recipient's packet name using the uid in the Key String receiverPackage = getPackageNameForUid(key.uid); if (receiverPackage == null) { Slog.w(TAG, "Invalid recipient UID: " + key.uid + ", skip notification"); continue? } / / 2. Verify recipient authorization by package name (pre-authorization list + signature matching) if (validateReceiver(receiverPackage)) { / / Verification passed, retain the key and the corresponding list of URIs. filteredCollected.put(key, uris); } else { Slog.w(TAG, "Receiver unauthorized: " + receiverPackage + " (UID: " + key.uid +"), notification denied"); } } / / Replace with the filtered result (clear the original collected and add the filtered content). collector.collected.clear(); collector.collected.putAll(filteredCollected); } Step S03_3_b: Based on the package name and signature hash of the authorized recipient in the second map set within the newly added loadTrustedApps method in ContentService, the package name and signature hash of the recipient in the collected set after filtering invalid recipients are matched with the package name and signature hash of the authorized recipient in the second map set within the newly added loadTrustedApps method in ContentService using the newly added validateReceiver method in ContentService.

[0079] In this embodiment, the application adds a validateReceiver method to ContentService, and also maintains a second map collection in the loadTrustedApps method added to ContentService. The second map collection records the package name and signature hash of the authorized receiver.

[0080] The `validateReceiver` method matches the package names and signature hashes of the remaining recipients in the `collected` set after processing in step S03_3_a with the package names and signature hashes of the authorized recipients in the second `map` set within the `loadTrustedApps` method. Only when a recipient's package name matches the package name of an authorized recipient in the second `map` set, and the recipient's signature hash matches the signature hash of that authorized recipient in the second `map` set, is the recipient considered a successful match. A successful match indicates that the recipient in the `collected` set after filtering invalid recipients is a legitimate authorized recipient.

[0081] Part of the code is as follows: / / Receiver verification: Check if the package name is in the pre-authorization list and if the signature matches. private boolean validateReceiver(String receiverPackage) { / / 1. Check if it is in the pre-authorized recipient list if (!mTrustedReceivers.containsKey(receiverPackage)) { Slog.d(TAG, "The receiver is not in the preauthorization list: " + receiverPackage); return false; } / / 2. Verify signature hash matching (to prevent application tampering) String actualSignatureHash = getAppSignatureHash(receiverPackage); String expectedSignatureHash = mTrustedReceivers.get(receiverPackage); if (!expectedSignatureHash.equals(actualSignatureHash)) { Slog.d(TAG, "Receiver signature mismatch: " + receiverPackage + " (actual: " + actualSignatureHash + ", expected: " + expectedSignatureHash + ")"); return false; } return true; } In this embodiment, the getAppSignatureHash method in the code snippet obtains the signature hash based on the package name. Since it is a utility method, the specific implementation logic will not be explained in detail here.

[0082] Step S03_3_c: Based on the matching results, filter the data entries corresponding to the ContentObserver of the unauthorized receiver in the collected collection after filtering the invalid receivers to obtain the final collected collection.

[0083] In this embodiment, if the obtained receiver's package name and signature hash match simultaneously with the package name and signature hash of an authorized receiver in the second map set, the receiver is determined to be a legitimate authorized receiver, and the data entry corresponding to the ContentObserver of that receiver is retained in the collected set. If no authorized receiver in the second map set matches simultaneously with the obtained receiver's package name and signature hash, that receiver is filtered out from the invalid receivers in the collected set, thus obtaining the final collected set, which contains only authorized receivers. Subsequent notification distribution begins after receiver verification is completed.

[0084] Combined with the above embodiments, in one implementation manner, the embodiments of the present application further provide a cross-process media file path notification method. In this cross-process media file path notification method, a system configuration file is constructed in the system to manage and maintain a trusted application list, and the package names and signature hashes of authorized senders and receivers are stored in the trusted application list; when authenticating the receiver and the sender, the cached system configuration file is loaded into the memory in ContentService; in the constructor method of ContentService, the newly added loadTrustedApps method in ContentService is executed to parse the information in the system configuration file, and the package names and signature hashes of the sender and the receiver obtained by parsing are stored in the corresponding first map set and second map set in the loadTrustedApps method.

[0085] In this embodiment, when the newly added loadTrustedApps method in ContentService in the cross-process media file path notification method provided by the present application maintains the first map set and / or the second map set to perform legality verification on the sender and / or the receiver, an optional maintenance method is as follows: maintain a trusted application list in the system, store the package names and signature hashes of the authorized sender, and / or, the package names and signature hashes of the receiver, which can be managed through a system configuration file (such as / system / etc / trusted_apps.xml).

[0086] The content of the configuration file is as follows: <trusted_apps> <!-- Authorized sender: such as MediaProvider application --> <sender package="com.android.providers.media" signature_hash="签名哈希值" / > <!-- Authorized receiver: such as Gallery application --> <receiver package="com.android.gallery3d" signature_hash="签名哈希值" / > < / trusted_apps> In this embodiment, when authenticating the receiver and / or the sender, the cached system configuration file is loaded into memory in the ContentService. A loadTrustedApps method is added, which is executed within the constructor of ContentService. During the authentication of the receiver and sender, the loadTrustedApps method defines two map collections: a first map collection stores the sender's package name and signature hash, and a second map collection stores the receiver's package name and signature hash. The content of the system configuration file loaded into memory is parsed and then stored in the two map collections of the loadTrustedApps method.

[0087] / / Load pre-authorization information private void loadTrustedApps() { / / Parse the XML file and store it in a Map (package name -> signature hash) mTrustedSenders = new HashMap<>(); mTrustedReceivers = new HashMap<>(); / / Refers to parsing XML data loadXml() / / Storing data mTrustedSenders.put("com.android.providers.media", "hash value"); mTrustedReceivers.put("com.android.gallery3d", "hash value"); } In this embodiment, the entire process of the cross-process media file path notification method provided in this application is as follows: Figure 5 As shown, the core improvement of this application is reflected in the dotted line section of the diagram, including: when updating a notification, the `notifyChange` method in `ContentResolver`, which adds an additional parameter, carries the file path information and storage type identifier corresponding to the notification (e.g., whether the notification corresponds to a media file in a USB flash drive or internal storage). After `ContentService` receives the notification, it initiates corresponding security verification. First, it verifies the sender's identity. If the sender's identity fails verification, an exception log is recorded, and the current notification is not sent to the recipient. When the sender's identity is verified, `ObserverCollector` collects observers, which correspond to the recipients. Therefore, after `ObserverCollector` collects observers, it further verifies the recipient's identity, filtering out unauthorized recipients. For the remaining recipients, `ObserverCollector` distributes notifications to their `ContentObserver`s, and the recipients finally update the UI based on the received notifications.

[0088] The cross-process media file path notification method provided in this application is developed through secondary development of the ContentService, ContentResolver, and ContentObserver classes in the Android media database Media Provider and the system framework source code. Through designs such as "two-way security verification" and "fine-grained path management," it brings practical value from multiple dimensions including system security, privacy protection, and user experience. Specific benefits are as follows: Enhance the security of cross-process notifications and defend against malicious attacks: Perform dual verification of package name + signature hash, and only allow pre-authorized legitimate applications to participate in the notification process to prevent malicious applications from impersonating the sender / receiver.

[0089] Protecting user privacy with precise recipient filtering: Notifications containing paths are only distributed to trusted recipients such as photo libraries. Unauthorized applications (such as malicious utility apps) are directly filtered out, preventing path information from being leaked at the source.

[0090] The notifications are precise and efficient, improving functional reliability and optimizing performance: by distinguishing between local and USB flash drive files based on identifiers such as whether they are USB flash drive files, the recipient (as shown in the image library) can display and update the UI based on the identifiers, avoiding full data queries and refreshes, and improving user experience and application performance. It should be noted that, for the sake of simplicity, the method embodiments are all described as a series of actions. However, those skilled in the art should understand that the embodiments of this application are not limited to the described order of actions, because according to the embodiments of this application, some steps can be performed in other orders or simultaneously. Secondly, those skilled in the art should also understand that the embodiments described in the specification are all preferred embodiments, and the actions involved are not necessarily necessary for the embodiments of this application. As for the system embodiments, since they are basically similar to the method embodiments, the description is relatively simple; relevant details can be found in the descriptions of the method embodiments.

[0091] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. The same or similar parts between the various embodiments can be referred to each other.

[0092] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, embodiments of this application can take the form of entirely hardware embodiments, entirely software embodiments, or embodiments combining software and hardware aspects. Furthermore, embodiments of this application can take the form of computer program products implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0093] This application describes embodiments with reference to flowchart illustrations and / or block diagrams of methods, terminal devices (systems), and computer program products according to embodiments of this application. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing terminal device to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing terminal device, generate instructions for implementing the flowchart illustrations. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0094] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing terminal device to operate in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0095] These computer program instructions can also be loaded onto a computer or other programmable data processing terminal equipment, causing a series of operational steps to be performed on the computer or other programmable terminal equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable terminal equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0096] Although preferred embodiments of the present application have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of the embodiments of the present application.

[0097] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or terminal device that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or terminal device. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or terminal device that includes said element.

[0098] The present application provides a detailed description of a cross-process media file path notification method. Specific examples have been used to illustrate the principles and implementation methods of the present application. The descriptions of the above embodiments are only for the purpose of helping to understand the method and core ideas of the present application. At the same time, those skilled in the art will recognize that there will be changes in the specific implementation methods and application scope based on the ideas of the present application. Therefore, the content of this specification should not be construed as a limitation of the present application.< / uri> < / uri> < / uri> < / uri> < / uri>

Claims

1. A cross-process media file path notification method, characterized in that, The method includes: During the first transmission of the notification, the file path information is transmitted through the path parameters added by various methods in the first transmission process, and the file path information is received and recorded by the Bundle object added in the notifySingleChangeInternal method. The first transmission process is the process of the notification being transmitted to the notifySingleChangeInternal method. The notifySingleChangeInternal method calls the notifyChange method of the ContentResolver instance with the added additional parameter, and sends a notification containing the file path information to the ContentService. The file path information stored in the newly added Bundle object is carried by the additional parameter added in the notifyChange method. During the second transmission of the notification, the file path information is carried by the additional parameters added by various methods in the second transmission process, and the file path information is received and recorded by the additional variable added in the Key class of ContentService. The second transmission process is the process of transmitting the notification to the Key class of ContentService after receiving the notification. Based on the Key class, a notification containing the file path information is distributed to the corresponding ContentObserver, so that the registrant of the ContentObserver can obtain the notification containing the file path information through the Key class.

2. The cross-process media file path notification method according to claim 1, characterized in that, During the first transmission of the notification, file path information is transmitted through path parameters added to various methods in the first transmission process, and the file path information is received and recorded through a Bundle object added in the notifySingleChangeInternal method, including: During the first transmission of the notification, the notification method in DatabaseHelper with the newly added path parameter is called through the callback method in the listener of MediaProvider. The file path information in the callback method is passed by the newly added path parameter in the notification method. The notification method calls the notifyChange method in DatabaseHelper to add a new path parameter, and the file path information in the notification method is passed by the new path parameter added by the notifyChange method. The notifyChange method of the DatabaseHelper calls the notifySingleChangeInternal method with the added path parameter, and the file path information in the notifyChange method of the DatabaseHelper is passed by the added path parameter in the notifySingleChangeInternal method. The file path information is received and recorded through the Bundle object added in the notifySingleChangeInternal method.

3. The cross-process media file path notification method according to claim 2, characterized in that, If the callback method is an onInsert callback method, the method further includes: Connect to the database object by calling the getReadableDatabase method through DatabaseHelper in the onInsert callback method; The file path information stored in the database object is retrieved using the query method to obtain the file path information in the onInsert callback method.

4. The cross-process media file path notification method according to claim 1, characterized in that, By calling the `notifyChange` method of the `ContentResolver` instance with the added additional parameters through the `notifySingleChangeInternal` method, a notification containing the file path information is sent to the `ContentService`, including: The notifySingleChangeInternal method obtains the ContentResolver instance through the system context object mContext in DatabaseHelper; Based on the obtained ContentResolver instance, the notifyChange method with the added additional parameter in the ContentResolver instance is called, and the file path information stored in the newly added Bundle object is carried by the added additional parameter in the notifyChange method; The notifyChange method of the ContentResolver instance is called by adding an additional parameter to the notifyChange method of the ContentService to send a notification containing file path information to the ContentService. The file path information in the notifyChange method of the ContentResolver instance is passed by the additional parameter added to the notifyChange method of the ContentService.

5. The cross-process media file path notification method according to claim 1, characterized in that, During the second transmission of the notification, the file path information is carried through additional parameters added to various methods in the second transmission process, and is received and recorded through additional variables added to the Key class of ContentService, including: The notifyChange method of ContentService calls the collectObserversLocked method of ObserverNode to collect all ContentObservers that have received notifications. The `collectMyObserversLocked` method is called through the `collectObserversLocked` method to trigger the `collect` method of `ObserverCollector`; The `collect` method establishes a mapping relationship between the notification and the corresponding `ContentObserver` and stores it in the `collected` collection. The file path information carried by the additional parameter added in the `notifyChange` method of the `ContentService` is stored in the additional variable added to the `Key` class of the `collected` collection.

6. The cross-process media file path notification method according to claim 1, characterized in that, Based on the Key class, a notification containing the file path information is distributed to the corresponding ContentObserver, so that the registrants of the ContentObserver can obtain the notification containing the file path information through the Key class, including: In the notifyChange method of the contentservice, the dispatch method of ObserverCollecter is executed to obtain the notification containing the file path information stored in the key class of the collected collection; The `dispatch` method calls the `onChangeEtc` method of `ContentObserver` to send a notification containing the file path information to the corresponding `ContentObserver`. The onChangeEtc method of the ContentObserver calls the dispatchChange method, and the dispatchChange method calls the onChange method, so that the registrant of the ContentObserver can receive a notification containing the file path information through the onChange method.

7. The cross-process media file path notification method according to claim 1, characterized in that, When the Bundle object includes a first key-value pair recording file path information and a second key-value pair recording storage type, the method further includes: The newly added isUsbStorage(filePath) method identifies the storage type of the media file based on the file path information and records it in the second key-value pair of the Bundle object. The storage type includes internal storage or external device storage. When each method passes the file path information through its newly added additional parameters, it also passes the storage type through its newly added additional parameters. In addition, the newly added additional variable in the Key class simultaneously receives and records the file path information and the storage type, so that the registrant of the ContentObserver can obtain a notification containing the file path information and the storage type through the Key class.

8. The cross-process media file path notification method according to claim 4, characterized in that, The `notifyChange` method of the `ContentService` is invoked by calling the `notifyChange` method of the `ContentResolver` instance to add additional parameters, including: When an application calls the notifyChange method with added parameters in ContentService through the notifyChange method of the ContentResolver instance, the application's package name is obtained from the application's callingUid through the newly added getPackageNameForUid(callingUid) method in ContentService, and the package name is converted to obtain the corresponding signature hash. The validateSender(realSenderPackage) method, newly added to the notifyChange method of ContentService, matches the obtained package name and signature hash with the authorized sender's package name and signature hash in the first map set within the loadTrustedApps method, newly added to ContentService; If the package name and the signature hash successfully match the package name and signature hash of the authorized sender in the first map set, the application is allowed to call the notifyChange method in ContentService with the added additional parameters through the notifyChange method of the ContentResolver instance.

9. The cross-process media file path notification method according to claim 4, characterized in that, After establishing the mapping relationship between the notification and the corresponding ContentObserver through the `collect` method and storing it in the `collected` collection, and storing the file path information carried by the additional parameter added in the `notifyChange` method of the ContentService into the additional variable added in the Key class of the `collected` collection, the method further includes: The filterUnauthorizedReceivers method, newly added in ContentService, filters the data entries corresponding to the ContentObserver of the invalid receiver in the collected collection; Based on the authorized recipient's package name and signature hash in the second map set within the newly added loadTrustedApps method of ContentService, the newly added validateReceiver method in ContentService matches the recipient's package name and signature hash in the collected set after filtering invalid recipients with the authorized recipient's package name and signature hash in the second map set within the newly added loadTrustedApps method of ContentService. Based on the matching results, the data entries corresponding to the ContentObserver of the unauthorized receivers in the collected collection after filtering the invalid receivers are filtered to obtain the final collected collection.

10. The cross-process media file path notification method according to claim 9, characterized in that, The system builds a system configuration file to manage and maintain a list of trusted applications, which stores the packet names and signature hashes of authorized senders and receivers. When authenticating the receiver and sender, the cached system configuration file is loaded into memory in ContentService; Within the constructor of ContentService, the newly added loadTrustedApps method in ContentService is executed to parse the information in the system configuration file and store the parsed packet name and signature hash of the sender and receiver into the corresponding first map set and second map set within the loadTrustedApps method.

Images