Google Play開發者賬號被封，相關問題彙總以及解決方案探索

選自 Eva資料

最近又有賬號被關聯了，這次關聯和以往不一樣，現在還在申訴，對申訴結果沒有過多的期待。經過這一次，決定重新梳理一遍賬號關聯問題。希望通過慘痛的教訓，能給面臨同樣問題的開發者提供一些解決思路。

時間線：

- 5月6日，APP稽核通過釋出上架；

- 5月14日，版本更新；

- 5月19日，版本更新；

- 5月19日，開始針對APP進行付費功能對接；同時提交第一個測試賬號A；

- 5月21日，後臺新增第二個測試賬號B；

- 5月22日，開發者賬號關聯被封；

這次最後的判斷是，測試賬號導致開發者賬號關聯；測試賬號A和B都不曾是開發者賬號，但是都曾經在使用過被封開發者賬號的手機上登入。特別B賬號，提交測試時，常用裝置之一依然登入著過去被封的開發者賬號。正是因為這次對測試賬號的大意，導致賬號被封。這次開發者賬號上的APP無任何違規，是純粹的工具類APP，包括裡面的廣告點都是非常乾淨的。在賬號被封之前，沒有收到過下架或者違規警告。

經過這幾天的總結，重新梳理開發者賬號相關的內容。對此次因為測試賬號導致封號更加確定。大家看下圖：


重點關注標記的位置；Google的關聯關係，目前公認的判定者是機器。也就是谷歌通過機器演算法，針對開發者賬號的各種資訊和行為進行對比，然後根據對比結果來判定是否是關聯賬號。

如果大家對評分卡有一定的瞭解，那麼可以把Google的這個判定規則比做一套評分卡系統，簡單的理解就是機器通過對開發者賬號相關的各種欄位與黑名單庫進行對比。然後每一個欄位都會有具體的分值。當分值超過某一個值時，就判定為關聯賬號。而這其中，有一些欄位，單獨命中就會直接得到較高的分值。從而確定賬號關聯關係。（這是一種假設，實際的系統應該比這複雜很多）

對於較高分值的欄位，目前的判斷是：裝置相關，付款/收款相關，主動關聯資訊。

1、裝置相關

這一塊不用多說，有很多介紹的文章。很多開發者都有在本地電腦登入開發者賬號導致封號的經歷（前提是本地電腦曾經登入過被封賬號）。我們曾經嘗試過重置系統，清除快取等策略。但是依然有中招的，後來就不敢再驗證了（成本太高，而且無法確定是什麼規則導致了關聯），後來就直接採用VPS伺服器的方式進行。這也是目前避免賬號關聯的基礎操作。

裝置這塊，VPS伺服器已經是最好的解決方案了。當然，如果你只有唯一一個開發者賬號，而且從未有過違規記錄。還是可以在本地登入的，配備一個穩定的虛擬專用網路就沒有任何問題。

2、付款/收款相關

關於付款，指的是開通開發者計劃所支付的25刀所使用的付款卡，去年很多人都可以使用自己的信用卡支付（需要是VISA或Master），但是最近一段時間來，經常會出現支付失敗的情況，這個具體是什麼原因不得而知。我相信依然還是有很多是採用這種支付方式的，也是可以支付成功的。

如果是採用自己的卡支付，那麼卡相關的資訊已經被記錄了。如果使用同樣的卡支付其它的開發者賬號，那麼這個關聯關係是非常強的。如果讓我去制定賬號關聯關係，支付卡這一條資訊，肯定也是首選的。

為了避免這種情況，最好的辦法就是一個賬號對應一張卡。最好是每個賬號對應的人都是不一樣的。如果實在做不到，可以嘗試一個人不同卡進行支付。

其它還有找人代付或者是買卡。這塊這裡就不多說了。

收款卡，這一塊主要就是當你的APP有付費專案時，一定要慎重填寫。填寫的收款資訊一定要是乾淨的，可以使用自己的收款卡。關於如何收款，有相關的介紹文章，大家可以前往檢視（如何設定收款銀行卡）。這裡不再贅述。

這裡的原則就是，不同開發者賬號，收款資訊分開。不要混用。

3、主動關聯資訊

不知道大家是否注意到，開發者賬號可以主動關聯AdMob，Google Analytics，Firebase這些平臺，還有就是新增測試賬號這些內容。假設你沒有主動關聯的時候，谷歌也知道你所使用的這些賬號。但是它不會非常確定說你們是一起的，當你主動關聯的時候。它的規則就明確說，你們是一起的！

