android安裝原理

A. Android 的提權 (Root) 原理是什麼

android其實是基於linux的一個操作系統，只是被用到了移動設備上面了，如果你想在pc上面安裝android系統，理論上是完全可行的。
現在其實才牽涉到了android root的原理，root其實就是獲取android系統的root許可權。至於原理：手機製造商原始出廠的手機並未開放root許可權，獲取root的方法都是不受官方支持的，因此，目前獲取root的方法都是利用系統漏洞實現的。而不同手機廠商可能存在的漏洞不同，也就導致了不同手機root的原理可能不同。不過，不管採用什麼原理實現root，最終都需要將su可執行文件復制到Android系統的/system分區下(例如：/system/xbin/su) 並用chmod命令為其設置可執行許可權和setuid許可權。為了讓用戶可以控制root許可權的使用，防止其被未經授權的應用所調用，通常還有一個Android應用程序來管理su程序的行為。root的基本原理就是利用系統漏洞，將su和對應的Android管理應用復制到/system分區。（這個是我復制的維基網路的，如果你懂一點兒linux，那麼這個過程就很好理解，如果不懂呢，那麼你可以忽略掉。）

B. Android系統應用安裝過程以及應用備份原理是怎樣的

可以下載一個360手機助手，再用數據線連到電腦，就可以了，在電腦上選擇游戲，就會自動下載安裝了

C. Android V1及V2簽名原理簡析

Android為了保證系統及應用的安全性，在安裝APK的時候需要校驗包的完整性，同時，對於覆蓋安裝的場景還要校驗新舊是否匹配，這兩者都是通過Android簽名機制來進行保證的，本文就簡單看下Android的簽名與校驗原理，分一下幾個部分分析下：

簽名是摘要與非對稱密鑰加密相相結合的產物，摘要就像內容的一個指紋信息，一旦內容被篡改，摘要就會改變，簽名是摘要的加密結果，摘要改變，簽名也會失效。Android APK簽名也是這個道理，如果APK簽名跟內容對應不起來，Android系統就認為APK內容被篡改了，從而拒絕安裝，以保證系統的安全性。目前Android有三種簽名V1、V2（N）、V3（P），本文只看前兩種V1跟V2，對於V3的輪密先不考慮。先看下只有V1簽名後APK的樣式：

再看下只有V2簽名的APK包樣式：

同時具有V1 V2簽名：

可以看到，如果只有V2簽名，那麼APK包內容幾乎是沒有改動的，META_INF中不會有新增文件，按Google官方文檔：在使用v2簽名方案進行簽名時，會在APK文件中插入一個APK簽名分塊，該分塊位於zip中央目錄部分之前並緊鄰該部分。在APK簽名分塊內， 簽名和簽名者身份信息會存儲在APK簽名方案v2分塊中，保證整個APK文件不可修改 ，如下圖：

而V1簽名是通過META-INF中的三個文件保證簽名及信息的完整性：

V1簽名是如何保證信息的完整性呢？V1簽名主要包含三部分內容，如果狹義上說簽名跟公鑰的話，僅僅在.rsa文件中，V1簽名的三個文件其實是一套機制，不能單單拿一個來說事，

如果對APK中的資源文件進行了替換，那麼該資源的摘要必定發生改變，如果沒有修改MANIFEST.MF中的信息，那麼在安裝時候V1校驗就會失敗，無法安裝，不過如果篡改文件的同時，也修改其MANIFEST.MF中的摘要值，那麼MANIFEST.MF校驗就可以繞過。

CERT.SF個人覺得有點像冗餘，更像對文件完整性的二次保證，同繞過MANIFEST.MF一樣，.SF校驗也很容易被繞過。

CERT.RSA與CERT.SF是相互對應的，兩者名字前綴必須一致，不知道算不算一個無聊的標准。看下CERT.RSA文件內容：

CERT.RSA文件裡面存儲了證書公鑰、過期日期、發行人、加密演算法等信息，根據公鑰及加密演算法，Android系統就能計算出CERT.SF的摘要信息，其嚴格的格式如下：

從CERT.RSA中，我們能獲的證書的指紋信息，在微信分享、第三方SDK申請的時候經常用到，其實就是公鑰+開發者信息的一個簽名：

