The difference between the use of ADB push and adb install in Android is reproduced
This article is submitted by Yingchun Shi (@ three vulgar little Women). Reprint please specify the original address.
In the actual development of Android, the ADB command is often used, and the installation application can use ADB push or adb install. Here are the differences between the two ways of installation.
- ADB push enables you to specify the installation directory. For example, after implementing "ADB push xxx.apk System/app", xxx.apk is installed in the System/app directory, the software under this directory is the system application mentioned above. (Note that the System/app is read-only, so only the root permission can be used to push the apk in, and the APK will overwrite the original APK when it is push in.) The ADB push itself means copying the file to a folder in the system, but it will register the app after the APK is push to System/app and the phone is restarted.
- ADB install the software installed with this command is located in the Data/app directory, with the parameter-R to force the installation, user application.
As indicated by the above two, the main differences between the ADB install and the ADB push apk are:
|
Push |
Install |
| Directory |
System/app |
Data/app |
| Permissions |
System level (full access) |
User level (not fully open) |
| Unloading |
Delete after root |
Can be uninstalled |
| Size |
Unlimited, custom |
There are restrictions |
| Installation |
PM re-registration |
No re-registration |
Manually installed APK version number is the same as the system built-in API version number.
A deeper layer of analysis:
1 , Android System Application update mechanism
- The system provides Versionname, Versioncode two properties for each application in Androidmainfest.xml.
- The versionname:string type, which is used to view the version for the app's users.
- The Versioncode:integer type, as the basis for the system to determine whether the application can be upgraded.
2 , Android system built-in application update judgment code
- Code from Package update criteria for Scanpackageli functions in Frameworks/base/services/java/com/android/server/packagemanagerservice.java
From the above data analysis:
- The same AP, if there is a higher version of the app under Data/app, but the older version under System, follow the old version.
- It is also known that if more than two APs are in the same process but only one AP has changed API version, the compilation will fail
- Suppose there are two ap:ap1 and AP2. Two APs are both build through and install into the phone after the API version update. And the system has built-in AP1 is the old version, the reboot will still register the old version of the AP1. At this point, the same process will appear in the system but different versions of AP1 (System/app) and AP2 (Data/app)
In summary, compilation will go wrong.
Guess:
- If the APS of the same process are compiled with the same version of the SDK, push into the phone, it can be run (verified).
- If the APS of the same process are compiled with the same version of the SDK. Install into the phone, you can run it, if you delete all the same process APS within the System/app. (verified)
- If the AP of the same process is compiled with the same version of the SDK, the Push/install can be (to be verified).
Add: When using Push, the corresponding apk in the original system will be overwritten, so it is best to back up one copy, with the following command:
ADB pull/system/app/xxxx.apk/home/
android adb push vs. ADB install (two ways of installing APK)
Differences between the use of ADB push and adb install in Android
