The most distinctive feature of the miui system is the system-level theme skin replacement, which can replace any visible elements. Such as desktop icon, Desktop Folder, desktop wallpaper, various image resources and fonts in the app. If a rom supports this function like miui, how can this function be implemented. From the perspective of function implementation, it can be divided into third parties and only systems can be changed. Here, we mainly provide various services open to the Android system for skin replacement. For example, wallpapers and ringtones can be replaced by system interfaces. Other skin replacement functions of miui are mainly used to replace app resources. This function should be the most distinctive. The following describes the implementation of this function and the problems encountered during the development of the theme management app. It will continue with several blogs.
Theoretically, you can define related interfaces with specific applications to replace resources on the app (the desktop is also an app), so as to achieve targeted resource replacement. For example, many desktops on the market now support their own skin replacement functions. You can change the icon Image Library, icon backplane, and so on. If the skin replacement function is implemented in this way, the skin replacement module defines the related interfaces with each app, puts the corresponding resources in the agreed position, and notifies each app through intent broadcast, reload each app. However, this will inevitably increase the complexity of each app, and the resources of third-party apps cannot be updated.
If you need to replace any app in the Rom, you need to go deep into the Android system to load and use resources to find the answer.
As shown in the figure below, the getresource of the activity we use calls the context virtual base class interface, if you want to have a deep understanding of the specific implementation of context, you can look at contextimpl. This section briefly introduces how the Android system extracts resources. In Android, it loads resources and obtains resources through context. Finally, it calls assetmanager's opennonasset () to load resources. The Android system uses the resource ID to identify different resources. The ID greater than 0x0000000 is the system resource, otherwise it is the app's own resource. Use the package name to determine different resource packages and read resource files.
All resources in the Android system exist in the form of a folder compressed package. This is what the Android app is doing during compilation. We know that in the Android app, all application code is compiled into files in Dex format. For res resources, all resource files are simply compressed to the APK application package Using ZIP files. When the Android phone is installed,
In fact, the process is 1: extract the APK application package. 2. parse the XML file in the folder and register the package information with the system. It mainly includes the name of the startup activity file and the application package name. 3. Copy the APK package to the/data/APP folder and name it. Under/data/APP, the Resource Packages corresponding to each application are actually copies of the APK package. During resource loading, the application package name is used to determine the resource package location. Go to/data/APP to find the corresponding resource package. Extract the corresponding resource file.
Several special resource packages:
1. system resource package, in/system/framework-res
2. the System Application resource package, in fact, is the same as a common application, is used to determine the location of the resource package through the package name, the difference is that the system application is directly compiled into Android during system compilation. the package name specified in MK is copied to the/system/APP. The above mentioned installation and resolution section does not exist. Its resource package is the APK ontology under/system/app. The package name is the name specified in Android. mk during compilation.
The above is a simple description of the process of loading resources in the Android system. Based on this idea, you can choose to load and replace resources.
As this article involves the underlying things, some of which belong to the product-level Core and cannot be detailed, please forgive me. The next few articles will mainly discuss the development of theme management apps and will introduce them in detail.
-- Reprint is welcome. Please indicate the source
Http://blog.csdn.net/zyplus --