假設你有一個AdMob賬號，之前給某一個APP對接廣告，後來這個APP違規被下架了，然後APP對應的開發者賬號被封了。這個時候，重新做了一個APP，對接的依然是這個AdMob賬號，新的APP被關聯的情況是多大呢？當在新App對應的開發者賬號後臺關聯了此AdMob賬號，這是不是直接主動告訴了Google你們是同一個人？我想這個時候，谷歌的機器肯定是要把這個賬號關閉掉！

總結

圖中列出的欄位，在申請開發者賬號的時候，最好是做到徹底獨立，與過往有黑歷史的賬號區別開來。想要真正搞清楚谷歌的判定規則，是非常難的。而且在不同的時候，判斷規則也會有所側重。同樣的遊戲APP、金融APP、工具APP也會有不一樣的判定，具體還需要開發者通過經驗不斷的摸索。

對於開發者來說，最大的問題就是被判定關聯，直接封號，沒有任何的機會（如果有開發者申訴成功了，可以留言給大家分享下經驗），這才是我們不能接受的。也就是很多時候都不知道自己是怎麼死的，唯有慎重才能降低被關聯的風險。

以上這些內容，希望能給大家帶來幫助，如果大家有同樣的情況也可以互相交流。對於開發者來說，要在Google Play平臺上釋出應用，需要遵守他們的規則。如果因為觸犯規則導致賬號被封，那就得不償失了。

在谷歌目前的機器規則下，你一次是壞人，那麼永遠就是壞人，把曾經違規的賬號相關資訊永遠封存，不再用於新的開發者賬號中是最優策略。不知道谷歌開發者黑名單有沒有有效期的這種說法，如果有不知道是2年還是5年。可是對於開發者來說，肯定是沒有任何成本或時間去試探和等待的。

今天分享這些內容，一方面是對遇到情況的一些分析總結。另外也是對Google Play開發者政策的一種解讀。Google也許是大的公司，但是在開發者規則這一塊，做法明顯是不如IOS的。谷歌的政策稽核工作，大量是通過一臺寫著無數規則的機器執行的，面對機器，機械式的應對是最有效的。

【擴充套件閱讀】谷歌應用市場上架(開發者賬戶關聯)相關問題彙總以及解決方案

選自 知乎 賈Sir

目前網際網路公司出海做業務的時候，必須要跨過的2座大山就是Facebook和Google. Facebook掌管著全世界優質的使用者流量, Google掌管著app的上架入口。而其中Google Play 的 app上架則是出海要解決的第一個問題。我會用幾篇文章一一說明下上架過程中遇到的問題以及解決辦法.

上架流程

開發者賬戶註冊到上架的流程包括哪些?


為了app的安全穩定的上架，上面是我總結的app的整個的上架流程.

首先先說一下遠端vps(遠端虛擬主機)的事情。

購買遠端vps的目的是為了規避上架操作環境(ip 電腦mac地址 瀏覽器cookie等資訊)和其他開發者帳號關聯。那麼我們要去哪裡採購這種vps呢?

有這麼幾種方式: 大廠vps(阿里雲, aws) ，小廠vps，自建/私有機房

當然鑑於自身條件和投入成本的話，大部分人還是選擇的使用大廠的vps. 如果你有資源優勢的話，自建機房搭建vps是最安全的，當然維護成本一般人承受不起。

然後說一下賬戶是自己註冊還是購買的問題。

自己註冊開發者帳號的話，為了避免關聯，自己要提前準備好完全新的資料，信用卡和vps環境(具體教程大家自己去百度好了，一大把)。這裡有個小祕訣，開發者帳號註冊完畢後，等個2-3天再上傳app。如果在上傳app之前開發者帳號就被關聯封號的話，這說明你註冊過程中就有關聯的因素沒處理好，這樣就省的浪費剛弄好的app包了。

稍微提醒大家的就是， 如果是自己註冊賬號一定要多看看，多問問，保證環境乾淨，遇到問題別慌，記住 我們要的是成功率，不是速度。

購買別人的賬戶的話，要找靠譜的渠道，賬戶需要是已經註冊了1個月以上的老賬戶，安全，穩定。

綜上，如果你有能力搞定全新的申請資料的話，那建議自己註冊，如果你沒有，那麼建議還是找渠道，至於怎麼找，你懂的.

賬戶關聯是指什麼?可能的關聯點有哪些?

賬戶關聯是指gg識別到你的多個app可能是類似的馬甲包或者上包環境可能是相同環境, 會一擼到底的全部下架,封號. 讓你之前所有的努力和辛苦，一夜之間灰飛煙滅，整個公司的業務都會停滯，嚴重的情況下，可能直接解散也不是不可能。。。

