㈠ 求問android怎麼在代碼里獲得系統文件的讀寫許可權
本來以為就沒有辦法在應用程序這一層改系統時間了，後來在網上搜了好久，知道這個目的還是可以達到的。
第一個方法簡單點，不過需要在Android系統源碼的環境下用make來編譯：
1. 在應用程序的AndroidManifest.xml中的manifest節點中加入
android:sharedUserId="android.uid.system"這個屬性。
2. 修改Android.mk文件，加入LOCAL_CERTIFICATE := platform這一行
3. 使用mm命令來編譯，生成的apk就有修改系統時間的許可權了。
第二個辦法麻煩點，不過不用開虛擬機跑到源碼環境下用make來編譯：
1. 同上，加入android:sharedUserId="android.uid.system"這個屬性。
2. 使用eclipse編譯出apk文件，但是這個apk文件是不能用的。
3. 用壓縮軟體打開apk文件，刪掉META-INF目錄下的CERT.SF和CERT.RSA兩個文件。
4. 使用目標系統的platform密鑰來重新給apk文件簽名。這步比較麻煩，
首先找到密鑰文件，在我的Android源碼目錄中的位置
是"build argetproctsecurity"，下面的platform.pk8和platform.x509.pem
兩個文件。
然後用Android提供的Signapk工具來簽名，signapk的源代碼是
在"build oolssignapk"下，
用法為"signapk platform.x509.pem platform.pk8 input.apk output.apk"，
文件名最好使用絕對路徑防止找不到，也可以修改源代碼直接使用。
這樣最後得到的apk和第一個方法是一樣的。
最後解釋一下原理，首先加入android:sharedUserId="android.uid.system"這個屬性。通過Shared User id,擁有同一個User id的多個APK可以配置成運行在同一個進程中。那麼把程序的UID配成android.uid.system，也就是要讓程序運行在系統進程中，這樣就有許可權來修改系統時間了。
只是加入UID還不夠，如果這時候安裝APK的話發現無法安裝，提示簽名不符，原因是程序想要運行在系統進程中還要有目標系統的platform
key，就是上面第二個方法提到的platform.pk8和platform.x509.pem兩個文件。用這兩個key簽名後apk才真正可以放入系統進程中。第一個方法中加入LOCAL_CERTIFICATE := platform其實就是用這兩個key來簽名。這也有一個問題，就是這樣生成的程序只有在原始的Android系統或者是自己編譯的系統中才可以用，因為這樣的系統才可以拿到 platform.pk8和platform.x509.pem兩個文件。要是別家公司做的Android上連安裝都安裝不了。試試原始的Android 中的key來簽名，程序在模擬器上運行OK，不過放到G3上安裝直接提示"Package ... has no signatures that match those in shared user android.uid.system"，這樣也是保護了系統的安全。
java代碼 1、必須是Android系統開發人員，否則你無法修改init.rc等文件。 2、你的應用程序必須要獲得system許可權。 在應用層 你要想用代碼獲得系統文件許可權，除非你手機root了 要麼你自己坐rom。。。。 自己修改 init，rc
方法/步驟
1
首先找到你要操作的文件夾，這里用一個音效卡相關的文件夾做例子。選中文件夾。右擊它。選擇文件的屬性，安全--->高級。
2
更改所有者，如圖所示。在輸入對象名稱那兒，輸入你的賬戶名稱，我的是微軟賬戶。輸入完之後確定。
3
回到剛才的界面，你會看到所有者已經改變了，變成了你的賬號。然後確定退出，回到文件夾。（一定要確定後退出回到文件中，才能進行下一步）
4
再次回到剛才的界面。禁止所有繼承。
5
添加用戶。輸入賬號，我輸入的是微軟賬號。輸入後確定。
通過第三方軟體獲得Root許可權，可以訪問和修改手機操作系統里幾乎所有的文件，但這樣操作有可能影響手機的穩定性，出現死機、重啟等人為性故障。
另外獲取許可權後一般對存儲器和CPU等主板上主要部件引起不良。Root屬於修改操作系統軟體，按照條例不屬於包修范圍。為了提升顧客滿意度，對Root顧客提供免費升級固件服務，如果Root已影響到手機硬體需要更換主板，則需要收取主板費用。
若您的機器Root後需將機器恢復到原來的系統版本，請將機器送到服務中心，由售後工程師幫助檢查處理。自行將設備恢復出廠設置是無法取消Root許可權的。
對於已經獲取所有許可權的文件，建議大家還是恢復到原來的狀態。今天就跟大家分享一下如何恢復系統文件的默認許可權，Windows 7和Windows 8系統都是一樣的操作步驟。這里以平時最常修改的hosts文件為例，下圖顯示已獲取hosts文件所有許可權。已獲得所有許可權的hosts文件恢復許可權有點類似於於逆向操作，首先點選Administrators組（上圖藍色條），然後點擊下方的「高級」按鈕，切換到「所有者」標簽。高級安全設置-所有者在上面的窗口中，點擊「編輯」按鈕打開新窗口來更改所有者。編輯所有者到這一步，你會發現可更改的所有者並沒有當初替換時的TrustedInstaller，怎麼辦？別急，點擊「其他用戶或組」來添加它。在新開的窗口裡，輸入：NT SERVICE＼TrustedInstaller，注意前面的NT SERVICE一定要加上，否則系統不認。添加TrustedInstaller用戶完成後點擊確定回到上一窗口，此時會看到TrustedInstaller用戶出現了，接下去就是選擇它，然後一路確定退出各個窗口。文件所有權恢復到默認狀態
File類裡面就有canRead，canWrite，canExecute方法啊。 查看原帖>>
麻煩採納，謝謝!
用re
先耐心的把這里的帖子看上幾頁，再多網路網路資料，不要手機一上手就玩這些要root許可權的內容，容易出問題，到時候問題越來越多。。。建議至少2周後再做這些事情，對你會很有幫助。 查看原帖>>
對於一般文件來說，是不需要開啟administrator賬戶的，只需要一個簡單的辦法就OK啦！比如說，對待下面的這種類型的文件夾。
2
我們只需要擊右鍵，選擇「管理員取得所有權」即可。
3
對於一些程序文件來說，只需要你擊右鍵，選擇「以管理員身份運行」，也是一個非常便捷的獲得管理員許可權的辦法。
END
開啟Administrator賬戶的方法
Windows 7系統中，administrator賬戶並不是默認開啟的，那麼就需要我們手動開啟，這也不是很難的啦！對計算機圖標，擊右鍵，選擇管理。
打開界面後，選擇本地用戶和組，單擊用戶，選擇administrator賬戶即可。
3
打開，administrator賬戶之後，按照以下的操作來進行就行了。
4
這樣，在開始登陸的界面，即可以出現administrator賬戶了，選擇此賬戶即可獲得管理員最高許可權，不過建議一般來說此賬戶還是不要開啟的好，如果此賬戶受損，再創建帳戶很容易失敗。還有，在第一次開啟此賬戶時，是不需要密碼的。
這個問題其實LBE已經解決了。 1.在2012隱私保護版中，每次運行時請求系統root，創建一個開機啟動服務libload.so，專門用於處理lbe自身的root請求。 2.在2013免root版中，首次運行時自動獲取系統root，並把破解過的su文件復制到/system/xbin/.sv ，然後給6755的許可權，專門用於處理lbe自身的root請求。 上述兩種方案，均為程序自帶root管理，用於解決其自身root請求。 以下代碼即為方案2的原理，附件中為修改過的su文件。 ******************************************* 安卓的su文件，基本原理為 1234567if (pid=DB(Allow)) then "get uid=0 root" 白名單，程序獲取rootelseif (pid=DB(Disable)) Return 黑名單，返回空else View"superuser.active" 資料庫無記錄，「授權管理」彈出root請求窗口endif修改後的su文件 1if (pid<>"") then "get uid=0 root" 無條件，返回root********************************************** 我反編譯b.apk，然後把java應用調用runtime.exec("su")的代碼全部改為runtime.exec("sa")， 然後重新打包簽名好。安裝這個軟體。 用RE文件管理器把上面附件的su改名為sa，復制到/system/xbin/sa並改許可權rwsx-rsx-r。 以後使用b.apk，獲取root許可權沒有任何提示。 su.zip大小：249.85K 已經過網路安全檢測,放心下載 點擊下載下載量:133
㈡ 如何用Android MTK源碼生成簽名文件
在linux環境中，以Android源碼目錄為根目錄
cd build/target/proct/security/
其中的platform.pk8是製作系統簽名需要的文件、
1 在這個目錄下，執行
openssl pkcs8 -inform DER -nocrypt -in platform.pk8 -out platform.pem
生成臨時文件platform.pem
2 接著執行以下命令，將在目錄下生成platform.p12文件，它本質上應該就是一個數字證書。
openssl pkcs12 -export -in platform.x509.pem -out platform.p12 -inkey platform.pem -password pass:android -name androiddebugkey
3 然後再執行以下，
keytool -importkeystore -deststorepass android -destkeystore ./platform.jks -srckeystore ./platform.p12 -srcstoretype PKCS12 -srcstorepass android
這個名字可以改成debug.keystore. 後綴名沒有關系，eclipse和AS都識別 platform.jks
出現以下信息，表示成功生成 platform.jks
4 然後在打包 apk 的時候選擇platform.jks文件，就可以直接用adb命令安裝apk到機器中了。
adb install xxxx
㈢ Android基礎『V1V2V3簽名』
基礎概念
簽名：在 APK 中寫入一個「指紋」。指紋寫入以後，APK 中有任何修改，都會導致這個指紋無效，Android 系統在安裝 APK 進行簽名校驗時就會不通過，從而保證了安全性。
摘要演算法： 使用一段簡單的看上去隨機的不可逆向的固定長度的字元串來表示一個文件的唯一性。 常見的摘要演算法如MD5(128個比特位)、SHA-1演算法(160/192/256個比特位)。
公鑰密碼體制：也稱非對稱演算法，特點是 公鑰是公開的 ，私鑰是保密的。常見的如：RSA。
展開討論一下RSA：
Android中的簽名方案
V1 ：基於jarsigner(JDK自帶工具，使用keystore文件進行簽名) 或 apksigner(Android專門提供的，使用pk8、x509.pem進行簽名)。keystore和pk8/x509.pem可以相互轉換。
簽名原理：首先keystore文件包含一個MD5和一個SHA1摘要。 這也是很多開放平台需要我們上傳的摘要數據 。
簽名APK後會在META-INF文件夾下生產CERT.RSA、CERT.SF、MANIFEST.MF三個文件。
在apk中，/META-INF文件夾中保存著apk的簽名信息，一般至少包含三個文件，[CERT].RSA，[CERT].SF和MANIFEIST.MF文件。這三個文件就是對apk的簽名信息。
MANIFEST.MF中包含對apk中除了/META-INF文件夾外所有文件的簽名值，簽名方法是先SHA1()(或其他hash方法)在base64()。存儲形式是：Name加[SHA1]-Digest。
[CERT].SF是對MANIFEST.MF文件整體簽名以及其中各個條目的簽名。一般地，如果是使用工具簽名，還多包括一項。就是對MANIFEST.MF頭部信息的簽名，關於這一點前面源碼分析中已經提到。
[CERT].RSA包含用私鑰對[CERT].SF的簽名以及包含公鑰信息的數字證書。
是否存在簽名偽造可能：
修改(含增刪改)了apk中的文件，則：校驗時計算出的文件的摘要值與MANIFEST.MF文件中的條目不匹配，失敗。
修改apk中的文件+MANIFEST.MF,則：MANIFEST.MF修改過的條目的摘要與[CERT].SF對應的條目不匹配，失敗。
修改apk中的文件+MANIFEST.MF+[CERT].SF，則：計算出的[CERT].SF簽名與[CERT].RSA中記錄的簽名值不匹配，失敗。
修改apk中的文件+MANIFEST.MF+[CERT].SF+[CERT].RSA，則：由於證書不可偽造，[CERT].RSA無法偽造。
V2 ：7.0新增的
簽名後的包會被分為四部分
1. Contents of ZIP entries（from offset 0 until the start of APK Signing Block）
2. APK Signing Block
3. ZIP Central Directory
4. ZIP End of Central Directory
新應用簽名方案的簽名信息會被保存在區塊2（APK Signing Block） 中， 而區塊1（ Contents of ZIP entries ）、區塊3（ ZIP Central Directory ）、區塊4（ ZIP End of Central Directory ）是受保護的， 在簽名後任何對區塊1、3、4的修改都逃不過新的應用簽名方案的檢查 。
V3 ：9.0新增的
格式大體和 v2 類似，在 v2 插入的簽名塊（Apk Signature Block v2）中，又添加了一個新快（Attr塊） 。
在這個新塊中，會記錄我們之前的簽名信息以及新的簽名信息，以 密鑰轉輪的方案，來做簽名的替換和升級。這意味著，只要舊簽名證書在手，我們就可以通過它在新的 APK 文件中，更改簽名 。
v3 簽名新增的新塊（attr）存儲了所有的簽名信息，由更小的 Level 塊，以 鏈表 的形式存儲。
其中每個節點都包含用於為之前版本的應用簽名的簽名證書，最舊的簽名證書對應根節點，系統會讓每個節點中的證書為列表中下一個證書簽名，從而為每個新密鑰提供證據來證明它應該像舊密鑰一樣可信。
這個過程有點類似 CA 證書的證明過程，已安裝的 App 的舊簽名，確保覆蓋安裝的 APK 的新簽名正確，將信任傳遞下去。
注意： 簽名方式只支持升級不支持降級，如安裝了V2的包，不能覆蓋替換為V1的包。
參考
Android App簽名(證書)校驗過程源碼分析
新一代開源Android渠道包生成工具Walle
Android 簽名機制 v1、v2、v3
㈣ 如何將Android 源碼中編譯出的apk進行自己的簽名
1.將應用程序源碼復制進Android源碼目錄中(提前編譯好源碼)
2.使用build/envsteup.sh 配置shell -
mm TARGET_PRODUCT=proct_name
或直接./build_android.sh 也能完成編譯。
3.在源碼目錄：out/target/proct/proctname/obj/APPS/test_cert_intermediates 下有三個文件：package.apk package.apk.unsigned package.apk.unaligned
將package.apk.unsigned復制出來，單獨進行sign.
4.在Windows下進行sign: jarsigner -verbose -keystore youkey.keystore d:\package.apk.unsigned youkey
5.zipalign -v 4 d:\package.apk.unsigned d:\package.signed.apk
㈤ 如何用Android 源碼生成APK簽名文件
我們很多應用需要用到系統簽名，可以通過生成系統簽名文件，在生成apk時使用這個簽名，然後可以安裝到機器中，不需要放在源碼里編譯，重新刷系統。
先附上 50和 20機器人通用的debugkey(圖已經省略)
在Linux環境中，以Android源碼目錄為根目錄。
其中的platform.pk8是製作系統簽名需要的文件。
1、在這個目錄下，執行
生成臨時文件platform.pem
2、接著執行以下命令，將在目錄下生成platform.p12文件，它本質上應該就是一個數字證書
3、然後再執行以下命令出現以下信息，表示成功生成platform.jks
這個名字可以改成debug.keystore. 它的後綴本身是沒有關系，eclipse和AS都識別 platform.jks
4、然後在打包 apk 的時候選擇platform.jks文件，就可以直接用adb命令安裝apk到機器中了。
xxxx表示需要安裝的apk路徑
5、簽名的 Key store password和Key password都是android
㈥ android 系統簽名
也有提到怎麼單獨給一個apk簽名，這里補充一下android的簽名許可權控制機制。
android的標准簽名key有：
testkey
media
latform
hared
以上的四種，可以在源碼的/build/target/proct/security裡面看到對應的密鑰，其中shared.pk8代表私鑰，shared.x509.pem公鑰，一定是成對出現的。
其中testkey是作為android編譯的時候默認的簽名key，如果系統中的apk的android.mk中沒有設置LOCAL_CERTIFICATE的值，就默認使用testkey。
而如果設置成：
LOCAL_CERTIFICATE := platform
就代表使用platform來簽名，這樣的話這個apk就擁有了和system相同的簽名，因為系統級別的簽名也是使用的platform來簽名，此時使用android:sharedUserId="android.uid.system"才有用！
在/build/target/proct/security目錄下有個README，裡面有說怎麼製作這些key以及使用問題（android4.2）：
從上面可以看出來在源碼下的/development/tools目錄下有個make_key的腳本，通過傳入兩個參數就可以生成一對簽名用的key。
其中第一個為key的名字，一般都默認成android本身有的，因為很多地方都默認使用了這些名字，我們自定義的話只需要對第二個參數動手腳，定義如下：
C ---> Country Name (2 letter code) ST ---> State or Province Name (full name) L ---> Locality Name (eg, city) O ---> Organization Name (eg, company) OU ---> Organizational Unit Name (eg, section) CN ---> Common Name (eg, your name or your server』s hostname) emailAddress ---> Contact email addre
另外在使用上面的make_key腳本生成key的過程中會提示輸入password，我的處理是不輸入，直接enter，不要密碼！後面解釋，用自定義的key替換/security下面的。
可以看到android源碼裡面的key使用的第二個參數就是上面README裡面的，是公開的，所以要release版本的系統的話，肯定要有自己的簽名key才能起到一個安全控製作用。
在上面提到如果apk中的編譯選項LOCAL_CERTIFICATE沒有設置的話，就會使用默認的testkey作為簽名key，我們可以修改成自己想要的key，按照上面的步驟製作一個releasekey，修改android配置在/build/core/config.mk中定義變數：
在主makefile文件裡面：
ifeq ($(DEFAULT_SYSTEM_DEV_CERTIFICATE),build/target/proct/security/releasekey)
BUILD_VERSION_TAGS += release-key
這樣的話默認的所有簽名將會使用releasekey。
修改完之後就要編譯了，如果上面的這些key在製作的時候輸入了password就會出現如下錯誤：
我在網上找到了合理的解釋：
其實會出現這個錯誤的最根本的原因是多線程的問題。在編譯的時候為了加速一般都會執行make -jxxx，這樣本來需要手動輸入密碼的時候，由於其它線程的運行，就會導致影響當前的輸入終端，所以就會導緻密碼無法輸入的情況！
再編譯完成之後也可以在build.prop中查看到變數：
這樣處理了之後編譯出來的都是簽名過的了，系統才算是release版本
我發現我這樣處理之後，整個系統的算是全部按照我的要求簽名了。
網上看到還有另外的簽名release辦法，但是應該是針對另外的版本的，借用學習一下：
make -j4 PRODUCT-proct_mol-user dist
這個怎麼跟平時的編譯不一樣,後面多了兩個參數PRODUCT-proct_mol-user 和 dist. 編譯完成之後回在源碼/out/dist/目錄內生成個proct_mol-target_files開頭的zip文件.這就是我們需要進行簽名的文件系統.
我的proct_mol 是full_gotechcn,後面加「-user」代表的是最終用戶版本，關於這個命名以及proct_mol等可參考http://blog.csdn.net/jscese/article/details/23931159
編譯出需要簽名的zip壓縮包之後，就是利用/security下面的准備的key進行簽名了：
./build/tools/releasetools/sign_target_files_apks -d /build/target/proct/security out/dist/full_gotechcn-target_files.zip out/dist/signed_target_files.zi
簽名目標文件 輸出成signed_target_files.zi
如果出現某些apk出錯，可以通過在full_gotechcn-target_files.zip前面加參數"-e =" 來過濾這些apk.
然後再通過image的腳本生成imag的zip文件，這種方式不適用與我目前的工程源碼，沒有做過多驗證！
Android簽名機制可劃分為兩部分：（1）ROM簽名機制；（2）第三方APK簽名機制。
Android APK實際上是一個jar包，而jar包又是一個zip包。APK包的簽名實際上使用的是jar包的簽名機制：在zip中添加一個META的子目錄，其中存放簽名信息；而簽名方法是為zip包中的每個文件計算其HASH值，得到簽名文件(*.sf)，然後對簽名文件(.sf)進行簽名並把簽名保存在簽名塊文件(*.dsa)中。
在編譯Android源碼生成ROM的過程中，會使用build/target/proct/security目錄中的4個key（media, platform, shared, testkey）來對apk進行簽名。其中，*.pk8是二進制形式（DER）的私鑰，*.x509.pem是對應的X509公鑰證書（BASE64編碼）。build/target/proct/security目錄中的這幾個默認key是沒有密碼保護的，只能用於debug版本的ROM。
要生成Release版本的ROM，可先生成TargetFiles，再使用帶密碼的key對TargetFiles重新簽名，最後由重簽名的TargetFiles來生成最終的ROM。
可以使用Android源碼樹中自帶的工具「development/tools/make_key」來生成帶密碼的RSA公私鑰對（實際上是通過openssl來生成的）: $ development/tools/make_key media 『/C=CN/ST=Sichuan/L=Cheng/O=MyOrg/OU=MyDepartment/CN=MyName』 上面的命令將生成一個二進制形式（DER）的私鑰文件「media.pk8」和一個對應的X509公鑰證書文件「media.x509.pem」。其中，/C表示「Country Code」，/ST表示「State or Province」，/L表示「City or Locality」，/O表示「Organization」，/OU表示「Organizational Unit」，/CN表示「Name」。前面的命令生成的RSA公鑰的e值為3，可以修改development/tools/make_key腳本來使用F4 (0×10001)作為e值（openssl genrsa的-3參數改為-f4）。
也可以使用JDK中的keytool來生成公私鑰對，第三方APK簽名一般都是通過keytool來生成公私鑰對的。
可以使用openssl x509命令來查看公鑰證書的詳細信息： $ openssl x509 -in media.x509.pem -text -noout or, $ openssl x509 -in media.x509.pem -inform PEM -text -noout
還可以使用JDK中的keytool來查看公鑰證書內容，但其輸出內容沒有openssl x509全面： $ keytool -printcert -v -file media.x509.pem
有了key之後，可以使用工具「build/tools/releasetools/sign_target_files」來對TargetFiles重新簽名： $ build/tools/releasetools/sign_target_files_apks -d new_keys_dir -o target_files.zip target_files_resigned.zip 其中，new_keys_dir目錄中需要有四個key（media, platform, shared, releasekey）。注意：這里的releasekey將代替默認的testkey（請參考build/tools/releasetools/sign_target_files腳本實現），也就是說，如果某個apk的Android.mk文件中的LOCAL_CERTIFICATE為testkey，那麼在生成TargetFiles時是使用的build/target/proct/security/testkey來簽名的，這里重新簽名時將使用new_keys_dir/releasekey來簽名。
uild/tools/releasetools/sign_target_files_apks是通過host/linux-x86/framework/signapk.jar來完成簽名的。也可以直接使用host/linux-x86/framework/signapk.jar來對某個apk進行簽名： $ java -jar signapk [-w] publickey.x509[.pem] privatekey.pk8 input.jar output.jar 其中，」-w」表示還對整個apk包(zip包）進行簽名，並把簽名放在zip包的comment中。
對於第三方應用開發者而言，對APK簽名相對要簡單得多。第三方應用開發一般採用JDK中的keytool和jarsigner來完成簽名密鑰的管理和APK的簽名。
使用keytool來生成存儲有公私鑰對的keystore： $ keytool -genkey -v -keystore my-release-key.keystore -alias mykey -keyalg RSA -keysize 2048 -validity 10000
查看生成的密鑰信息： $ keytool -list -keystore my-release-key.keystore -alias mykey -v or, $ keytool -list -keystore my-release-key.keystore -alias mykey -rfc （註：獲取Base64格式的公鑰證書，RFC 1421）
導出公鑰證書： $ keytool -export -keystore mystore -alias mykey -file my.der （註：二進制格式公鑰證書，DER） $ keytool -export -keystore mystore -alias mykey -file my.pem -rfc （註：Base64格式公鑰證書，PEM）
對APK進行簽名： $ jarsigner -verbose -keystore my-release-key.keystore my_application.apk mykey
驗證簽名： $ jarsigner -verify -verbose -certs my_application.apk
在進行Android二次開發時，有時需要把build/target/proct/security下面的公私鑰對轉換為keystore的形式，可以參考這篇文章：把Android源碼中的密碼對轉換為keystore的方法。
㈦ Android8.1源碼下對APK進行系統簽名
在Android8.1上面繼續參考http://blog.sina.com.cn/s/blog_3e4774e30101e1y5.html這凳神森篇文章來對APK進行Android系統源碼環境下的簽名，發現簽棗畝名時出現如下錯誤：
查了下資料，需要將命令由如下：瞎羨
修改為：
參考資料：https://ask.csdn.net/questions/684938
㈧ Android系統簽名
有時候，我們開發的apk需要用到系統許可權，需要在AndroidManifest.xml中添加共享系統進程屬性：
這時候apk的簽名就需要是系統簽名(platform、shared或media)才能正常使用。
常用系統簽名方式
這種方式比較麻煩，你需要有編譯過的源碼環境，並按如下步驟：
1、拷貝App源碼到Android源碼的packages/apps/目錄下，且App源碼是普通(Eclipse)格式的
2、配置Android.mk，在其中添加
3、使用mm編譯App，生成的apk即系統簽名
這種方式比在源碼環境下簽名簡單，App可以在Eclipse或Android Studio下編譯，然後給apk重新簽名即可。
但這種方式在頻繁調試的時候比較痛苦，即使寫成腳本，也需要重復一樣的操作。
相關文件
platform.x509.pem、platform.pk8、signapk.jar
文件位置
platform.x509.pem、platform.pk8:
signapk.jar:
signapk源碼路徑:
簽名命令
步驟
1、將相關文件及源apk文件置於同一路徑下
2、檢查源apk包，去掉META-INF/CERT.SF 和 META-INF/CERT.RSA 文件
3、執行簽名命令即可
讓Android Studio集成系統簽名，需要用到一個工具 keytool-importkeypair ，詳見下文。
這個工具的作用是將系統簽名的相關信息導入到已有的簽名文件里。
工具的使用方法可以通過–help或README.textile來尋求幫助
platform.x509.pem、platform.pk8、keytool-importkeypair、demo.jks、signature.sh
我的做法是在App根目錄新建Signature文件夾專門存放簽名相關文件。
步驟
1、生成demo.jks簽名文件
2、編寫簽名腳本signature.sh，內容如下：
為腳本文件添加可執行許可權：
執行腳本：
3、配置builde.gradle
在android區域下(與defaultConfig同級)添加配置：
這樣debug或release apk就帶有系統簽名了。
如果想直接Run app就是release版且帶系統簽名的apk，還需修改：
這樣直接Run app就是帶系統簽名的release版apk了。
㈨ Android apk 系統簽名
因工作需要對系統的wifi和乙太網進行配置，需要獲取友螞春到系統許可權以後才能進行操作，因此研究了物哪下對apk 進行系統簽名以獲取系統許可權，其實本來打算如果root可以的話直接通過root的方式（設備已經root），後來找了半天發現沒有api進行修改，無奈只能進行系統簽名了，有童鞋知道root方式修改不妨告訴我一下。
這些文件可以問系統廠商獲取，如果是原生系統可以到系統源碼目錄下獲取。
如果報以下的錯誤 ,這時候就用到准備的libconscrypt_openjdk_jni.so 文件
為了檢測我們的應用是否已經簽名成功 可以獲取系統許可權，看看能否獲取到。
結果:
在上一種方式中，我們成功對我們的apk進行了系統簽名，並且能使用系統許可權，但是必須每次打包出apk再進行簽名 對調試很不方便，下面我們可以生成帶有系統簽名的簽名文件，在項目中使用，就不需要每次手動進行簽名。
bubble可以替換為自己喜歡的名稱,這一步要輸入密碼，我嘗試輸入其他好耐不行，只能輸入android。
bubble 可替換為自己喜歡的password和alias
到這里 兩種對app進行系統簽名的方式完成，如有不足，歡迎指出.
㈩ 如何讓應用程序獲得系統許可權以及如何使用platform密鑰給apk簽名
Android中許多函數只能是系統程序或者有root許可權的程序才可以調用，否則會有"Permission denied"異常。所以如果開發時要調用此類函數，必須授予程序root許可權。下面是兩種具體的實現方法
註：兩種方法都不一定適用於所有android系統。
方法一：需要在清掘Android系統源碼的環境下用make來編譯：
在應用程序的 AndroidManifest.xml 中的 manifest 節點中加入 android:sharedUserId="android.uid.system" 這個屬性
修改Android.mk文件，加入LOCAL_CERTIFICATE := platform這一行
使用mm命令來編譯，生成的apk就有修改系統時間的許可權了。
方法二：
同上，加入android:sharedUserId="android.uid.system"這個屬性。
使用eclipse編譯出apk文件，但是這個apk文件是不能用的。
用壓縮軟並漏件打開apk文件，刪掉META-INF目錄下的CERT.SF和CERT.RSA兩個文件。 （這一步我跳過了（原本是無意的，後來發現下面也有提到），結果一樣可以）
使
用目標系統的platform密鑰來重新給apk文件簽名。這步比較麻煩，首先找到密鑰文件，在Android源碼目錄中的位置
是"build\target\proct\security"，下面的platform.pk8和platform.x509.pem兩個文件。然
後用Android提供的Signapk工具來簽名，signapk的源代碼是在"build\tools\signapk"下，用法為"signapk
platform.x509.pem platform.pk8 input.apk
output.apk"，文件名最好使用絕對路徑防止找不到，也可以修改源代碼直接使用。
<此時這樣最後得到的apk和第一個方法是一樣的>
解釋一下原理，首先加入
android:sharedUserId="android.uid.system"這個屬性。通過Shared User id,擁有同一個User
id的多個APK可以配置成運行在同一個進程中。那麼把程序的UID配成android.uid.system，也就是要讓程序運行在系統進程中，這樣就
有許可權來調用那些需要系統許可權的函數了。 只是加入UID還不夠，如果這時候答蔽核安裝APK的話發現無法安裝，提示簽名不符，原因是程序想要運行在系統進程中
還要有目標系統的platform
key，就是上面第二個方法提到的platform.pk8和platform.x509.pem兩個文件。用這兩個key簽名後apk才真正可以放入系
統進程中。第一個方法中加入LOCAL_CERTIFICATE := platform其實就是用這兩個key來簽名。
有一個問題，就是這樣生成的程序只有在原始的Android系統或者是自己編譯的系統中才可以用，因為這樣的系統才可以拿到
platform.pk8
和platform.x509.pem兩個文件。要是別家公司做的Android上連安裝都安裝不了。試試原始的Android中的key
來簽名，程序在模擬器上運行OK，不過放到G3上安裝直接提示"Package ... has no signatures that match
those in shared user android.uid.system"，這樣也是保護了系統的安全。
最後說一下，這個android:sharedUserId屬性不只可以把apk放到系統進程中，也可以配置多個APK運行在一個進程中，這樣可以共享數據，應該會很有用的。