如果您是Google Play稽核團隊App機審策略規則的制定者，讓您去設計一套App機審系統，你會如何設計呢？
阿文從事出海行業多年，斗膽講講自己對Google Play App機審策略的理解，不足之處，還請大家多多海涵和不吝賜教。
先po一張思維導圖，希望能在App機審策略規則方面給予各位一些啟發，做好違規預防工作，而不是有了違規問題再去解決，從而使我們工作很被動。
原始檔可私信小編獲取，底部圖片長按掃碼新增！
正文來了
從我們提交aab檔案到預稽核透過，您的aab檔案就進入GP稽核系統開始排隊了。Google稽核系統會分析我們的aab檔案，對程式碼和UI介面進行機器稽核，尤其是對程式碼部分，而靜態分析和動態分析為其稽核重點，大多程式碼關聯，惡意軟體，程式碼違規都在這一階段完成。所以，這一步也是我們順利上架和版本更新迭代的重中之重。
App程式碼機審
1
aab檔案靜態分析
(1) Hash值比對：在App防逆向工作中，透過對App全量檔案提取Hash值，並遵循某種規則計算加密儲存。然後在App執行時提取App檔案，按照相同規則計算，將Hash值進行全量比對，來預防惡意程式纂改App。所以，猜測 Google大機率也會透過類似手段來初步計算我們App和其他違規App的檔案相似度來作為賬號關聯的特徵點。大家一定注意，如果一個檔案只改名字是不會改變Hash值的！
(2) 簽名檔案：使用同一個簽名檔案來簽名不同的App萬萬不可，尤其使用之前違規的App簽名。
(3) Manifest資訊：Google會檢測我們的Manifest內容（各種配置資訊）是否合規。而且，對於馬家堡而言，往往他們的Manifest檔案會相當類似，這一點肯定會影響我們的稽核。
(4) 資原始檔（Res，Assets）：資原始檔內容是否違規，圖片內容是否侵權，字串內容是否符合App內容分級等等，Google都會稽核。資原始檔是否與違規 App 重複度過高也是稽核的重點，比對方式可參考第一點。對於遊戲產品而言，素材的稽核會更嚴格。
(5) Dex檔案：Dex檔案節區資訊和功能程式碼是機審的重點。想要理解Dex檔案節區資訊，必須要學習Dex檔案格式的構成，可以簡單理解為標頭檔案(header)、索引區(xx_ids)、資料區(data)，有興趣的自己可以查查。功能程式碼是程式碼審查的最關注點，程式碼是否和歷史違規程式碼重複度過高，是否有惡意程式碼Google都會審查。
(6) SO檔案：SO的理解也需要了解些逆向知識，SO（ELF）檔案節區資訊和匯出函式猜測會是Google稽核的方向。很多SDK都會將C++程式碼生成SO檔案，所以對於SDK的選擇就很重要，千萬不要選擇有風險的SDK用於我們的專案。
Google Play透過對App包檔案進行一系列操作審查，最終得到一個多關鍵資訊靜態分析特徵表，留做後續和Google後臺違規資料庫作對比。
2
執行時動態分析
靜態分析完成後，會進入稽核更為嚴格的動態分析階段，Google Play可能會透過把我們的aab在沙箱（虛擬執行環境）中模擬執行，來全面分析我們的App。
(1) Java/Kotlin/Flutter/Compose Api呼叫鏈：不管我們用什麼程式碼開發，都將執行在Java虛擬機器上，都會轉變為java位元組碼檔案，Google會審查我們的Api呼叫鏈來確定我們是否使用了違規或者過時的Api，程式碼是否存在風險漏洞，也會審查我們與其他違規App的程式碼重複度。
(2) SO檔案 C++程式碼 Api呼叫鏈：和Java Api同理，所以我們在開發中儘量使用自行開發的SDK，儘量不使用小公司SDK或者任何可能有風險的SDK，也強烈建議不要直接使用小的三方開源庫，如果其程式碼不規範或者被其他的違規的App使用過，就非常有可能影響我們。
(3) Activity，Fragment堆疊（全路徑）資訊：介面例項資訊都會儲存在堆疊中，這一步重點檢查我們和其他違規App的程式碼重複度問題，也是有可能導致關聯問題的特徵點。
(4) App建立的目錄檔案：這一點往往會被很多人忽視，尤其是在開發馬家堡的過程中，App內部自行建立的目錄檔名是非常容易被審查併產生關聯的問題之一。
(5) 網路行為（與後端互動）：不僅僅App 程式碼本身，我們和後端的互動也是審查的重點之一，域名，Path路徑，Json結構如果和違規App產品關聯，也非常容易被處罰甚至被關聯封號。
(6) 日誌分析：細節決定成敗，日誌列印的節點，資訊，檢索Key也是非常容易忽視的點。如果兩個不同包名的App，Google將日誌列印開啟後列印的Log非常相似，我想會很容易被認定為關聯。
Google Play在模擬執行App後，最終得到一個多關鍵資訊動態分析特徵表，留做後續和Google後臺違規資料庫作對比。
UI介面
一句話總結，Google Play會在模擬執行App過程中，對每一個介面進行截圖，然後與Google強大的後臺違規資料庫作對比，來確定您的App是不是和其他違規App相似，是否和違規App存在關聯，介面元素是否侵犯產權等等。
敲黑板了
這麼多複雜的特徵點提取之後，靜態分析特徵表，動態分析特徵表，UI介面會分別和Google強大的後臺違規資料庫作對比，檢索您的App是否和違規App關聯，是否是惡意軟體，是否存在違規，最終輸出一個閾值判斷是否可以過審或者給予其他更嚴重的懲罰。
再次宣告，以上均是本人對Google Play程式碼機審策略規則的一點點猜想， 不足之處，還請大家多多海涵和不吝賜教。Google真實的機審肯定無比龐大和嚴格，值得我們後續持續研究。
最後衷心地祝願大家的App都能一次過審，業務開展順風順水。
END
更多出海內容，煩請關注下方公眾號哈。長按圖片新增小編企V，獲取更多出海解決方案和加入我的出海交流群，一起交流學習。
期待您“點贊，分享和在看” 哦 👇
關鍵詞
資訊
問題
資原始檔
Google Play