可能的關聯點:

(1) 後端介面: 介面的ip, 域名

(2) 上包環境: 遠端vps的ip, mac地址. gmail郵箱繫結的手機號, 開發者繫結的信用卡.

(3) 客戶端: 程式碼重複度大, UI類似.

如何避免關聯?

先針對上面的關聯點一一進行解釋，然後再針對性的看解決方案:

(1) 後端介面: ip要換新的, 域名也要換新的，更改介面結構, 加密資料傳輸

(2) 上包環境: 確保註冊開發者賬戶使用的信用卡和gmail郵箱沒人使用過或者沒有繫結過其他開發者賬戶. 也可以去購買現成的賬戶. (購買有風險, 需要仔細識別)

(3) 客戶端: 程式碼重複性因為不確定改動到何種地步就算重複性低了，簡單的方式就是修改UI, 加密字典, 方法名, 類名. 可能的情況下，完全重構是最好的

(4) 開發者賬號: 在使用過程中要做好隔離, 只能在固定的機器和ip下使用.

(5) 客戶端使用的第三方: 上架前，對自己的進行抓包分析, 檢查第三方是否非法上傳使用者資料或者誘導使用者下載app. 不同的app要使用不同的第三方賬戶. 包括但不限於 第三方sdk的金鑰，第三方的賬戶(不同的app繫結要繫結不同的Facebook賬戶下的不同的appid)

有沒有萬無一失的辦法?

目前沒有萬無一失的辦法. 因為gg的風控也在學習，進步, 升級. 當然如果有人聲稱有穩定上包的辦法, 麻煩你推薦給我, 我去拜師.

當然現在有些公司就是不斷的上架app，每天上架很多app，期望能有幾個app能稽核通過，用量取勝，博機率。其實這裡面有個小問題，就是如果上架的app越多，gg能學習到的app程式碼樣本就越多，這樣是不是也給了gg更多的程式碼關聯檢測依據呢? 大家思考下....

大家也別費勁去猜測和詢問gg的上架風控策略，這個是絕密，就連gg內部非稽核團隊的人都是不知道的。原因你懂的。

其實最穩定的上架策略就是仔細研讀和遵守Google Play的開發者政策，這樣才能保證我們上架的過程順利。

【擴充套件閱讀】Google 開發者賬號及關聯被封后怎麼解決？

選自 第一齣海視角

近期谷歌下架了600多款安卓應用，App被暫停、下架，賬號被封停這些事情遇到太多，損失可謂慘重！下面將結合實際經驗分享一下如何應對開發者賬號被封停，2020年2月份以來，Google封禁的力度和技術水平提升了不少，在踩過很多坑以後，我覺得有必要總結一下我們踩過的坑，給其它朋友作為參考。

Google封禁關聯賬號，主要是把控兩個部分， Google開發者賬號的申請，申請Google開發者賬號用的PC，基本原則：一臺PC對應一個Google開發者賬號。

01

PC+香港VPN

更換一臺全新的PC+香港VPN（之前沒用過的），找一個修改PC資訊的工具，想走捷徑，可以直接用阿里雲在香港的windows雲伺服器去申請，這樣可以省去VPN的費用，一臺PC登入過其他Google開發者賬號，忘記清除登入資訊，結果會涼涼

02

賬號問題

第一次申請時賬號沒問題，等到這個賬號被封，我們更換了windows雲伺服器的IP地址和作業系統，想再去申請，發現總是被封，猜測是雲伺服器被Google記錄了，具體是通過記錄哪些資訊來識別的，還不太清楚。

申請Google開發者賬號用的支付賬號真實的信用卡，一個信用卡只用來支付一個賬號的費用，第三方虛擬信用卡平臺，我們用的是全球付。和信用卡一樣，一個虛擬信用卡只用來支付一個賬號的費用。

其它每個Google開發者賬號都要對應一套全新的資訊。除了上面說的PC和支付賬號外，還包括：手機號，隱私權網址：我們這邊是先隨便亂填一個，等Google找我們時再填一個正確的，開發者個人和住址資訊

01

提交到Google上的的apk， 靜態馬甲包，就是指新提交的包和以前被封的包存在相似的地方，被Google檢查出來了，這種是純靜態檢測，即我們自己解壓apk包就能看到的東西。具體包含哪些呢？

02

Android aar包，Unity遊戲必然要引入各種Android aar包，這些包裡面一般都是第三方公共的SDK，看起來應該沒問題，我們就往aar包加了一個自己的類，結果就被封了。移除這個類就沒事！