除了CERT.RSA文件，其餘兩個簽名文件其實跟keystore沒什麼關系，主要是文件自身的摘要及二次摘要，用不同的keystore進行簽名，生成的MANIFEST.MF與CERT.SF都是一樣的，不同的只有CERT.RSA簽名文件。也就是說前兩者主要保證各個文件的完整性，CERT.RSA從整體上保證APK的來源及完整性，不過META_INF中的文件不在校驗范圍中，這也是V1的一個缺點。V2簽名又是如何保證信息的完整性呢？

前面說過V1簽名中文件的完整性很容易被繞過，可以理解 單個文件完整性校驗的意義並不是很大 ，安裝的時候反而耗時，不如採用更加簡單的便捷的校驗方式。V2簽名就不針對單個文件校驗了，而是 針對APK進行校驗 ，將APK分成1M的塊，對每個塊計算值摘要，之後針對所有摘要進行摘要，再利用摘要進行簽名。

也就是說，V2摘要簽名分兩級，第一級是對APK文件的1、3 、4 部分進行摘要，第二級是對第一級的摘要集合進行摘要，然後利用秘鑰進行簽名。安裝的時候，塊摘要可以並行處理，這樣可以提高校驗速度。

APK是先摘要，再簽名，先看下摘要的定義：Message Digest：摘要是對消息數據執行一個單向Hash，從而生成一個固定長度的Hash值，這個值就是消息摘要，至於常聽到的MD5、SHA1都是摘要演算法的一種。理論上說，摘要一定會有碰撞，但只要保證有限長度內碰撞率很低就可以，這樣就能利用摘要來保證消息的完整性，只要消息被篡改，摘要一定會發生改變。但是，如果消息跟摘要同時被修改，那就無從得知了。

而數字簽名是什麼呢（公鑰數字簽名），利用非對稱加密技術，通過私鑰對摘要進行加密，產生一個字元串，這個字元串+公鑰證書就可以看做消息的數字簽名，如RSA就是常用的非對稱加密演算法。在沒有私鑰的前提下，非對稱加密演算法能確保別人無法偽造簽名，因此數字簽名也是對發送者信息真實性的一個有效證明。不過由於Android的keystore證書是自簽名的，沒有第三方權威機構認證，用戶可以自行生成keystore，Android簽名方案無法保證APK不被二次簽名。

知道了摘要跟簽名的概念後，再來看看Android的簽名文件怎麼來的？如何影響原來APK包？通過sdk中的apksign來對一個APK進行簽名的命令如下：

其主要實現在 android/platform/tools/apksig 文件夾中，主體是ApkSigner.java的sign函數，函數比較長，分幾步分析

先來看這一步，ApkUtils.findZipSections，這個函數主要是解析APK文件，獲得ZIP格式的一些簡單信息，並返回一個ZipSections，

ZipSections包含了ZIP文件格式的一些信息，比如中央目錄信息、中央目錄結尾信息等，對比到zip文件格式如下：

獲取到 ZipSections之後，就可以進一步解析APK這個ZIP包，繼續走後面的簽名流程，

可以看到先進行了一個V2簽名的檢驗，這里是用來簽名，為什麼先檢驗了一次？第一次簽名的時候會直接走這個異常邏輯分支，重復簽名的時候才能獲到取之前的V2簽名，懷疑這里獲取V2簽名的目的應該是為了排除V2簽名，並獲取V2簽名以外的數據塊，因為簽名本身不能被算入到簽名中，之後會解析中央目錄區，構建一個DefaultApkSignerEngine用於簽名

先解析中央目錄區，獲取AndroidManifest文件，獲取minSdkVersion(影響簽名演算法)，並構建DefaultApkSignerEngine，默認情況下V1 V2簽名都是打開的。

第五步與第六步的主要工作是：apk的預處理，包括目錄的一些排序之類的工作，應該是為了更高效處理簽名，預處理結束後，就開始簽名流程，首先做的是V1簽名（默認存在，除非主動關閉）：

步驟7、8、9都可以看做是V1簽名的處理邏輯，主要在V1SchemeSigner中處理，其中包括創建META-INFO文件夾下的一些簽名文件，更新中央目錄、更新中央目錄結尾等，流程不復雜，不在贅述，簡單流程就是：

這里特殊提一下重復簽名的問題： 對一個已經V1簽名的APK再次V1簽名不會有任何問題 ，原理就是：再次簽名的時候，會排除之前的簽名文件。

