1. android開發微信支付集成客戶端二次簽名怎麼做
1.客戶端代碼得到用戶購買的商品信息，將之傳給自己公司app伺服器，參數包含但不限於以下：
params.put("appid", appID);// 微信appid，選擇性上傳，伺服器寫死亦可
params.put("money", money);// 支付金額，單位：分
params.put("name", goodsName);// 商品名稱
params.put("currencytype", "CNY");// 支付幣種，只能填CNY，代表人民幣12341234
備註：以上是參數欄位是我們公司伺服器定義，給伺服器用以獲取預支付訂單號prePayId用。
備注2：詳細欄位請參考：https://pay.weixin.qq.com/wiki/doc/api/app/app.php?chapter=9_1
2.app伺服器調用微信「統一下單」介面，得到prePayId訂單號並返回prePayId給手機客戶端；
3.手機客戶端使用prePayId及商品信息調起微信客戶端進行支付；
3.1用戶操作：輸入密碼進行支付；返回鍵取消支付；網路無連接支付失敗等；
4.微信客戶端回調支付結果給咱們的APP客戶端；
5.微信伺服器非同步通知咱們公司app伺服器支付結果（伺服器的工作，與客戶端無關）
這個其實很簡單的，demo文檔寫得很詳細，直接上代碼吧：
/**
* 獲取sign簽名
*
* @return
*/
private String genPayReq() {
// 獲取參數的值
PayReq request = new PayReq();
request.appId = ConstantsMember.APP_ID;
request.partnerId = ConstantsMember.MCHID;
request.prepayId = mPrepayId;
request.packageValue = "Sign=WXPay";
request.nonceStr = DataUtil.getGuid();
request.timeStamp = DataUtil.getTimeStamp();
// 把參數的值傳進去SortedMap集合裡面
SortedMap<Object, Object> parameters = new TreeMap<Object, Object>();
// {appid=wx34df375d7dae8c90, noncestr=,
// package=Sign=WXPay, partnerid=1349967601,
// prepayid=, timestamp=1468031760}
parameters.put("appid", request.appId);
parameters.put("noncestr", request.nonceStr);
parameters.put("package", request.packageValue);
parameters.put("partnerid", request.partnerId);
parameters.put("prepayid", request.prepayId);
parameters.put("timestamp", request.timeStamp);
String characterEncoding = "UTF-8";
String mySign = createSign(characterEncoding, parameters);
System.out.println("我的簽名是：" + mySign);
return mySign;
}
/**
* 微信支付簽名演算法sign
*
* @param characterEncoding
* @param parameters
* @return
*/
public static String createSign(String characterEncoding,
SortedMap<Object, Object> parameters) {
StringBuffer sb = new StringBuffer();
Set es = parameters.entrySet();// 所有參與傳參的參數按照accsii排序（升序）
Iterator it = es.iterator();
while (it.hasNext()) {
@SuppressWarnings("rawtypes")
Map.Entry entry = (Map.Entry) it.next();
String k = (String) entry.getKey();
Object v = entry.getValue();
if (null != v && !"".equals(v) && !"sign".equals(k)
&& !"key".equals(k)) {
sb.append(k + "=" + v + "&");
}
}
sb.append("key=" + ConstantsMember.KEY); //KEY是商戶秘鑰
String sign = MD5Util.MD5Encode(sb.toString(), characterEncoding)
.toUpperCase();
return sign; //
//
}
2. android apk可以重復簽名嗎
由於APK文件有簽名機制，因此如果之前的APK和現在APK的簽名不一致，就會在你覆蓋安裝舊版軟體的時候出現無法安裝的情況。這時需要先卸載才能安裝新版的軟體。
3. android防止二次打包，校驗簽名signature時，校驗公鑰有什麼用
有必須的哦，通過公鑰的對比可以發現這個apk是否是被二次打包，一般會把公鑰的md5或者是sha1值計算出來放在程序中，然後程序運行的時候計算當前程序的md5，然後進行比較。
上段代碼：
public static int checkAppSignature(Context context) {
String SIGNATURE = "478yYkKAQF+KST8y4ATKvHkYibo=";//需要固定寫在程序的某個位置的簽名
try {
PackageInfo packageInfo = context.getPackageManager().getPackageInfo(context.getPackageName(), PackageManager.GET_SIGNATURES);
Signature[] signatures = packageInfo.signatures;
Signature sign = signatures[0];
MessageDigest md = MessageDigest.getInstance("SHA");
md.update(sign.toByteArray());
Log.e("proyx", bytesToHexString(md.digest()));
final String currentSignature = Base64.encodeToString(md.digest(), Base64.DEFAULT);
Log.e("proyx", "Include this string as a value for SIGNATURE:" + currentSignature);
if (SIGNATURE.equals(currentSignature)) {
return 0;
}
} catch (Exception e) {
//assumes an issue in checking signature., but we let the caller decide on what to do.
e.printStackTrace();
}
return 1;
}
4. Android 如何加密java文件 防止軟體二次簽名打包和反編譯
有些做加固的公司，可以給應用加固，增加反編譯的難度
5. 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了。
6. 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
7. 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的方法。
8. android防止二次打包，校驗簽名signature時，校驗公鑰有什麼用
有必須的哦，通過公鑰的對比可以發現這個apk是否是被二次打包，一般會把公鑰的md5或者是sha1值計算出來放在程序中，然後程序運行的時候計算當前程序的md5，然後進行比較。
上段代碼：
public static int checkAppSignature(Context context) {
String SIGNATURE = "478yYkKAQF+KST8y4ATKvHkYibo=";//需要固定寫在程序的某個位置的簽名
try {
PackageInfo packageInfo = context.getPackageManager().getPackageInfo(context.getPackageName(), PackageManager.GET_SIGNATURES);
Signature[] signatures = packageInfo.signatures;
Signature sign = signatures[0];
MessageDigest md = MessageDigest.getInstance("SHA");
md.update(sign.toByteArray());
Log.e("proyx", bytesToHexString(md.digest()));
final String currentSignature = Base64.encodeToString(md.digest(), Base64.DEFAULT);
Log.e("proyx", "Include this string as a value for SIGNATURE:" + currentSignature);
if (SIGNATURE.equals(currentSignature)) {
return 0;
}
} catch (Exception e) {
//assumes an issue in checking signature., but we let the caller decide on what to do.
e.printStackTrace();
}
return 1;
}