Current location - Quotes Website - Signature design - APK device (1) PMS principle analysis
APK device (1) PMS principle analysis
In the overview of apk installation, it is mentioned that there are four installation scenarios of APK, but in either case, it will be submitted to PackageManagerService for processing, but the pretreatment links are different, so this paper first analyzes the main process of PMS. Frameworks/base/services/core/Java/com/Android/server/pm/packagemanagerservice.java is based on Android 9.0.

1. Set some specific system flow information and save it in the settings.

2. Parse the related xml files under /etc/permissions to obtain the information about the related rights and functions of the system.

3. Parse the file /data/system/package.xml to get information about the installed applications.

4.dex optimizes related apk and jar, mainly related jar and apk in /system/framework directory.

5. According to the configuration of sharedUserId, determine which process apk is running in, and then add relevant process information to Settings, so that the system can know which process each apk is running in.

6. Parse the AndroidManifest.xml file and extract the node information in the file.

7. Scan local files, mainly for system applications, locally installed applications and so on.

8. Manage local apk, including installation and deletion.

As mentioned above, the information of APK will be submitted to PMS for a series of installation work. Specifically, a message will be sent through PackageHandler to drive the copy and installation of APK. The timing diagram is as follows:

There are several points to be explained in the process of photography:

1. Create an InstallParams object in the installStage method, and create an INIT_COPY message corresponding to the installation data of the package and send it to the PackageHandler for processing;

2. When processing the INIT_COPY message, the PackageHandler will first judge whether the DefaultContainerService is bound. DefaultContainerService is a service for checking and distributing movable files, which is time-consuming, so it is not running in the same process as PMS. They communicate with each other through IMediaContainerService. If it is not bound, it will be bound. After that,

DefaultContainerConnection is also defined in PMS, and the execution link is as follows:

3. When sending MCS_BOUND message, it can be divided into two types according to whether the message sent has an object, as shown in the following figure:

4. Processing of 4.MCS_BOUND message:

HandlerParams is an abstract class in PMS, and its implementation class is the internal class of PMS. HandlerParams's startCopy method is as follows:

packagemanagerservice . Java # handler params

Call the abstract method handleStartCopy at Note ①, which is implemented in InstallParams, as follows:

packagemanagerservice . Java # install params

1 and note ① determine the installation location of APK.

2. Create the InstallArgs object in note ②. This object is an abstract class that defines the installation logic, such as copying and renaming APK. There are three subclasses in Android 8.x and before: FileInstallArgs, AsecInstallArgs and MoveInstallArgs. Among them, FileInstallArgs is used to process APK; installed in non-ASEC storage space, that is, internal storage space (data partition); AsecInstallArgs is used to process APK;; Installed in ASEC(mnt/asec), that is, SD card; MoveInstallArgs is used to handle the movement of installed APK; But AsecInstallArgs has been removed after Android 9.x,

3. the copyApk method of 3.InstallArgs is called in note ③. Here, taking the implementation of FileInstallArgs as an example, the doCopyApk method of FileInstallArgs will be called internally:

1. Note ① is used to create a temporary storage directory, such as/data/app/vmdl 18300388.tmp, where18300388 is the installed session ID;

2. In note ②, the copyPackage method of DefaultContainerService is called across processes through IMediaContainerService, which will copy APK to the temporary storage directory of the process where DefaultContainerService is located. For example,/data/app/vmdl18300388.tmp/base. APK, so the copy of apk is complete.

In the process of the APK assignment call chain, the handleReturnCode method will be called in the startCopy method of HandlerParams, and the timing diagram is as follows:

PackageManagerService # handleReturnCode:

Check the state of APK in Note ① before installation to ensure the reliability of the installation environment. If it is not reliable, the copied APK file will be cleared. Note ③ Whether the installation is successful or not will be checked. If the installation fails, the directories and files related to the installation will be deleted. After the installation is completed, a POST_INSALL message will be sent in note ⑤ to inform the installation is completed, which will be explained later here.

The installPackageTracedLI at note ② will call the installPackageLI method of PMS:

packagemanagerservice . Java # installPackageLI:

Here are a few points to note:

In 1 and note ③, it will be detected that the information of the APK to be installed is stored in the settings, which means that the APK is installed, and the signature information of the APK needs to be checked to ensure safe replacement.

2. In note ④, the temporary file will be renamed, for example,/data/app/vmdl18300388.tmp/base.apk, and renamed as/data/app/package name-Oonlrrpylyleu63aveqba = =/base.apk. The new package name is followed by a series of letters and numbers.

3. In note ⑤, it is distinguished according to substitution. If it is an alternative installation, the replacePackageLIF method will be called to internally distinguish between system APP and non-system APP. If it is a newly installed APK, the installNewPackageLIF method will be called.

packagemanagerservice . Java # installNewPackageLIF:

In the source code analysis of the processPendingInstall method above, a POST_INSTALL message will be sent at the comment ⑤ to inform the installation is completed, so let's take a concrete look at how to handle this message in the PackageHandler.

The above is a summary of the main methods, which can be summarized as follows:

1. Step 1: This is mainly to delete the installation information from the installation column list, which was also added in the previous processPendingInstall.

2. Step 2: Obtain runtime permissions after successful installation.

3. Step 3: After obtaining the permission, send an ACTION_PACKAGE_ADDED broadcast to inform Laucher of the process and update the icon.

Step 4: If it is an upgrade, broadcast it twice again.

5. Step 5: If PRIVATE_FLAG_FORWARD_LOCK is set in the installation package or it is required to be installed on the SD card, call the sendResourcesChangedBroadcast method to send the resource change broadcast.

6. Step 6: If the application is a browser, clear the browser settings and recheck the browser settings.

7. Step 7: Call gc forcibly and start JVM for garbage collection.

8. Step 8: Delete the old installation information

9. Callback Callback the packageInstalled method of IPackageInstallObserver2. Tell PackageInstaller the installation result. So as to realize the installation callback of the UI layer.

The above part roughly explains the main steps of PMS to deal with APK, which can be summarized as follows:

1. When PackageInstaller submits the information of APK to PMS for processing, PMS will drive the copy and installation of APK by sending a message to PackageHandler.

2.PMS sends INIT_COPY and MCS_BOUND messages to control PackageHandler to bind DefaultContainerService to copy APK.

3. After copying APK, start the process of installing APK, including pre-installation inspection, installation of APK and finishing work after installation.

[ 1]/framework/PMS/3-PMS-install . html

[4]article/5 1 19749905

[5]p/9 DDB 930 153 B7