03

解決方案，從0開始匯入第三方的SDK，如果自己要新加類，麻煩更換類名和包名，不要和之前提交的一樣，找個第三方加固工具（比如360的應用加固），加固一下apk。

04

資源包，也就是apk解壓後assetsinData下的檔案（以Unity工程為例）Google是通過比較檔名和檔案內容的相似度來判斷兩個包是否是馬甲包，不管你是用mono方式打包，還是IL2CPP方式打包，這個目錄下會有一大堆用hash值命名的二進位制檔案，hash值來源於原始的檔名，這意味著如果兩個apk裡面有大量的二進位制檔案同名，那麼對應的也就會有大量的實體資原始檔同名，這個很危險。

05

最佳選擇，把用到的資源單獨打一個AssetBundle包，並對這個包進行加密（簡單的按位取反就行），這樣就不會有太多二進位制檔案暴露在assetsinData目錄下了，這個最優選擇也有個問題，就是如果這次提的包被封了，下次提的包AssetBundle檔案就和這次相同了，解決方法就是換一種加密方式。

06

伺服器網路，如果你提交的包被封了，那麼下次提交時一定要更換伺服器的IP地址和域名，很多互金朋友可能不知道，自己遊戲的HTTP請求是明文的，就是客戶端傳送給伺服器的HTTP請求把伺服器的域名寫的很清楚，Google會毫不客氣地封掉這個域名，所以光換IP地址，不換伺服器域名，是沒有用的，沒有用的，沒有用的！

07

程式碼（針對Unity工程）這個沒什麼好說的，直接用IL2CPP方式打包，如果你堅持用mono打包，也可以，自己修改一下libmono.so，實現對dll的加密就行。

02

總結

千萬不要去淘寶買Google Play賬號，淘寶那些賣賬號的只顧自己賺錢，一臺機器一張信用卡申請很多賬號，然後賣給你，如果賣出的這些卡號一個有問題，就全部封殺了！切記。實在不行可以掛失你的信用卡，補發一張給你。註冊手機借朋友的或者用阿里小號就可以了。

02

IP問題

以前的IP也不能用了，重新換個IP地址，電腦問題，建議你換一臺電腦電腦，如果預算不夠，那麼可以租個便宜的雲伺服器做個打包平臺，你可以在你的電腦上碼程式碼，打包在雲伺服器打包，app的程式碼和素材以及宣傳等

03

谷歌反作弊

如果僅僅前面3步你以為能逃脫強大的Google Ai了？谷歌反作弊系統會分析你的程式碼的，以及各種特徵。最好的辦法是以前的都不要用了。不然每次封殺你，你可能會懷疑人生，做到以上4點好像看起來就跟以前完全脫離了。沒錯，就是這樣，你一定要把自己當做全新的一個開發者。不要僥倖。你對面的是全球最強大的人工智慧。而你只有一個人。

上傳應用部分

01

多個馬甲包，隔天上傳，每個馬甲包隔1天上傳，釋出成功一個，則上傳下一個。因為同一天可能被同一個人稽核，以避免造成同時被拒/下架

02

用Firefox傳包，據說可以隔離本地資料

03

應用描述、應用截圖，與之前不同

04

應用描述不包含競品品牌詞，apache、base測試版釋出，測試人員賬號，與之前不同

APK打包部分

01

《隱私協議》《使用者資料授權說明》《其他文字協議》，與之前不同

02

APP前端文案（展示文案&提示文案…），與之前不同，細化到每個詞，不僅僅是順序調整

03

APK內資料傳送域名、API、IP、域名主體、SSL證書主體，與之前不同

04

APK文案中聯絡方式（WhatsApp、email、手機號、地址…），與之前不同

05

APK內三方服務資訊（如firebase、google analytics等），與之前不同

06

APK應用簽名，與之前不同

07

APK打包機器和IP，與之前不同

08

程式碼混淆，相似度越低越好，相似性<40%，有條件重構最好。

09

檔名、類名、協議名、函式名、屬性名；圖片、樣式表等資原始檔命名及路徑，與之前完全不同

10

APP啟動彈出隱私授權宣告，需使用者同意，才能進入下一環節，使用者同意後，才可進行資料採集授權，使用者同意授權後，才可進行資料收集

11

圖片、視訊等媒體檔案，hash值與之前不同（需打亂）

12

UI與之前完全不同，從外表看與被下架的產品有結構上的區別

來源：Enjoy遊戲出海
原文：https://mp.weixin.qq.com/s/PVf8Ms3cYGffMVUjnVZulw