可以看到目錄、META-INF文件夾下的文件、sf、rsa等結尾的文件都不會被V1簽名進行處理，所以這里不用擔心多次簽名的問題。接下來就是處理V2簽名。

V2SchemeSigner處理V2簽名，邏輯比較清晰，直接對V1簽名過的APK進行分塊摘要，再集合簽名，V2簽名不會改變之前V1簽名後的任何信息，簽名後，在中央目錄前添加V2簽名塊，並更新中央目錄結尾信息，因為V2簽名後，中央目錄的偏移會再次改變：

簽名校驗的過程可以看做簽名的逆向，只不過覆蓋安裝可能還要校驗公鑰及證書信息一致，否則覆蓋安裝會失敗。簽名校驗的入口在PackageManagerService的install里，安裝官方文檔，7.0以上的手機優先檢測V2簽名，如果V2簽名不存在，再校驗V1簽名，對於7.0以下的手機，不存在V2簽名校驗機制，只會校驗V1，所以，如果你的App的miniSdkVersion<24(N)，那麼你的簽名方式必須內含V1簽名：

校驗流程就是簽名的逆向，了解簽名流程即可，本文不求甚解，有興趣自己去分析，只是額外提下覆蓋安裝，覆蓋安裝除了檢驗APK自己的完整性以外，還要校驗證書是否一致只有證書一致（同一個keystore簽名），才有可能覆蓋升級。覆蓋安裝同全新安裝相比較多了幾個校驗

這里只關心證書部分：

Android V1及V2簽名簽名原理簡析

僅供參考，歡迎指正

D. Android N 四大組件的工作原理

本文側重講解android N 系統中四大組件的工作原理，不同系統原理略有差別。通過分析四大組件的工作流程加深對Android Framework的理解，也為插件化開發打下基礎。

Activity
展示一個界面並和用戶交互，它扮演的是一個前台界面的角色。

Service
計算型組件，用於後台執行一系列計算任務，工作在主線程，耗時操作需要另起線程， 分為啟動狀態和綁定狀態。

BroadcastReceiver
消息型組件，主要用於不同組件或者不同應用之間的消息傳遞，它工作在系統內部，不適合執行耗時操作，操作超過5s，會出現ANR。

ContentProvider
數據共享型組件，用於向其他組件或者應用共享數據，主要執行CURD操作。

我們啟動一個activity有兩種方法，
第一種（Activity直接啟動方式）：
Intent intent = new Intent(this, MainActivity.class);
startActivity(intent);

第二種（Context啟動方式）
Intent intent = new Intent(this, MainActivity.class);
getApplicationContext().startActivity(intent);

不同的啟動方式Activity的工作流程有點差別。

兩種啟動都會調用到Instrumentation類中的execStartActivity的方法，系統最終是通過ActivityThread中的performLaunchActivity完成Activity的創建和啟動。
performLaunchActivity方法主要完成以下工作：
1、通過ActivityClientRecord對象獲取啟動activity的組件信息
2、通過mInstrumentation對象的newActivity方法調用classloader完成activity的創建
3、通過r.packageInfo(LoadedApk 對象)的makeApplication方法嘗試創建Application對象
4、創建ContextImpl對象並調用Activity的attach方法完成一些數據的初始化
5、調用Activity的onCreate方法

在Activity啟動的過程中，App進程會頻繁地與AMS進程進行通信：

App進程會委託AMS進程完成Activity生命周期的管理以及任務棧的管理；這個通信過程AMS是Server端，App進程通過持有AMS的client代理IActivityManager完成通信過程；
AMS進程完成生命周期管理以及任務棧管理後，會把控制權交給App進程，讓App進程完成Activity類對象的創建，以及生命周期回調；這個通信過程也是通過Binder完成的，App所在server端的Binder對象存在於ActivityThread的內部類ApplicationThread；AMS所在client通過持有IApplicationThread的代理對象完成對於App進程的通信。

Service有兩種啟動方式，startService()和bindService()，兩種狀態可以並存:
startService流程

bindService流程

BroadcastReceiver的工作過程主要包括廣播的注冊、發送和接收:

動態注冊過程：

發送過程

靜態注冊是由PackageManagerService（PMS）在應用安裝的時候完成整個注冊過程的，除廣播以外，其他三大組件也都是在應用安裝時由PMS解析並注冊的。

每個進程的入口都是ActivityThead.main()，App的啟動流程如下：

