You can find explanations of various terms related to storage in Android Developer Documentation.

New users can apply the template to all third-party apps in need first(or use the rules shared by other users). The default template will redirect the app's access to the shared storage to its external cache. If some of the apps you use save valuable data in the shared storage (for instance, the map app may save offline maps, and the translation app may save offline dictionaries), you need to open the settings of the corresponding app and check "the app saves valuable data in shared storage" option, as shown in the figure below. Later, you need either to manually migrate the files saved by these apps or re-download them in these apps, which cannot be done automatically by Material Cleaner.

In this way, the initial configuration is complete.

After the initial configuration, you'll find that none of the apps can use the shared storage, which doesn't look right. So the question is, under what circumstances does an app need to use shared storage?

This question can be considered in two parts. First, which files should be stored in the shared storage? According to Android Developer Documentation, the shared storage stores media content and documents that users know and are easy to share. The offline map and offline dictionary files mentioned in the initial configuration can usually only be opened by the app that saves these files, so these files should be saved in the app-specific storage of the corresponding app instead of the shared storage. For files that users need, you can write "Change the file hierarchy seen by the app" rules to specify where the app saves those files.

The second part is: which files in the shared storage do the apps need? For primary use cases, the Android system provides the Storage Access Framework and the Media Store API. If an app already adopts these privacy-friendly practices, you don't need to add any rules for it. However, some apps will relinquish using the storage access framework for the sake of a unified user interface or query media files paths via the media store and then open the files using path (the latter is actually an optional correct approach, but addition rules are needed due to technical reasons). In these cases, you need to add "Dirs that can directly access" rules, or these apps will not be able to access the files they need, and you will not be able to use the related functions of the app. Moreover, you can also add "Paths that can't access" rules on this basis to allow an app to access a directory but prohibit access to its sub-paths. If the app is a file manager or something that needs to access all files, it is recommended that you only write "Paths that can't access" rules or use the read-only feature.

The Android system provides the Media Store to facilitate apps to retrieve media files from the device. After you enable Material Cleaner with sufficient capabilities (Install Zygisk module), Material Cleaner can be aware of such behavior and show prompts when storage redirect obstructs apps from interacting with the media store. This allows you to create large numbers of rules in a short time and without interrupting current operations for incorrect mount rules. Integrated with the media store, using storage redirect is as easy as using runtime permissions.