別讓應用簽名問題拖了審核的後腿

2022-03-27 18:24:51 字數 1645 閱讀 2483

相信很多開發者肯定遇到過由於簽名的問題導致應用審核被拒的情況,比如:

新版本和在架版本簽名不一致

整合hms的相關服務如push失敗,map地圖載入不出來,原因是證書指紋不匹配

應用上架後,不同渠道應用更新不了,提示簽名不一致

等等要解決這些疑問,先要了解什麼是應用簽名?

簽名很重要,應用必須要有簽名,沒有簽名不讓上架。

簽名不能變,一旦變了,很多東西全亂套了,證書指紋會變,鑑權會變,應用更新不了等。反正依賴簽名的很多服務都無法使用。

所以一般開發者在開發應用的時候都會使用android studio或者命令的方式給應用簽名。

而agc應用簽名服務是幹嘛的呢?說白了就是agc提供了另一種給你的應用簽名的方式!

一共有兩種方式:

第一種是agc完完全全給你的應用生成新簽名。簽名一定會改變,而且是宇宙唯一的。

對應介面叫做:「讓 ag connect 建立並管理我的應用簽名金鑰」

為什麼僅適用於新應用呢?剛剛前面講到,這種方式agc會給你生成乙個新的簽名,如果你已經有在架應用,那使用這種方式不可能生成乙個和在架應用一樣的簽名了,所以當然用不了。

第二種是你自己上傳簽名檔案,agc不會給你生成新的簽名,只是使用你上傳的簽名檔案給你的應用簽名。至於新的簽名是什麼,取決於你上傳了什麼,agc只是保管一下。對應介面叫做:「匯出並上傳金鑰和證書」

就是說你自己使用某個工具和命令把你的簽名匯出成乙個zip包的簽名檔案,然後上傳到agc,agc用這個簽名檔案給你應用簽名。所以你要是有在架應用的話,一定要傳乙個和在架應用一樣的簽名檔案,否則你的應用最終新老版本簽名就不一致了。

值得注意的是,目前這種方式已經支援校驗能力,如果傳的簽名和在架版本不一樣就會提示,且不允許上傳。

舉個例子,你有一款應用,自己本地用android studio簽名的,假設應用的簽名是a,然後你使用了agc的應用簽名服務,選擇第一方式,那agc會生成乙個新的簽名b,你的應用上架審核和最終發布時簽名就被改成b了。所以很可能你本地測試時簽名是a,審核測試時應用的簽名是b。

如果你選擇第二方式,你需要傳乙個zip的簽名檔案,如果zip檔案是通過是簽名a生成的,最終你的應用上架審核和發布時簽名就是a;如果是b生成的,簽名就是b;是c生成的,簽名就是c。反正就是你傳啥最終簽名就是啥。

所以小夥伴千萬不要選錯了,也不要傳錯了。那應該怎麼選擇呢?其實也很簡單。

一般來說,新應用如果只考慮在華為上架那就選第一種方式;如果要在多個渠道商店上架,那就選第二種方式,並且上傳和其他商店一樣的簽名檔案。如果有些鑑權支付等服務依賴簽名,那就選第二種方式。

已上架應用的話只能選第二種方式了,只要保證你傳的簽名檔案和在架版本一樣就可以。

講到這裡,再回到最初的問題就知道很可能是選錯了簽名方式,或者傳錯了簽名檔案導致應用簽名被改變了。遺憾的是簽名服務一旦使用不支援刪除,當前的解決方案只能是通過刪除應用來刪除簽名,然後重新建立應用,選擇正確的簽名方式、上傳正確的簽名檔案。

題外話:

應用簽名≠應用簽名服務;簽名是必須的,應用簽名服務是可選的。

apk包可以選用應用簽名服務,aab包必須要用。

簽名變了,對應證書指紋也會改變,依賴的服務需要配置新的證書指紋。

黑客攻擊成常態 別讓安全拖了上雲的後腿

如今,上雲與否早已不是選擇題。在企業實現數位化轉型的過程中,雲計算的重要性不言而喻。對於cio來說,關鍵任務變成了找到適合的雲服務商,並且根據自身業務特性逐步遷移到雲端。不過隨著業務加速雲化,一些企業的安全團隊卻仍然停留在原有的思維定式,忽視了對新業務部署時的風險控制,這種威脅不僅是在應用層,還有架...

製造企業 別讓網際網路拖了你的後腿!

20年前,幼小網際網路火種如看不見的幽靈一般悄悄潛入了正值發展高峰期的中國。20年後,當年的種子如今已長成參天大樹,網際網路已經成了人們不可或缺的一部分,成為了人們的左右手。20年前,當所有人都在熱衷開工廠的時候,馬雲開始琢磨搞網際網路。20年後,當所有人都在熱衷搞網際網路的時候,馬雲又開始大刀闊斧...

檢視應用簽名和手動簽名

我們在使用一些第三方時需要提 用簽名,如果我們想要獲得簽名檔案的指紋,我們可以在cmd中輸入如下命令 keytool list v keystore 簽名檔案路徑 然後輸入正確的密碼就可以了。其結果如下所示 證書指紋 md5 a3 f4 03 25 6f ae 01 e9 53 f1 86 36 a...