從源碼中可以看出：
應用啟動的入口為ActivityThread的main方法，main方法會創建ActivityThread實例並創建主線程消息隊列。
attach方法中遠程調用AMS的attachApplication方法，並提供ApplicationThread用於和AMS的通信。
attachApplication方法會通過bindApplication方法和H來調回ActivityThread的handleBindApplication，這個方法會先創建Application，再載入ContentProvider，然後才會回調Application的onCreate方法。

由上圖可以看出，在ContentProvider的啟動過程中伴隨著app進程的啟動。

ContentProvider的其他CURD操作如insert，delete，update跟query的流程類似。

E. 如何實現android靜默安裝

原理：
使用隱藏的系統API——installPackage。該方法在1.5版之後的android SDK中是看不見的，查看源碼可以看到它設置了@hide屬性，但在實際的運行包framework.jar中是存在的，因此只要能編譯通過，安裝到系統後是可以正常運行的。
步驟：
1. 從模擬器System\framework目錄下提取framework.jar
2. 將framework.jar後綴名改為zip，解壓後提取其中的classes.dex文件
3. 用dex2jar工具將classes.dex轉成classes.dex.dex2jar.jar(注意新版本的dex2jar工具無法轉換Android2.2的framework，建議使用dex2jar-0.0.7.8-SNAPSHOT，該工具可以從google官方站上下載到)
4. 將classes.dex.dex2jar.jar改名為classes.dex.dex2jar.zip解壓取出android/content/pm/目錄下的PackageManager.class，IPackageInstallObserver.class，IPackageDeleteObserver.class及相關的幾個class文件備用
5. 找到android-sdk目錄下的android.jar,改名為android.zip（注意改名前先備份一下）,解壓後將步驟4中取得的class文件覆蓋到android對應的目錄下，重新壓縮成android.zip，並改名為android.jar
6. 這個時候android.jar已經是一個更新過的SDK了，重新打開eclipse工程，已經可以實現。
調用方法：
void android.content.pm.PackageManager.installPackage(Uri packageURI, IPackageInstallObserver observer, int flags, String installerPackageName)

說明：
1. 由於更改android.jar可能導致重新載入SDK失敗，覆蓋之前切記備份一下
2. 實際上該過程可以調用到任何hide屬性的API，本文為了影響最小，只覆蓋了installPackage相關的class
3. 下載android源碼重新編譯SDK也可以實現調用隱藏API，不過比較麻煩

F. 如何搭建android運行環境

1.Android運行環境的搭建

進行安卓系統的軟體設計，那麼JDK的開發環境搭建必須是首要的。我們選擇Windows10 64位操作系統。同時在JDK版本的選擇中選用Windows x64版本的Java SE Development Kit 8u5，該版本穩定，應用廣泛而且開源免費，獲取方便。在安裝的過程中要注意不要重復安裝，應安裝完畢後立即刪除安裝包，否則如果不小心再次點到安裝包，該安裝包會立刻刪除所安裝的程序並詢問是否重新安裝。在JDK的安裝過程中，要注意開發工具，源代碼，公共JRE三項都要選中，而且要安裝到C盤默認目錄下，同時將其附帶的JRE同樣安裝到相同目錄下，同時硬碟至少應該留有2G的空間。

選擇好JDK的版本並進行安裝後，我們的JAVA環境就安裝好了，眾所周知，安卓系統是由JAVA語言架構的，所以在搭建安卓運行環境之前必須要先安裝JAVA環境。安裝完JAVA環境之後，我們進行安卓開發環境的搭建。我們就要進行Android SDK版本的選擇。我們這里選擇android-sdk_r24.4.1-windows版本。這個版本是與安卓8.0同時發布的，同時它的發布時間也在我們的安卓測試機紅米NOTE5A型號之後，可以完美兼容我們的安卓測試機所運行的安卓7.1.2版本。

5. 總結

本次主要介紹了系統軟體環境的搭建與生成,從Android運行環境的搭建，Windows系統環境變數設置，Android SDK的配置， SDK介面和APK生成幾個方面分別介紹了具體步驟,讓我們了解了本文安卓系統軟體開發的環境配置。

以上就是安卓環境和下載和安裝啦，按步驟來操作對小白來說也是相對簡單的，只要注意一些文中說明的細節，現在就開始行動起來一起學unity吧。

G. android系統原理

Android系統原理及開發要點詳解

給您看看

H. android如何實現靜默安裝哦

原理

• 靜默安裝、卸載的原理就是利用pm install命令來安裝apk，pm uninstall 來卸載apk.

• 智能安裝是利用android系統提供的無障礙服務AccessibilityService，來模擬用戶點擊，從而自動安裝.

//靜默安裝
privatevoidinstallSlient(){
Stringcmd="pminstall-r/mnt/sdcard/test.apk";
Processprocess=null;
DataOutputStreamos=null;
BufferedReadersuccessResult=null;
BufferedReadererrorResult=null;
StringBuildersuccessMsg=null;
StringBuildererrorMsg=null;
try{
//靜默安裝需要root許可權
process=Runtime.getRuntime().exec("su");
os=newDataOutputStream(process.getOutputStream());
os.write(cmd.getBytes());
os.writeBytes("
");
os.writeBytes("exit
");
os.flush();
//執行命令
process.waitFor();
//獲取返回結果
successMsg=newStringBuilder();
errorMsg=newStringBuilder();
successResult=newBufferedReader(newInputStreamReader(process.getInputStream()));
errorResult=newBufferedReader(newInputStreamReader(process.getErrorStream()));
Strings;
while((s=successResult.readLine())!=null){
successMsg.append(s);
}
while((s=errorResult.readLine())!=null){
errorMsg.append(s);
}
}catch(Exceptione){
e.printStackTrace();
}finally{
try{
if(os!=null){
os.close();
}
if(process!=null){
process.destroy();
}
if(successResult!=null){
successResult.close();
}
if(errorResult!=null){
errorResult.close();
}
}catch(Exceptione){
e.printStackTrace();
}
}
//顯示結果
tvTest.setText("成功消息："+successMsg.toString()+"
"+"錯誤消息:"+errorMsg.toString());
}

I. 安卓系統是否可以刷到任何硬體設備上

樓主你好！

如果有Android系統的源代碼，然後又有 硬體設備的原理圖。理論上就可以做到將Android系統安裝到所有硬體上。不過用程序員嚴謹的話講，這句話成立還有個前提，那就是Android 源碼中所包含的Linux 源碼中，支持你硬體中CPU執行的指令集。如果CPU都不認識你編譯出來的程序指令，你有如何期望他能夠正確跑的寫的Driver呢？

J. 安卓手機軟體無法安裝，提示安裝未完成。

1、可能你的手機裡面，軟體殘留的東西太多了，建議先用360手機衛士之類的管理軟體清理一下。
2、之前安裝過同類的軟體，但是出現過問題，導致安裝發生問題。
3、安裝包下載的不完全或者有損壞，導致安裝過程無法完成，可以換一個版本的安裝包試試。
下面引用一套解決方案：
（其實解決的方法理論上不受機型和系統限制，原理應該都是一樣的，跟SD卡也沒關系~）
系統環境：已Root，已做APP2SD+，SD卡分為兩個區：一個512M的Ext分區（安裝軟體的地方），一個剩餘空間的Fat32分區
首先說一下問題發生時的症狀：最近一段時間連續發生了三個應用程序未安裝的情況，無論是從市場里安裝還是用豌豆莢的各種安裝方法均顯示「應用程 序未安裝」，並且用各種卸載工具、軟體管理工具以及系統內置的程序管理均無法找到相關應用程序，連無圖標那種都沒有，屬於徹徹底底的找不著，就連用RE瀏 覽器也搜索不到，而除此之外的其他應用程序都可以正常安裝~
之前嘗試解決的過程（均無效，懶得看的朋友可以直接跳過）：
1、第一個想法就是系統內有程序殘留，可能是未刪除干凈導致無法安裝，因此用RE瀏覽器搜索程序相關關鍵字，把找到的相關文件和目錄全部刪除，然後重啟再安裝程序，結果無效；
2、想到之前有過備份，於是打開鈦備份，找到相關軟體，還原：最開始選擇的是程序+數據，顯示還原失敗，然後單獨選擇還原程序，提示還原成功， 但是在系統內並沒有看到還原成功的程序，所以被忽悠了（這里我沒有做重啟系統的嘗試，不知道如果還原之後重啟系統會不會有效，有興趣的朋友可以試試 哈~）；
3、沒辦法，只能Google了，首先找到的是成功最多的一種方法：【儲存模式連接電腦或者用Root Explorer找到SD卡目錄下的.android_secure文件夾，裡面應該會有一個smdl2tmp1.asec，也可能是其他名稱，總之與正 常程序命名格式明顯不一樣的文件，刪除，再次安裝軟體試試】，但是我無論是系統還是SD卡均找不到相關目錄及文件，所以這種方法對我完全沒用；
4、第二種方法：【如果是PC端上安裝應用提示失敗，請先檢查有沒有安裝Android手機對應的的USB驅動,一般使用91手機助手或豌豆夾都會自動幫你裝上手機驅動】，我是手機端提示失敗，並且我的驅動正確安裝，豌豆莢也使用正常，所以這個跟我無關；
5、第三種方法：【查看手機設置-應用程序-未知來源 是否勾選，否則就會導致有些非電子市場提供的應用程序無法安裝】，我勾選的，所以這個也跟我無關；
6、第四種方法：【用系統自帶的程序管理查看SD卡上的程序，有的程序竟然是沒有彩色圖標的，原來就是這些 沒有圖標的軟體在作怪，這些沒有圖標的軟體就是以前一些沒有正確安裝或者卸載不完全軟體數據，如果你再次安裝就會報錯，現在我們用系統自帶的軟體管理把它 們卸載干凈，再次安裝軟體時就不會出錯了】，可是我用系統自帶的程序管理連任何圖標都看不到，所以這種方法對我沒用；
7、第五種方法：【只需刪除/mnt/secure/asec/smdl2tmp1.asec (驅動器模式下是：可移動磁碟/.android_secure/smdl2tmp1.asec)，再安裝即可】，這種方法是第一種方法的補充，可惜的是 我系統和卡里也根本沒有mnt目錄，所以沒用；
8、第六種方法：【升級已安裝的程序時提示「應用程序未安裝」 少部分軟體升級時會出現，只能卸載掉舊版本，再安裝新版本】，我根本找不到卸載，所以也沒用；
9、第七種方法：【在設置-開發-允許模擬地點上打鉤，就OK樂】，這個我勾上了還是沒用；
10、第八種方法：【手機連接電腦然後打開91手機助手，隨便安裝一個應用程序，選擇安裝路徑為手機內存】，我是2.1系統，本來軟體就都是裝在「內存」中的，所以這個也沒用；
11、第九種方法：【還有一部分因為軟體簽名更改了，所以不能覆蓋安裝，直接刪除重新安裝新的版本即可】，這個原理同方法六一樣，所以對我無效；
12、第十種方法：【直接恢復出廠設置】，這是我不願意做的一種方法，理論上應該有效吧。
經過了以上各種嘗試後，問題仍舊無法解決，那個郁悶啊，難道我就必須恢復出廠么？猶豫再三，都已經開始准備重裝了，結果在搜索安卓系統安裝原理的時候居然被我找到一種方法，解決了這個困擾我多時的未安裝問題，下面我們一起來看下解決方案：
其實安卓系統的程序安裝就是把APK文件復制到APP目錄下並賦予許可權，備份也是把APK文件以及相關的數據文件復制出來，依照此原理，我做了如下操作：
1、首先下載應用程序的APK安裝包放到SD卡里；
2、將APK文件改名為com.xxx.xxx.apk的形式（對比系統APP目錄下的文件名做的改動，純中文或者其他任意文件名能否成功我沒有做過測試~）；
3、用有Root許可權的RE瀏覽器將卡內的APK文件移動或復制到系統目錄內的APP目錄下（就是你能看到其他應用程序圖標的那個目錄）；
4、找到你復制過來的APK文件，長按調出菜單選「許可權」，對照下圖勾選相應的許可權並確定；
讀寫執行
用戶√√○
分組√○○
其他√○○
5、重啟手機（這一步很重要，重啟之後系統才會重新搜索應用程序）；
6、怎麼樣？重啟之後是不是又看見可愛的程序圖標了？打開試試，都能正常使用~（不要以為到這里就結束了）；
7、雖然程序正常了，但是如果再次安裝或者升級，之前的一切就白做了，就會再次變成最初的「應用程序未安裝」狀態；
8、因此在程序能正常使用的時候，打開任何一款程序卸載軟體，我用的是深度卸載，找到並卸載之；
9、正常卸載之後，這次你可以放心的重新安裝了，升級什麼的也不會出現「應用程序未安裝」了。
至此，這個問題就算是完美解決了，希望對深受「應用程序未安裝」困擾的機友們能有所幫助