由於 Android P 會收緊對 hidden API 的管制，而 Android 掛線動作只能透過 hidden API 進行（見前文），因此近日 Android P 推出 Preview 後，便立刻下載 emulator 來測試。

結果:

成功攔截！

此外，在給予通知存取權後，也可進行接通再掛線。

不過在 log 出現了幾個系統警告訊息:

W/zygote: Accessing hidden method Landroid/telephony/TelephonyManager;->getITelephony()Lcom/android/internal/telephony/ITelephony; (light greylist, reflection)
W/zygote: Accessing hidden method Landroid/telephony/TelephonyManager;->isNetworkRoaming(I)Z (light greylist, reflection)
W/zygote: Accessing hidden method Landroid/telephony/TelephonyManager;->getSimOperator(I)Ljava/lang/String; (light greylist, reflection)
W/zygote: Accessing hidden method Landroid/telephony/SubscriptionManager;->getActiveSubscriptionIdList()[I (dark greylist, reflection)

即是說，程式攔截電話時透過 Reflection 使用了 Android 的數個 hidden API，包括 TelephonyManager 的 getITelephony，isNetworkRoaming 及 getSimOperator，和 SubscriptionManager 的 getActiveSubscriptionIdList。 前三者已被列入”light greylist”內， 而後者則屬”dark greylist”。

正如 Google 在最近的 developer blog上所指，

In the next Android developer preview, you’ll be able to run your existing apps and see warnings when you use a non-SDK interface that will be subject to blacklist or greylist in the final release. It’s always a best practice to make sure your app runs on the developer preview, but you should pay specific attention to the interface compatibility warnings if you are concerned that you may be impacted.

而在最新的Developer Preview 文件上

There are two greylists: The light greylist contains methods and fields which continue to function in Android P, but to which we do not guarantee access in future versions of the platform. If there is a reason that you cannot implement an alternative strategy to a light-greylisted API, you may file a bug to request reconsideration of the restriction.

The dark greylist contains methods intended to be made inaccessible in a future Developer Preview release.

換句話說，Google尚未在 Android P 版一刀切 blacklist 所有 hidden API，而是分段進行，小鴨用到的 hidden API， 電話攔截用到的只屬 “light greylist”，即（除非 Google 改變主意，否則）暫時在 Android P 上仍可進行攔截。

不過，獲取電話中 Subscription ID list（即雙卡電話來電紀錄中見到的 “SIM識別碼”，多數是個位數字）的 API，在 Android P 便要以另行方法代替（這個實際上是有另行方法的，不過較間接）。

前文[1][2]提及，現時獨立攔截軟件能夠掛線，有賴 Android 系統的一個隱藏API，而 Google 將逐步收緊以至禁止軟件使用這類API。即使 Android P 暫未封禁該隱藏API，再下個版本亦很有可能正式禁制。

獨立攔截軟件的唯一出路，是Google將該隱藏API，轉為正式開放的API，供獲用戶授予攔截權限的軟件使用，可惜，近日Google 在 Android P Preview 的 Issue Tracker 中，已正式否決了相關要求。

Google 在回應中，透露了未來的計劃(似乎是Android P以後的事)

We have no plans to expose that individual call control APIs via TelecomManager or TelephonyManager at this time.

In the future, we plan to expose a more comprehensive call control API based on the existing InCallService API. This would allow the user to select a single app which would also be bound to for the purpose of controlling calls on their device.

現時 InCallService API 僅限於用戶預設的一個電話應用使用，提供通話／視像通話時的用戶介面，一般由系統廠商提供，因應個別電話機款支援的功能以至介面設計而度身訂造，比攔截軟件複雜多倍。而上述回覆中亦提及”a single app … for controlling calls”，即僅能由一個電話使用該 API 的限制不會改變，因此，電話應用以外的軟件將無法提供掛線功能(情況和 Android 4.4 以後攔截SMS一樣)。

因此，Google 的說法，確認 Android 下的獨立攔截軟件，不久將來將會消滅，用戶要攔截電話，只可選擇廠商／電話供應商提供的服務，或透過繁複的設定，使用一個未能發揮手機功能及可能與系統介面格格不入的電話撥號兼攔截軟件。

又或者，轉投這方面將比 Android 還開放的 iOS。

註：其實已有人發現了繞過Android P對隱藏API限制的方法（簡體網頁），不過便要冒被Google偵測到會被下架的風險⋯⋯

之前講到，Google表示在Android P起，會漸漸封鎖隱藏功能(Hidden API)，當中攔截來電App常用的掛線功能，雖在 Android P 的預覽版中只納入淺灰名單(即預計Android P仍然可用)，但再下一版亦可能難逃被封。似乎在兩、三年後，只有電話撥號App才可以繼續掛線攔截。但第三方撥號App，在配合手機功能及原廠界面方面必定大打節扣。

踏入5月，原以為兩、三年後才出現的情況，突然到來，有用戶回報，廣告來電時雖然偵測到，但掛線功能失效，其他功能正常。顯然，這次不是一般的背景被殺問題。追查之下，原來問題是源自官方Android於5月發布的一項「保安更新」！

原來，這個廣為攔截App使用的掛線功能 (TelephonyManager#endCall())，被一間寫App公司 Introne Apps 向 Google「舉報」[註1]，由於與後來加入的源碼處理不一致，這項原先存在的功能竟被當成保安漏洞，還附上漏洞編號「 CVE-2017-13322」。Google 人員在2月，修改了 Android 系統以「堵塞」該「漏洞」。

該項修改連結:

Enhanced permission checks for TelephonyManager#endCall() API.

修改註釋:

The existing permission checks require CALL permission in order to end an ongoing call or reject an incoming call. The Telecom equivalent of this API requires MODIFY_PHONE_STATE. Since this API IS in fact a system API, modifying the permission requirements to require the same MODIFY_PHONE_STATE permission. [註2]

此改動在4月中被採納到 Android 源碼，再被納入了對Android 6及以上適用的 Security Patch，在2018年5月5日的保安更新中發出。

5月5日保安更新詳情:
https://source.android.com/security/bulletin/pixel/2018-05-01

換句話說，原本預計在數年後才在Android Q發生的問題，提前在今天出現，並透過Security Update，在短期內影響Android 6以上(即大部份)用戶。

隨着該保安更新，漸漸被各手機商推送，大量攔截App用戶發現，在Android更新後，用開的App已不能掛線，最多只能靜音，而視乎App及設定，廣告及詐騙來電來電時會一直震動，造成滋擾。

獨立的攔截App是否就此被趕上絕路？欲知後事如何，且看下回分解。

[1] 來源: Google: https://source.android.com/security/overview/acknowledgements
[2] 此處提及的 Telecom 是指 TelecomManager 下，功能相似的源碼。Telecom是較新的模組，能處理所有種類的來電 (如 VoIP)，現行 TelephonyManager 則處理傳統的流動網絡。由於 MODIFY_PHONE_STATE 權限，只有系統App才可獲取，上述改動亦等同直接封鎖了該功能。

本版主要為加強對 Android P (Android 9) 支援，當中Android 8 或以上使用新接聽方法(無需存取通知權[註1]，可較可靠地進行接聽再掛線以避免留言)，而Android 9 (DP 3 (beta 2))或以上使用新掛線方法，進行攔截動作。

此版亦就2018年5月5日的保安更新，引致攔截App掛線失效問題(見)，提供暫時解決辦法，恢復掛線功能(但用戶需要先開啟存取通知權限給小鴨，方會有效)。

在遇到掛線失效問題時，程式會回報錯誤，並引導用戶開啟存取通知權限。在主頁亦會顯示相關提示。

本版亦採用了Adaptive Icon (支援Android 8及以上)，在相關Launcher會自行適應App icon形狀。

其他修改包括:

(1) 修正了Android 4下夜間模式的拉下選單顯示問題，

(2) 解決部份Android 6 LG機款的彈App問題，

(3) 修正Android 7以上Sim slot辨認問題，

(4) 攔截開啟失效時，會回報錯誤並關掉攔截。確保重啓完成才開啟攔截以避免問題，

(5) 部份機種近期彈App問題。

註1: 視乎設定，若設定了來電時震動，但希望攔截的來電不要震動，則仍須存取通知權。

唔知有無用家，真係識人去咗呢個「我想住嘅地方」

有嘅話，下一版就要⋯⋯

對其他人嚟講，瓦努阿圖，係想cut線同埋千祈唔好回撥嘅地方。

增強防護功能

此版因應早前來自某些偏遠地區撥出的「一響掛線」IDD騙案，新增了攔截及提示功能，從某些預設地區撥入的IDD來電(即「+」號開頭的電話)，會加入警告，用戶亦可選擇攔截所有從這些地區來電的電話。為免影響真正有需要與當中某些地區通話的用戶，在攔截動作中可自行在名單設定或剔除某些地區。

由於這類電話的手法，是為誘使受害人因不知電話來源而回撥IDD電話，再儘量拖延以從高昂的通話費中獲利，因此切勿回覆這類電話。為免用戶誤觸回撥，程式新增撥出電話防護功能，可依用戶選擇攔截所有撥出往這些地區的電話，或者在撥號前彈出警示確認。這項設定預設為關閉。有需要使用可在設定>撥出防護中開啟。用戶亦可在我的白名單中輸入例外號碼。

用戶亦可選擇攔截／提示所有撥出的IDD號碼，以免誤撥，不過目前只會辨認「+」號開頭的號碼，以個別電訊商IDD碼（如001）撥出的號碼目前不會辨認。

新增鎖屏熄mon功能

在鎖屏狀態下，推銷來電即使被攔截，亦或會將屏幕開啟一段時間，造成滋擾，亦浪費電池，因此本版亦新增功能，若用戶在攔截動作的權限設定中，給小鴨提供裝置管理員授權，在來電攔截後會快速回復鎖屏狀態，一般情況下屏幕會很快關閉。在攔截前若非鎖屏狀態，則不會受影響。

注意，在把小鴨設為管理員後，若要卸載小鴨，則須先取消管理員授權。

(11/11/2018)注意，由於Android 保安設計，裝置管理員鎖屏不能用指紋解鎖，只能用其他方法 。如用指紋解鎖請留意。

條款:擴闊伺服器定義

為應付日後功能需要，而雲端服務亦已相當平宜，故這次在小鴨條款中將伺服器定義，擴至包括小鴨作者日後可能加入的機器，以提供的更好的資訊及功能，例如防騙訊息。不過目前尚未開始設立系統。

前文提到，Google 在2018年5月突然於保安更新中，封鎖現有的掛線隱藏功能，令一直依賴此功能的攔截 App 突然失效。

Google 這次有違處理 Android 的一貫作風，此改動修正的，根本不是什麼緊急的保安問題，最多只能說 Android 內部功能之間有不一致的處理。而 Google 收緊 Android 供 App 使用的功能或政策，即使 Google 認為功能被濫用，一般都會給予一段時間，供開發者／用戶適應，不會毫無先兆地推出，例如收緊 Accessibility API 政策，收緊背景執行，以及封鎖其他隱藏 API 等。

鴨神顯靈？

不過，就在差不多同一時間， Google 之前仍堅持、不開放掛線功能給非預設電話撥號 App 的態度(見前文)，卻發生了 180 度轉變，不再堅持日後只有撥號程式才可掛線。

在5月15日，Google 人員表示將會在 Android P 中開放另一個掛線的功能 TelecomManager#endCall 給一般 App 使用 (該功能在 Android P 前要MODIFY_PHONE_STATE權限，限於系統使用)，同時，亦表示 Android P 之前的版本(受5月保安更新影響的 Android 6 – 8)，應可以繼續使用原有的隱藏方法掛線，並會將該保安更新還原。這間接引證了，5月的保安更新是未經深思熟慮的。

下文引述出自 https://issuetracker.google.com/issues/37018641

However, a new public API will be introduced to handle this case.

TelecomManager#endCall (note the location; TelecomManager versus TelephonyManager) will be available to callers holding the ANSWER_PHONE_CALLS runtime permission.  This new API complements the existing TelecomManager#acceptRingingCall and provides an app with the ability to answer or reject calls.

A rework for the security patch in question is under way, so the fix “Enhanced permission checks for TelephonyManager#endCall() API” will be modified.  For versions of android prior to P, the expectation is that TelephonyManager#endCall” will still be available via reflection using the CALL_PHONE permission. (5月15日)

其後，在6月初，Google 提出了明確的復原時間表，即在7月的更新會還原，8月推出永久性的修復。

My understanding is that it (Blocking of hang up API in May Security Patch) should be reverted in the July security bulletin, with the permanent fix in the August security bulletin. (6月6日)

獨立攔截App終於正式獲承認

最後，在6月6日推出的 Android P Developer Preview 3 中，加入了正式的掛線 API。

該API要求 ANSWER_PHONE_CALLS 權限，和 TelecomManager 下的接線 API 相同。在加入正式的掛線 API 改動的註釋中，指掛線功能對攔截 App 的確有必要，似乎是首次承認了獨立於撥號程式的攔截 App，仍是有價值的。

以下為註釋原文(取自https://android.googlesource.com/platform/frameworks/base/+/f858a0e8d23e43fa815962f0c3edbef293d37f7f)

Make TelecomManager#endCall a public API.

A broad category of apps such as wearable companion apps and call blocking apps rely on the ability to reject a ringing call. Previously this was achieved using a broken TelephonyManager API which lacked permission checks.

To support these applications, removing the @hide attribute on the existing TelecomManager#endCall API so that apps with the existing ANSWER_PHONE_CALLS permission can reject ringing calls and end ongoing calls.  Logically if an app has permission to answer a call, it should be able to end it.

至此，攔截 App 前途已較明朗，但當各廠家陸續發放5月的更新(接近原生 Android 以外，一般或會遲一個月)，似乎攔截 App 用戶若一直有作保安更新，仍須面對數個月不能掛斷電話的問題，若一些較舊的電話，剛巧／不幸在這期間被廠商放棄而不獲更新，更會永久失去掛線效能。

小鴨幹線的應對措施

為此，小鴨幹線經研究及發放試驗版確認後，於6月更新的 0.2.12 版加入了臨時應對措施，對 Android 6-8 以及 Android P Preview 2 或以前的版本，會偵測掛斷功能是否正常，若掛斷失效，會建議用戶給予通知存取權，利用通知存取權恢復掛線及接通再掛線功能，務求將用戶影響減至最少。掛斷原理是模擬 headset 操作，類似在此分享的方法。

而為準備 Android P 正式推出，該版亦預早加入偵測及利用新掛線功能的機制，當用戶升級至 Android P (Preview 3 或正式版)，便會自動利用 Android P 最新的掛線功能，無須加入預設撥號功能及強制用戶更改預設撥號程式。

小鴨作者分別在11月2日，9日及14日，收到類似以下的通知，指「小鴨幹線」新增，須使用裝置管理員鎖屏權限的攔截後鎖屏功能，違反Google的deceptive device settings changes政策，並即時將「小鴨幹線」下架。

該功能須由用戶自行在設定內開啟，開啟掣的位置已附有清楚說明，但Google(bot?)第一次email首先要求在Google Play內加入“This app uses the Device Administrator permission.”字句。

Hi Developers at Headuck,

After review, Headuck Call Blocker / Caller ID DEV (HK), com.headuck.headuckblocker.dev, has been removed from Google Play because it violates the deceptive device settings changes policy.

You must explain to users why you are requesting the ‘android.permission.BIND_DEVICE_ADMIN’ in your app. Apps must provide accurate disclosure of their functionality and should perform as reasonably expected by the user. Any changes to device settings must be made with the user’s knowledge and consent and be easily reversible by the user.

Next Steps

1. Read through the Deceptive Device Settings Changes policy for more details, and make sure your app complies with all policies listed in the Developer Program Policies.
2. If you don’t need the BIND_DEVICE_ADMIN permission in your app:
   • Remove your request for this permission from your app’s manifest.
   • Sign in to your Play Console and submit the modified, policy compliant APK.
3. Or, if you need the BIND_DEVICE_ADMIN permission in your app:
   • Include the following snippet in your app’s store listing description: “This app uses the Device Administrator permission.”
   • Provide prominent user facing disclosure of this usage before asking the user to enable this permission within your app. Your disclosure must meet each of the following requirements:
     • Disclosure must be displayed in normal course of usage of your app. Your users should not be required to navigate into a menu or settings to view disclosure.
     • Disclosure must describe the functionality Device Admin permission is enabling for your app. Each security policy used with the Device Admin request must be declared in your disclosure, and each policy must be accompanied with justification for the request.
     • Disclosure cannot only be placed in your privacy policy, terms of service or end user license agreement (EULA).

If approved, your app will again be available with all installs, ratings, and reviews intact.

Regards,
Nilay
Google Play Review Team

這項要求已立即辦妥並重新獲上架。但其後分別2次收到一式一樣(但由不同Reviewer署名及highlight不同段落)的通知，11月9日highlight了”Or, if you need the BIND_DEVICE_ADMIN permission in your app”，意義不明，在修改Google Play字句以致連大細楷都符合“This app uses the Device Administrator permission.”字眼後即重新獲上架。

但11月14日又再三收到同一email，這次highlight了”Provide prominent user facing disclosure of this usage before asking the user to enable this permission within your app. Your disclosure must meet each of the following requirements”，這段更含糊的字句。目前只能估計是因該選項是在設定之內，不是”normal course of usage”，被認為是有意隱藏(但攔截App大部份人都是設定後就不再理會??)，或解釋還不夠詳盡，如沒有用特定字眼(Google或許已是由AI bot負責監控，這種可能較大)。

作者多次透過Google developer網頁提交要求希望得到進一步指引，卻只收到似是bot的標準回覆(即重覆該政策一次)或沒有回覆(一如Reddit androiddev常提及的求助無門經驗)，似乎沒有方法接觸到有common sense的真人澄清問題。

目前，用戶若要使用小鴨，請在此頁下載。由於重覆違反政策會被永久刪App，若未能澄清問題，可能只能在blog發放有鎖屏功能的版本，而在Google Play版本則刪去該功能。

新增警務處防騙訊息

滋擾來電其中一個來源，是來自各類電話騙案的騙徒。即使大部份市民不會上當，只要騙徒仍能透過不斷更新的手法，從少部份受害者中獲利，這類滋擾只會變本加厲。

只有令所有人提高警覺，使騙徒難以成功，才能有效杜絕這類滋擾。

「小鴨幹線」為嚮應警務處本年十二月初舉行的「港島總區截騙大行動」，加入了新的防騙貼士一欄，詳列由警方防騙協調中心發出的訊息，包括騙徒最新手法，希望訊息能更廣泛留通，為讓公眾提高警覺而出一分力。

詳細運作如下：防騙訊息由「小鴨幹線」新設的伺服器，經警務處批准，從警方網頁下載標題，訊息標題會在App下載廣告電話名單時，由App向「小鴨幹線」伺服器檢查及下載更新，同時亦會一併檢查及更新一響來電地區名單及高頻廣告來電的更新(只會間中更新)。用戶點擊防騙訊息標題，「小鴨幹線」便會於瀏覽器開啟有關警方網頁。

暫時移除攔截後鎖屏功能

「小鴨幹線」在上一版0.2.13加入鎖屏功能，在攔截電話後，若用戶主動給予小鴨裝置管理員權限，便會透過將屏幕上鎖而令其關掉。不過，自於十月底上載該版本，小鴨已三次因可以使用該權限而被Google下架，Google除重覆有關該權限的一般性政策，一直沒有清楚給予原因，所有透過開發者網頁向Google就原因及如何可合規的提問，除第一次收到其覆述政策一遍，之後沒有回覆。

小鴨作者在頭兩次試圖於 Google Play 加入及修正政策特定字眼，雖短暫再獲即時上架，但過兩三天再被移除。詳見有關「小鴨幹線」暫被下架。

為免被再次下架，或因多次重犯觸發永久下架，目前只好在Google Play版本上移除該功能。在此頁下載的版本不受影響。

由於 Google Play 對 App 限制陸續有來，見有關「小鴨幹線」暫被下架 (2) 之 麻煩陸續有來，日後很可能只能在此網誌提供完整版的「小鴨幹線」。

更新至Android 8要求

小鴨在之前版本已漸漸加入 Android 8 的要求，至本版因應規定，正式更新至完全符合 Android 8 的規定，此次改動的主要影響是，Android 7.1 或以上，必須給予小鴨覆蓋其他App的權限，才會於推銷等來電時，彈出小鴨的提示。若小鴨因未有權限而彈出提示失敗，會在入App時給用戶建議更正。

[30/11 更新]: 推出後發現，彈出視窗位置的設定畫面，尚未更新至符合Android 8規定，在Android 8或以上，設定彈出視窗位置時會彈App。這個bug下次更新時會更正。

續上文

由於 Google Play 有極大量App，Google似乎只能靠 AI 去估計什麼App有問題，亦可能只靠 bot 去回覆查詢，問題是AI不是真的有智慧，只是靠之前有問題 App 的特徵作訓練，再從新個案中根據特徵找出大機會有問題的 App。若以此而隨時將 App 下架，不經真人檢查，再將處理開發者問題的要求交由bot自動處理(或不處理)，則 Google Play 對(無權無勢的小)開發者，毫無服務可言，另一方面，卻因其近乎壟斷地位，App 的購買及 App 內交易，卻仍維持極高比率的佣金。

此外，Google亦正漸漸透過各種理由，收窄各類與Google構成競爭的App的空間。就以攔截App來說，Google因私隱理由，下年初開始，所有使用讀寫系統來電紀錄及處理撥出來電的App，要在Google Play上架，都要事先向Google特別申請，而新政策下，似乎攔截App除非被設為預設電話App，否則不能使用寫入來電紀錄及處理撥出電話的功能。而小鴨幹線在申請及提出原因後，仍被否決使用這兩項功能，亦如一貫作風，沒有(實質)解釋：

Thank you for contacting the Google Play team. We have received the following information in the Permissions Declaration Form you submitted:

Q1 – Core use case(s)

Caller ID, spam detection, and blocking, Out-going call protection against wangiri scam

Q2 – Declared permission(s)

READ_CALL_LOG

WRITE_CALL_LOG

PROCESS_OUTGOING_CALLS

I’ve reviewed your request and found that your app, Headuck Call Blocker / Caller ID DEV (HK), com.headuck.headuckblocker.dev, does not qualify for use of the requested permissions for the following reasons:

The declared feature Caller ID, spam detection and spam blocking is allowed; but not approved for the specific permissions you’ve requested (PROCESS_OUTGOING_CALLS,WRITE_CALL_LOG)

換句話說，影響所及，Google Play上架的「小鴨幹線」，明年起不可以再刪除已攔截電話的系統紀錄(要 WRITE_CALL_LOG 權限)，以及防止用戶誤撥一響來電地區，即剛在上一版推出的撥出防護功能(要PROCESS_OUTGOING_CALLS 權限)。注意禁止攔截 App 使用這些功能，對已有用戶明確給予讀取來電紀錄權限的攔截App來說，並無關私隱保障，純粹是限制非預設撥號來電App的功能。

剛巧，Google 的 Android 預設電話 App，剛在本年中加入攔截及回報推銷來電功能….

類似情況，發生在與 Google Assistant 競爭的自動化 App (功能將受明年起的同一政策限制)，與 Google Play Services 內置 Wifi 定位功能相若的 Wifi 定位 App 及第三方/公開的 Wifi 定位數據庫(Android 8及9以省電為由，新增的 wifi scan 限制，系統程序如 Google Play Services 不受限)。

上述受影響的攔截及回報，自動化 App 及 wifi 定位功能，有一項共通點，就是可名正言順大量收集用戶回報，習慣及地理數據。

究竟是真巧合還是其他，局外人無從判斷。但事實是，Google 既控制 Android 系統發展，透過 Google Play 授權控制大部份 Android 廠商，亦近乎壟斷 App 的分發渠道，因此 Android 本身開源性質，難以阻止 Google 漸漸透過各種方法使 Android 成為與 iOS 一樣封閉的生態，更甚者是成為令用戶在別無選擇乖乖地向 Google 貢獻私隱數據的工具。( 諷刺的是，Google限制其他 App 理由，往往是保障你的私隱。)

現時唯一可做， 是到以下Android Issue tracker討論圍爐發洩 / star the issue (表示受影響) (要 login google 才看到):

• SMS 及 Call Log 限制https://issuetracker.google.com/issues/117486314
• Wifi scan 限制https://issuetracker.google.com/issues/112688545

TL;DR：Nokia 升級 Android 9 後，boot機時會殺掉小鴨，令小鴨無法自行啟動，更會向 Google Play 報告指小鴨出現問題。

經研究，疑似 Nokia 系統內置 App 殺手所為，因此，請 Nokia 手機用戶升級 Android 9 後不要安裝/繼續用小鴨，請使用不受影響的「小熊來電」或「Whoscall」等 。謝謝。

以「Pure」 Android 為賣點的 HMD

話說 HMD 的 Android 手機，主要賣點（除了對 Nokia 品牌的情懷外），就是接近「原生 Android」，而事實上Nokia 去年是出產最多型號 Android One 手機的商廠之一。

對於討厭了某些廠商，將 Android系統加料，預先安裝一堆廠商（或付錢贊助商）指定，沒用卻不能刪除的bloatware App，「原生 Android」有一定吸引力。

「原生 Android」另一好處，是沒有廠商自行改訂系統，減少與一眾按照 Android 標準而寫的App 不兼容的機會，避免要像一些尤其大陸牌子手機，要經繁複設定，才能讓一些正常App收到通知或於背景運作。

在App開發者角度，由於開發時一般都會使用Google提供的原生Android模擬器測試，因此使用接近原生的Android的用戶，一般會較少運作上的問題。

真的100%沒有加料 ?

少年你太年輕了。

「小鴨幹線」於2018年11月尾升級至符合 Android 8 標準後，在「小鴨幹線」的 Google Play Console 突然湧現了大批不同型號 Nokia Android 9 手機，向 Google 的當機 （學名為ANR） 回報，指在啟動攔截服務時出了問題。

“Context.startForegroundService() did not then call Service.startForeground()” 問題，冠絕小鴨App的所有ANR錯誤回報，一個月收到超過 800 次

一入去此問題的詳情，全數是Android 9的Nokia機款

同是 Android 9 的其他牌子，包括同是 Android One 以至 Pixel 親生仔，以至華為小米這些問題常客，都沒有此項問題。

綜合各種跡象，推測問題的原因，很可能是 Nokia 的 Android 9 手機，加入了原生Android所沒有，極為進取的殺 App（或凍結App）功能，以致攔截服務剛啟動，未有時間按Android 8 標準完成顯示 Icon 的動作（其實只須以 microsecond 計的時間），使被 Nokia 的殺手殺掉（或凍結），來不及完成Android 8 顯示 Icon 的要求。系統發覺服務沒有遵守要求，便會發出此項錯誤。

Don’t kill my App

經網上搜查，果然有App （Sleep as Android） 的開發團隊，發現 Nokia 手機同樣問題，更找來實機驗証。據其研究所得，Nokia 手機，預載了一間內地 Evenwell 公司出品，名為 com.evenwell.powersaving.g3 的App，以前所未見的粗暴的方式殺 App。套用該開發團隊（Urbandroid）的描述 :

The problem only occurs on Nokia devices with Android Pie. Nokia started to bundle a toxic app (package: com.evenwell.powersaving.g3, name: Battery protection) with their devices by some Asian company Evenwell. This app kills apps in the most brutal way we have seen so far among Android vendors.

該團隊近日更綜合經驗，推出了 “Don’t kill my App” 網站 （https://dontkillmyapp.com），列舉最差的殺App手機，以接近原生Android為噱頭的 Nokia，名列榜首。（而同樣為Android One 的 OnePlus，緊隨其後），竟超越了「深度訂製」的華為、小米。

同一團隊，更將Nokia 的暴力 App 殺手 com.evenwell.powersaving.g3 抽出並反編繹，再放到 Github :

https://github.com/urbandroid-team/dont-kill-my-app/tree/master/killers/nokia/com.evenwell.powersaving.g3

雖然有暴力成份，不過小鴨都好奇看了一下，果然相當粗暴…

究竟如何粗暴？為何「小熊來電」或「whoscall」，以至「Whatsapp」等背景App又運作如常？而每次開機後自行手動開啟小鴨又沒有問題？請看下回分解。

以下內容涉及暴力殺 App 及不當系統行為，敬請留意。

續上回，用 Nokia 品牌的 HMD Android 9 手機，預裝 Evenwell 的殺 App 程式，粗略看過其源碼，發覺似乎無時無刻都在尋找殺戮對象，包括手機啟動，任何程序啟動，網絡環境變更等，都會檢查是否要大開殺戒。

基本上，所有背景啟動，都會即時考慮是否要立即殺死(不是禁止啟動，而是出世後觸發該程式，檢查是後才殺死)， 但亦有不會殺死的種類或情況，包括 :

• 最近曾開啟(在 Recent List 頭)的幾個 App
• 預設的 SMS App (但沒有 Dialer App)
• NFC 服務觸發的 App
• 正在有來電響鈴時，不殺任何 App
• 取得audio focus (正播放音樂) 的App
• 正在用 network 的 App
• Live wallpaper App
• 有顯示 widget 的 App
• 預設 launcher
• 預先指定的內置白名單App
• 進程(process)名稱包含冒號，即App的非主要進程

追查一下內置白名單有什麼(國際版)，發覺有一系列的第三方 App (來源):

ru.megafon.mlk
kz.beeline.odp
ru.tele2.mytele2
net.seddev.callerunknownlocation
com.app5.rakem.wahmi
com.KatlinDev.fblikes
com.nttdocomo.android.remotelock
jp.softbank.mb.tether
com.nexon.nxplay
com.opplysning180.no
no.intellicom.app1881
com.ms1881
com.hthk.ThreeShortCode
nl.addcomm.afvalwijzer
de.eplus.mappecc.client.android.alditalk
au.com.aldi.android
com.google.android.apps.messaging
com.anytag.android
com.azarlive.android
com.bbm
com.bell.ptt
com.turkcell.bip
com.touchtalent.bobbleapp
de.knabedesign.bosfrequenz
com.bt.voiceapps.homeaway
net.nanabit.callconfirm
com.studiokuma.callfilter
com.smartone.callguard
com.eyecon.global
com.vladlee.easyblacklist
com.eupheme.callrecorder
com.plugmind.cbtest
com.chaatz
hu.sanomabp.citromail
com.clanplay.clanchat
mobi.drupe.app
com.bluebeam
no.digipost.android
jp.co.nttdocomo.saigaiban
com.discord
com.dw.contacts.free
com.blogspot.acesandroiddevelopment.easywalkietalkie.free
com.threesixtyentertainment.nesn
com.modoohut.dialer.theme.dark
com.modoohut.dialer.plugin.geocoder
primiprog.waw
com.oakley.fon
com.fongo.dellvoice
fr.freemobile.android.vvm
com.freedompop.phone
pl.gadugadu
com.google.android.gm
com.jb.gosms.da
com.jb.gosms.it
com.jb.gosms
com.jb.gosms.pl
com.jb.gosms.sv
com.google.android.apps.fireball
com.android.chrome
com.google.android.apps.tachyon
appinventor.ai_appsgeniet.MessageGift
com.handcent.lang.nextsms.hu
com.google.android.talk
com.imo.android.imoimbeta
com.imo.android.imoim
com.androidintercom
org.woltage.irssiconnectbot
com.jio.join
com.pccw.mobile.sip02
net.fidanov.landroid
it.italiaonline.mail
jp.naver.line.android
com.uplus.lps.agent
pl.tmobile.miboa
de.telekom.android.customercenter
ru.mail.mailapp
com.orange.vvm
msgplus.jibe.sca
com.facebook.orca
com.facebook.mlite
es.ono.MiOno
com.movistar.android.mimovistar.es
es.vodafone.mobile.mivodafone
net.bfgnet.miandroigo
nl.simyo.mijnsimyo
com.nosnaj.missatsamtal
com.yogi.operadora
ru.beeline.services
com.putitonline.mmm
uk.co.o2.android.mynetwork
com.vodafone.android
ca.bell.selfserve.mybellmobile
com.ChinaMobile
com.conzebit.myplan
Uxpp.UC
pt.zon.fon
mobisocial.omlet
com.camerum.android.app.operadora
fi.mobilive.vayrynen
nu.firetech.android.pactrack
nl.politie.consumentenapp
com.motorola.ptt.prip.br
com.psiphon3
com.psiphon3.subscription
se.tactel.reach
com.ready.android
com.rediff.mail.and
com.rts.ic.ym
com.Rogers.phonebookrogers
com.sfr.android.sfrmail
com.sfr.android.vvm
org.mistergroup.muzutozvednout
org.thoughtcrime.securesms
com.skype.raider
net.daum.android.solmail
jp.co.nttdocomo.carriermail
com.surya.STDCodes
com.reyvilo.android.suiviconso
pl.netox.supersms
de.tubs.ibr.dtn.dtalkie
me.talkyou.app.im
nl.apps4us.nummerinfo
org.telegram.messenger
no.telenor.dekningskart
dk.shape.teliacontacts
com.hutchison3g.threeintouch
br.com.conception.timwidget.timmusic
com.tokensapp
com.truecaller
com.uplus.ipagent
com.motorola.visualvoicemail
com.viber.voip
ca.virginmobile.myaccount.virginmobile
com.vodafone.messaging
com.vodafone.mbb.wifimonitor
de.telekom.mds.mbp
ru.atrant.worldcallplaceandtime_db_russian
org.herrlado.websms.connector.arcor
com.tencent.mm
com.orderlysoftware
com.whatsapp
com.clone.multipleap
com.gregdev.whirldroid
com.whooming.WhoomingMobile
gogolook.callgogolook2
com.andr.evine.who
com.sourcebt.android.wifitalkie
com.mywispi.wispiapp
jp.co.yahoo.android.ymobile.mail
com.yahoo.mobile.client.android.mail
ru.yandex.mail
com.zing.zalo
com.microsoft.office.lync15
us.zoom.videomeetings
com.Slack
com.cisco.webex.meetings
com.microsoft.teams
com.afwsamples.testdpc

當中有即時通訊的 WhatsApp、Telegram、WeChat (com.tencent.mm) 、FB Messenger (com.facebook.orca) 、Line (jp.naver.line.android)、瀏覽器 Chrome，而攔截 App 則包括數碼通「來電管家」(com.smartone.callguard)、小熊來電 (com.studiokuma.callfilter)、Whoscall (gogolook.callgogolook2) ，也有 TrueCaller (com.truecaller)、Calls Blacklist (com.vladlee.easyblacklist)。其他主要是須在背景運作的通訊或VoIP等，主流的程式。

當然沒有「小鴨幹線」這類小開發者的程式。

即是說，Nokia 已預先內訂保護「小熊來電」，「Whoscall」，「WhatsApp」之類主流程式，以及音樂播放，widget等種類的背景服務，在原生標準之上，限制用戶只能使用某種行為或名單指定的程式，而限制的條件毫不透明，這點和其他「深度訂製」大陸牌子機的所謂省電功能，並沒有分別。

而更甚者，用戶似乎無法簡單地關閉該功能，或自行將 App 加入白名單防止被殺，根據 Don’t kill my app 的 Nokia 分頁及其他地方的討論  (如這個)，把 App 放入原生 Android 設定的 doze 白名單，是沒有用的。雖然該殺手程式源碼，看來似乎有自訂白名單機制，來讓用戶防止殺 App，但似乎沒有人提及設定方法，未知是否為保持近似原生的設定界面，而將之隱藏。

以上為根據 Don’t kill my app 在 Github 公開的源碼分析，不排除 Evenwell 更新該程式，以致現時或日後的效果有所不同。

對小鴨的影響

上述 Evenwell 殺 App 程式與以往其他同類 App killer不同之處，是既不等待一段較長時間才殺 App，又不一開始時便禁止啟動（或許是因為要視乎 App 行為而決定）。這種方式及 timing，恰恰使要在背景起動的 App，啟動了卻無法完成 Android 8 以上顯示 Icon 要求，而被系統報錯彈 App。

因此，HMD 用戶在升級 Android 9 後，會發覺開機後，WhatsApp 之類主流通訊程式，音樂播放程式，widget 等背景服務運作正常，而小鴨則在啟動後立即死掉或凍結，觸發了錯誤，系統更會耗用數據，向 Google 提交錯誤報告…

即使 HMD / Nokia 用戶屬少數，亦令小鴨自12月起，在Google Play Console 整體表現，ANR (當機彈App) 率大幅提升，已去到會被 Google 處罰的「Bad behaviour threshold」邊緣徘徊。

所以，希望 小鴨用戶若用 HMD / Nokia 手機並使用 Android 9 ，為免耗用電力及數據，請刪除「小鴨幹線」，轉用上述「小熊來電」等，HMD / Evenwell 指定名單內的 App。

小鴨已將部份 Nokia 機種列為不兼容，以反映事實。

順帶一提，起動失敗後，用戶若手動開啟小鴨 App 再關閉再重啟攔截，小鴨是會如常啟動及運作的，但這完全是幸運(?)的巧合，因為 (1) 前景 App 相關的運作不會被殺，因此開啟小鴨 App 再啟動攔動沒有問題，(2) 之後因為小鴨攔截服務的特別設計(使用了另一非主要進程 :resident 專負責攔截，減少平時佔用空間)，也在殺手 App 的例外，所以服務候命時沒有問題，(3) 處理來電時會啟用主要進程，但殺手App 剛好不會在有來電時殺App，小鴨再避過一劫。

若小鴨沿用一般使用單一進程的設計，應會在一段時間後(如主程式關閉後一段時間)被清除。這也突顯這類 App 殺手準則的隨意性，若非查看源碼，完全不會知道為什麼某些 App 不能運作而其他類似 App 沒有問題的原因。

胡亂殺 App 或得不償失

一般來說，由於這類殺手 App 一直在背景運作，每當執行新程式或其他觸發其啟動的條件符合時，都會被啟動去檢查一次是否要殺 App，本身會耗用電力，因此在一般情況，省電效果成疑，在 Android 8 以上，系統本身已嚴格規管背景運作的前提下，只會防礙獲用戶同意的後台服務的運作，同時更可能耗用更多電力。

更何况，當一個品牌，以所謂「100%」、「原生」、「pure」Android 為賣點， 但消費者得到的，卻是在原生之上，特別加料的手機，令部份依足標準而製，在真 · 原生系統能運作無誤的 App，無法正常運作，更無法改變設定，變相限制用戶的選擇。用家若事先不知情，或難免有被商品說明誤導的感覺。

當然可能亦有用戶，喜歡原生介面，快人一步的更生速度，而使用 App 的習慣完全與殺手 App 的預設準則一致，又不介意日後 App 選擇被限制，這項「額外」功能，帶來了意想不到的驚喜 …  那麼，我真係恭喜你呀。

HMD「越獄」方法

警告 : 以下內容有危險動作，除非有專人指導、或本身是專人，否則切勿模倣

若使用 Android 9 的 HMD 手機，又希望突破限制，使用沒有在白名單的背景軟件，包括小鴨，在網上找到了方法，可以透過 adb 在自己 user 刪除該 App 殺手 :

pm uninstall --user 0 com.evenwell.powersaving.g3

這方法是不用root的，據悉不會影響 OTA (参考) ，但會不會影響保用便不得而知。

事實上，Evenwell 有大量其他 App 在 HMD 手機背景運作，負責追蹤使用情況及更新。有用戶試過以相同方法刪除了亦沒有問題，參見這頁。

再戴一次頭盔，後果自負，若不熟悉 Android adb 及相關工具，請改用指定的背景 App。

0.2.12或以前版本（即在去年10月或之前安裝） 用戶注意

基於「小鴨幹線」 App 在與 hkjunkcall 進行加密連線時，採用了較嚴格的認證方式(certificate pinning)，在 hkjunkcall 於一月中、原有認證到期而更新認證後，0.2.12或以前版本的小鴨，已拒絕與 hkjunkcall 進行加密連線，引致在試圖檢查下載名單時，出現更新檢查失敗/未能連接伺服器的訊息，未能檢查 hkjunkcall 名單版本及下載名單。

去年11月起的版本已處理有關問題，舊版本用戶請盡快更新「小鴨幹線」至現行版本，以繼續下載 hkjunkcall 名單。現行版本仍兼容 Android 2.2 或以上機款及維持apk檔在3M左右。

不便之處請見諒。

同時亦請留意，因應 Google Play 政策加強對 App 限制，「小鴨幹線」 Google Play 版本將會刪除部份功能，完整版可在此頁下載。詳見0.2.15版說明。

Google Play版本移除「刪除系統來電紀錄」功能

由於 Google 的政策，以私隱為由，收窄 Google Play 上第三方 App 的功能（見此文），0.2.15 版違反新政策而被下架，再上架 Google Play 版 (0.2.16 版本起) 已移除「刪除系統來電紀錄」功能以符合要求。要繼續使用相關功能，請使用本網站此頁面的完整版本。

Due to Google policies to restrict third party Apps on Google Play on privacy reasons, after the old 0.2.15 version has been removed from Google Play for violation of the new policy, Headuck has to remove the “Erase call record” function from its Google Play version starting from version 0.2.16, to comply with the policy. To continue the use of the removed function, please download the full version of Headuck from this page

而原本撥出防護功能亦因同樣原因，計劃在 Google Play 版本移除，不過後來 Google 稍為放寬了政策，讓攔截類 App 繼續使用撥出攔截權限，有關功能才在新版保留。

Nokia Android 9 不自行啟動小鴨

此外，由於使用 Nokia 牌子的 HMD Android 9 電話，雖是 Android One 電話但附加特殊功能，引致大量小鴨在開機時啟動失敗的報錯個案，因此在新版本，特別針對 Nokia Android 9或以上，不會在開機時試圖自行啟動，Nokia 用戶請使用其他指定攔截軟件。

不過，若用戶已採取措施，停止 Nokia 上殺 App 功能，可到「設定」>「程式選項」>「強制開機後自動啟動」選擇開啟，以繼續使用小鴨。

夜間模式更新 (Android 9)

小鴨的夜間模式，一直是利用 Android 之前隱藏的整體夜間模式機制，小鴨內夜間模式設定，其實是直接改動手機整體夜間模式。本應是在系統正式推出夜間模式設定後，用戶應轉用系統的夜間模式設定，而小鴨應自動跟隨。

由 Android 9 起，Android 已開放給用戶設定手機整體的夜間模式，原生 Android 9 只放在 developer options 內，但有指小米等已正式開放，因此，現時在 Android 9，整體夜間模式是否讓用戶設定，視乎 developer options 有否開啟或個別 ROM 而定，沒有標準。

由於兩者是同一設定，會互相干擾，但小鴨無法簡單地偵測系統有否開放整體的夜間模式設定，只能由用戶自行選擇，Android 9 或以上用戶，若經由手機系統設定夜間模式，請將小鴨的夜間模式，設定為新增的「跟隨系統」，以免互相干擾。日後若系統正式推出夜間模式設定，會自動跟隨系統，此選項將移除。

版本編號

為方便分辨 Google Play 的版本及完整版，Google Play 版本在「關於」對話框中，版本編號會加入「g」為後綴，如 0.2.16g，完整版則維持原有編號。

in terms of possible delay and uncertainties in Apps publication.

After the new Google policy to restrict functionality of third party apps using call-log / SMS permissions is in force since March 2019, Google only permits Apps with specific “core functionalities” to access those permissions on Google Play.

The “core functionality” in this case is call blocking, which has previously been verified by the Google Play Support team for the previous version of the App in question.

These rejections were received minutes after re-submitting App updates (and thus likely made by bots), and continued even after testing instructions and Youtube videos were provided in declarations.  Seems that in future updates, there will be extra efforts / delays to convince the Robot-In-Charge that the developer has not removed the core functionality of an App in updates (which I cannot think of a sane reason for doing so).

以「小鴨幹線」超過100名用戶使用的機款的活躍用戶數字，統計了不同Android品牌活躍用戶的大概分布，結果如下 :

註: Nokia，華為及小米部份機款已列為不兼容，或會影響其數字。

生產力促進局轄下香港電腦保安事故協調中心（HKCERT），與國家互聯網應急中心（CNCERT）合作，因應 CNCERT 所提供的分析，在2019年4月發表的香港熱門Android Apps 保安風險報告報告，將《蘋果動新聞》及另外數個應用程式，列為高風險應用程式 [1]。

小鴨作者得悉後，到 HKCERT 網頁看看背後的理據，即報告附錄 2 的「高風險應用程式深度分析」，學習一下。畢竟政府有計劃，鼓勵電話攔截App到「政府認可或指定的獨立認證機構」取得認證，而政府心目中的獨立認證機構，正正就是生產力促進局 [2]。

但竟然，所謂深度分析，極其兒戲，「高風險」的罪證充其量只是對 App 反編繹得出的 Java 源碼做了些 keyword match，不但看不出有考慮程式行為就其性質而言，是否相稱及必要，部份分析更犯下與事實不符的低級錯誤，顯示分析者對 Android 系統以至 Java 系統，缺乏進行這類分析所需的基本認識，更顯示從 CNCERT 交到 HKCERT 、再到 HKCERT 發表報告，過程中似乎沒有做基本把關工作。

以下為報告中所指，App的高風險動作

• 獲取SIM卡服務供應商名稱
• 獲取SIM卡狀態
• 讀取手機號碼
• 通過連線訪問網絡
• 獲取網絡資料
• 獲取手機設備資料
• 傳送手機資料

檢測結果截圖

而在「深度分析」中，HKCERT / CNCERT 列出反編繹的 Java 源碼，以顯示 App 進行有關行為的「罪證」。下文中的源碼截圖來自該「深度分析」。

指鹿為馬，低級錯誤

指「蘋果動新聞」有「讀取手機號碼」的部份:

指另一隻App「RunRace 3D」「讀取手機號碼」的部份:

以上完全是不符事實的低級錯誤，上述 getLineNumber() 明顯是屬於StackTraceElement 這個 class，這是Java 語言中是用作處理 Stacktrace [3]， 通常用於程式發生錯誤後，處理報錯，StackTraceElement 下的 getLineNumber() 是用以獲取有關出事的程式碼在 Java 源碼中的行號(Line Number)，與手機號碼風馬牛不相及。

分析(檢索?)人員似乎混淆了上述在 Java 語言中的方法，與及在 Android framework 中真正可用於讀取手機號碼的方法，即是 TelephonyManager 這個 class 之下的 getLine1Number()。注意名稱串法有個「1」字 [4]。

其實懂Java的人一看有限的前文後理，大致已看出是和 stacktrace 處理有關，而非讀取手機號碼。退一步說，所需的 TelephonyManager 這個 class 根本沒有出現，能出現這種事實錯誤的唯一合理解釋，是有關人員單是對源碼進行簡單的關鍵字檢索，而且還要串錯字 (getLine1Number 變成 getLineNumber)。

抽樣查看HKCERT之前的報告，亦發現此錯誤已非第一次出現。

合理及常用功能，不求甚解便列作高風險

對這些App的另一高風險罪行，是「通過連線訪問網絡」:

「蘋果動新聞」的源碼:

上述源碼確實是與從網絡取得資料相關（處理 HTTP 請求後返回的 status code），但問題時，為什麼存取互聯網，對一隻明顯是用於在網上看新聞的App而言，會是高風險 ? 事實上，在 200隻熱門App中，有幾多隻是不會存取互聯網的 ?

這份「深度分析」沒有動態分析以找出 App 上傳什麼內容到什麼地方的行為（如透過截取DNS請求或程式對外通訊），並根據 App 性質找出什麼上傳行為是不適當，單單是靜態地檢索了程式碼內含 HttpURLConnection 這個 Java 程式存取網絡用的 class，便列「通過連線訪問網絡」作為 App 屬高風險因素，這類「分析」完全無意義（其實單看該App需要 INTERNET 授權，已知程式可以存取網絡），更帶來誤導效果。

順帶一提，作者亦發現，「深度分析」指「Soul Knight」有「通過連線訪問網絡」，所列出的源碼卻是和網絡不相關的，

程式碼是在開啟 Android APK 檔內 (應屬廣告商程式庫) 的 Asset，或已存在手機內的指定檔案。不論是不認識 Android / Java 或是全段引用錯誤，都是不應出現的嚴重問題。

另一「高風險」罪狀是「傳送手機資料」，所列例子為

「蘋果動新聞」的源碼:

「Soul Knight」的源碼:（三國殺亦類似）

兩者其實是 Android 正常的 Intent.ACTION_SEND 機制 [5]，用處是將資料由一隻 App share 到另一隻 App，而後者會開啟。例如，「蘋果動新聞」那段，應是將資料 share 給 Facebook Messenger 而開啟後者（可能處理用戶按下 「Share to Facebook」 後的工作）。這段源碼亦很可能是 Facebook 提供的程式庫 MessengerUtils  中的一部份 [6]，被納入「蘋果動新聞」內。

而「Soul Knight」及「三國殺」所引用的那段源碼，根本是屬於官方 Google 提供給 Android 開發者使用的程式庫 (android support v4 library) 中 android.support.v4.app.ShareCompat 類的源碼 [7]，大部份 Android App 都會用這個程式庫，竟被拿來當作高風險，再次印證 (1) 所謂分析可能只是搜索 “android.intent.action.SEND” 這組字，一出現便當高風險，不問前文後理及App性質，(2) 分析者對 Android 編程的認識。

和上面網絡權限一樣，分析只代表程式含有可能進行 share 到其他 App 這項 Android App 極常用的功能，沒有找出是在什麼情況 share 及有何不恰當之處，卻將此列為 App 的高風險因素，帶來誤導效果。

選擇性預警，未能讓人看見公正性

所謂深入分析中，較與私隱相關的風險因素，是「發現」有關程式存取了「SIM卡資料/網絡資料/手機設備資料」，實際來說包括以下各項:

• SIM卡服務供應商 MCC + MNC 碼 （發SIM卡的供應商，讀取此資料要 READ_PHONE_STATE 權限）
• 流動網絡供應商 MCC + MNC 碼 （正使用的網絡商，讀取此資料要READ_PHONE_STATE 權限）
• 手機 IMEI 碼 （手機獨一的ID，讀取此資料要 READ_PHONE_STATE 權限）
• Wifi 的MAC Address （亦可當作手機獨一的ID，讀取此資料要ACCESS_WIFI_STATE 權限，一般經 wifi 上網不用此權限）

假設讀取上述資料都是用作上傳，這些確實會帶來私隱風險，尤其是可當作手機獨一 ID 的後兩項資料，因為 App 雖然不能單靠這些資料直接得悉用戶真實身份，卻可讓不同的 App 以及藏身 App 內的不同廣告商及資料分析商，共同追蹤及分享用戶在不同 App 的一舉一動，建立用戶的詳細資料profile，以收集數據及作針對性廣告。

但不幸的是，App 的「業界」使用此等 ID 追蹤用戶，極為普遍，內含廣告或分析軟件的 App，很多時都會要求相關權限，供廣告商使用。這是另外一大議題。

講返份報告，這次所列舉的行為，大致應沒有事實錯誤（但部份只根據開發者自訂的method名稱來判斷，仍是不謹慎的做法，亦再再反映分析只是 keyword 檢索的程度）。 問題在於，由於這是「業界」普遍問題，HKCERT 所檢查的最受歡迎的本地 App 當中，應有很多都會有同樣行為。

為進一步驗證，作者找了 HKCERT 所提及，本地50隻免費App當中的(1) 淘寶lite （com.taobao.htao.android）及 (2) Alipay HK wallet （hk.alipay.wallet），再加上是次主角 (3) 蘋果動新聞（com.nextmedia）以及另一家同類但不在HKCERT名單的 (4) 某報（com.nxws.on），於內地的 Sanddroid 沙盒檢測的比較結果，比較一下上述較具私隱風險資料的取用情況，詳細結果鏈結如下：

Taobao
http://sanddroid.xjtu.edu.cn/rep … D5C1FF1E6D0AAF4755B
Alipay
http://sanddroid.xjtu.edu.cn/rep … F276B606EF1B7FBF4EC
蘋果動新聞
http://sanddroid.xjtu.edu.cn/rep … A8DD3FDA784BF173245
某報
http://sanddroid.xjtu.edu.cn/rep … 608E6BA24B16E01F2FC

下表為相關總結：

就私隱關注而言，上表列出的只是問題的冰山一角，（有的如 Alipay 會直接取得 /proc/cpuinfo 等，HKCERT 報告沒有無提及便從略），上表只是希望說明，單就 HKCERT 報告所謂深度分析中有提及的「高風險行為」，很多 Apps 因用戶追蹤等原因，都會「觸犯」。而在 VirusTotal 結果中，像上面 Alipay 及 HKCERT 報告所述「蘋果」App 的情況，即是只有極少數防毒商的掃瞄結果為 positive（尤其是較著名的 anti-virus 廠商都未有顯示問題的情況），正常應理解為 false positive，因為有可能個別廠商用作 scan 的 signature 與 Apps 有巧合相同的code。

同被 HKCERT 檢查的 Alipay，在 VirusTotal 測試有 2 家防毒軟件 scan 到有 Trojan，但 HKCERT 報告沒有就該 App 發警告

因此，即使以 HKCERT 報告中這樣粗疏的手法，去檢視報告聲稱有檢查的數十隻 App，亦很難想像只會得出僅有蘋果動新聞及其他少數 App，須特別發出預警報告的結論。

當然，或許有在所謂「深度分析」中沒有提及，不為人知的原因及準則，導致 CNCERT 及 HKCERT，只挑出上述的 App 發出預警，但果真如是，HKCERT 作為100%政府資助，具官方性質及有專業權威性的機構，在此事上發表一些會嚴重影響品牌聲譽的報告，但背後不但錯漏百出，求其了事，更欠缺透明及未能讓公眾看到秉行公正，實在很有問題。

公眾有理由提出，這項所謂分析工作有否拿公帑給 CNCERT 進行，還是義務性質？若是單純做毫無真正分析的反編繹源碼 keyword search 及將 App 交到 VirusTotal 檢查（任何人都可免費提交），機械式得出無意義及具誤導性的預警，找 CNCERT 以至 HKCERT 自己做項工作目的及意義在哪裏？

話說回頭，如果政府就提高電話攔截 App 質素的實際措施，就是進行這樣質素，以及看不到公正性的驗證，作者為免浪費公帑，不參與也罷。而若公眾按這種驗證的結果來選擇App，作者亦只有一句：自求多福。

下一篇【HKCERT 列「蘋果動新聞」為高風險 (二) 之 三重巧合 ?】，在發表時機上，看看今次報告巧合之處。

註1: 本文整理及補充了作者於 HKPEC 相關 Post 的討論 : https://www.hkepc.com/forum/viewthread.php?fid=110&tid=2497432&extra=&page=1

註2: Android-apk.com亦有一份相關分析文章，更詳細解釋有關謬誤。HKCERT 報告的錯誤對懂 Android 及 Java 的讀者，實在太明顯。

後記

報載「生產力促進局」對蘋果的反駁，有如下回應：「檢測應用程式機制自2013年沿用至今，報告一直基於披露事實原則，同時會列出由國際惡意軟件分析機構 VirusTotal 上不同的防惡意程式引擎所進行的偵測結果和資料，供流動應用程式用戶作額外參考。協調中心並不會對個別結果作出分析或評論」。

作者要指出，(1) 撇除如上文指出，報告連事實都攪錯的問題，報告當中提及「不良行為」，相關 App 是否已被下架等，強烈暗示有關App有問題，英文版更直接指明，有關 App 有 “malicious activities”。而報告亦沒有全面披露其他 App 的檢查結果作比對，只是一面倒地披露相關App的「風險」，更無闢明所謂「風險」的意義（這方面可以比對消委會的產品報告），因此絕對難以理解這是一份僅屬陳列事實性質，可供公眾自行作持平結論的報告 。(2) 報告由 HKCERT 發出，內文指明「我們(HKCERT)與CNCERT合作，對從 Play 商店下載的應用程式進行惡意及可疑行為檢測」，即檢測名義上是合作進行的，但一有問題立刻極速割蓆，對用自已名義發出，放在自已網頁的東西，甚至可能是動用公帑資助及有責任監察的分析，被指出有問題後，不但沒有試圖澄清及檢討，更擺出事不關己，一點責任也沒有的態度！

看來這事所披露的，已非個別基層檢驗人員粗疏塞責的問題，而是公眾應如何看待，以後 HKCERT 以至生產力促進局發出的東西，公信力有多少，以及所涉公帑是否用得其所的問題。

截圖為英文版的「深入分析」，直指相關App有惡意活動

參考

[1] HKCERT 報告 https://www.hkcert.org/my_url/zh/blog/19043001，註: 原報告已移除，鏈結至 Internet Archive 存檔。

[2] 見立法會資訊科技及廣播事務委員會 2018年4月9日會議，會議紀要19段 https://www.legco.gov.hk/yr17-18/chinese/panels/itb/minutes/itb20180409.pdf

[3] StackTraceElement 文件見 https://docs.oracle.com/javase/7/docs/api/java/lang/StackTraceElement.html

[4] TelephonyManager.getLine1Number() 文件見 https://developer.android.com/reference/android/telephony/TelephonyManager.html#getLine1Number()

[5] Android SEND 機制見 https://developer.android.com/training/sharing/send

[6] Facebook MessengerUtils api 見 https://developers.facebook.com/docs/reference/androidsdk/current/facebook/com/facebook/messenger/messengerutils.html/

[7] ShareCompat 文件見 https://developer.android.com/reference/android/support/v4/app/ShareCompat

上文有一個角度未有考慮，就是香港電腦保安事故協調中心 (HKCERT) 把「蘋果動新聞」列為高風險的時間。

檢測當局早應知悉「蘋果動新聞」的所謂風險因素

HKCERT的「香港地區 Google Play 商店應用程式保安風險報告」是按月發表的，翻查 HKCERT 一年來的檢測名單，發覺「蘋果動新聞」一直都在檢測上，不過以往檢測的是不同的舊版本。見下表左方第1及第2欄。

於是，作者抽查一下在 Sandroid 沙盒對數個舊版本（4.5.0，4.7.0，4.9.0）的分析（詳細報告鏈結在上表最右欄），發覺上文所述，HKCERT 就今次5.0.1版認為是高風險的各項行為，在這些舊版本中同樣存在，見上表各項（當然連接上網這類基本功能亦一樣，從略）。

換句話說，HKCERT 在 2019年4月對「蘋果動新聞」發警報所聲稱考慮的技術因素，在此前的12個月，事實上一直存在。 HKCERT / CNCERT 每個月都有分析「蘋果動新聞」，所以亦應一直知悉情況。

既然如此，有什麼因素，令 CNCERT 及 HKCERT 不一早發出預警，而要選擇在2019年4月才發出對該App的預警？

巧合的是，眾所周知，蘋果剛巧就在2019年4月轉型為登記制，另一陣營隨即發表不利蘋果App的報導，希望阻嚇公眾登記，同月卻發生該網獨家報道某八卦新聞，而令登記人數大幅上升。

另外，HKCERT 的報告，一直順帶提供 VirusTotal 的掃瞄結果，在4月「蘋果動新聞」的預警中，附上的掃瞄結果鏈結，顯示其中一家國內的防毒商「安天」（Antiy），掃到蘋果App內有惡意程式。

但作者發覺，HKCERT 在4月報告聲稱所測試「蘋果動新聞」5.0.1版本，在VirusTotal 的給果，（和之前4.5.0，4.7.0，4.9.0版本一樣）是完全沒有發現問題的，當中包括「安天」。見上表鏈結。

2019年4月報告截圖

錯誤上載 App 版本

好奇之下，再細看 HKCERT 報告提供的VirusTotal 鏈結，究竟是什麼問題導致結果差異，發現另一個報告的事實謬誤，就是原來是拿了 5.0.0 版而非所稱的 5.0.1 版，上傳到 VirusTotal 測試 !

翻查 HKCERT 以往的報告，每月都在當月15日對各App取樣，而 4 月報告亦一如以往，註明取樣日期為 2019 年 4 月 15 日，所以各App 選擇所測試的版本應是按規則而非隨意。該日「蘋果動新聞」已推出5.0.1版本，但為什麼會拿了4月初推出的前一版到 VirusTotal 測試，但在報告內又沒有標註 ?

5.0.0 版及 5.0.1 版之差看來是細節，但魔鬼就在這裡，因為「安天」亦是不遲不早，僅對 5.0.0 版偵測出附有惡意程式，上表其他各版本，包括原應使用的 5.0.1 版，均沒有問題。

再看看報載 HKCERT 對報告工作流程的描述 :「中心[HKCERT]自2013年7月開始與CNCERT合作，每月從 Google Play 下載 200 款最熱門和最新的流動應用程式進行惡意及可疑行為檢測，整理 CNCERT 提供的分析結果後公佈，… ，中心 [HKCERT] 同時會列出由國際惡意軟件分析機構 VirusTotal上不同的防惡意程式引擎所進行的偵測結果和資料，供流動應用程式用戶作額外參考，不會對個別結果作出分析或評論」

此段的理解，似乎是想強調，CNCERT的分析和 VirusTotal 的掃瞄，兩者是獨立進行的。 「風險報告」屬分析結果部份，由 CNCERT 提供，而 VirusTotal 的掃瞄則是根據 CNCERT 的分析結果，另行上載到 VirusTotal 進行，以便在分析結果內同時列出，供額外參考。

三重巧合 ?

若是如此，則須出現三重巧合，才會出現於蘋果動新聞剛轉型、被另一政治陣營攻擊的月份，HKCERT 發表該 App 附有惡意程式的結果：

1. CNCERT 一直知悉蘋果動新聞有（根據深度分析中的所謂）高風險行為至少一年，但剛巧選擇在該月才發出警報，
2. 「安天」的掃毒軟件，亦不早不遲，僅對該月初推出的5.0.0版，偵測到惡意程式，及
3.  CNCERT / HKCERT 錯誤地在取樣日之前，預早下載了 5.0.0 版，而非報告所述取樣日期的5.0.1版，到 VirusTotal 測試。

沒有(1)，「蘋果動新聞」不會在此時上榜，而(2)及(3)若非同時出現，報告雖會顯示該 App 有行為會引起私隱風險，但同時「證明」沒有惡意程式或「毒」，效果有相當分別。

無論如何，事到如今，對一大部份公眾而言，一則新聞平均只有8秒 attention span，「官方報告踢爆「蘋果」App有毒」入腦，「蘋果」的澄清只有蘋果讀者見到，preaching to the converted。總之，損害已經造成。

而 HKCERT，一被質疑即劃清界線，只是依足程序外判再搬字過紙，不分析不評論不負責，當然亦不上身。

不要再浪費公帑

這種以字眼檢索當作深度分析，不論App性質連上網都當風險的報告，對所有App來說都可謂欲加之罪何患無詞，而對什麼App發警告，何時發警告，全無透明準則，有極大任意性，加上分析全在內地，即使有明顯事實錯誤，受報告損害的App均追究無門。

而 VirusTotal 測試羅列多家廠商掃瞄結果，當中廠商可能良莠不齊，HKCERT 僅列出所謂偵測度，各廠商一人一票，不加解釋，根本無助公眾正確理解及評估惡意程式風險，反而很容易造成誤導。另一方面， HKCERT 挾半官方名義，令報告有一定權威性及新聞價值，但實質 HKCERT 對內容看來毫無承擔。HKCERT 穩收公帑，但其開支又缺乏如政府的監察程序及透明度。這種在多個層次均出現權責不對稱的機制，對引致這些報告質素低落，錯漏一大堆，不無關係，當然這次亦將無人問責，不了了之。

若不作徹底改革，提高檢測的專業性及問責性，繼續讓 HKCERT 負責此類工作，除了浪費公帑，更誤導公眾，百害而無一利，亦難以排除有可能被人利用，作為影響市場以至作政治打擊工具的疑慮。

5月7日更新：蘋果已向 HKCERT 發律師信要求停止發表失實陳述及澄清[1]，HKCERT當晚指遵從法律意見從其網頁移除報告，但沒有承認報告有問題。希望法律行動有助消除這種不負責任更誤導公眾的報告。

5月8日更新：報載 HKCERT 承認報告有誤，但只限於發出律師信的蘋果旗下的 App，聲明如下:

香港生產力促進局屬下‪香港電腦保安事故協調中心 (HKCERT) 每月發布《‪香港地區 Google Play 商店應用程式保安風險報告》。HKCERT 重視每項檢測的準確性，對所有檢測項目及機構持中立態度。HKCERT 收悉有關 2019 年 4 月份《‪香港地區 Google Play 商店應用程式保安風險報告》的查詢，即時對該報告結果進行詳細技術分析，發現就《蘋果動新聞》應用程式所作的分析結果存有差異，同時主動與有關檢測機構查詢，並獲其證實有誤。在徵詢專業意見後，已即時採取相應措施，並在網站上移除報告。HKCERT 重視公眾意見，對是次事件深感抱歉，我們承諾往後定會更審慎處理各項檢測、加強技術分析以及審視相關報告機制，謹此感謝各界對是次事件的關注。

（解讀: 唔係我錯，係我俾 CNCERT 跣咗，重係憑自己分析發現嘅。同埋講明，我而家係主動收返份報告，唔係俾你律師信嚇到。）

至於之前以相似的「有連接上網」「有 share facebook」等罪名，對其他 App 發出的警報呢?

邊隻 App 請得起律師「查詢」一下，咪「即時」幫你進行詳細技術分析同向「有關檢測機構」澄清，還你公道囉。

[1]蘋果新聞，2019年5月7日：生促局報告指控動新聞app屬高風險 《蘋果》發律師信直斥鹵莽失實

「小鴨幹線」已於9月8日，因被指不符有關「惡意軟件」政策而遭 Google Play 下架，同日作者被吊銷開發者戶口。Google Play 中亦顯示小鴨App存在風險。作者已於同日按機制提出了上訴要求及要求澄清。作者相信這是 Google 的惡意軟件偵測，因小鴨作為背景攔截軟件，可能與某類型惡意軟件有相似的權限要求及運作模式，而出現假陽性的錯誤。以下交代詳情。

“Headuck Call Blocker” was removed from Google Play on 8th September for allegedly violating the “malware” policy.  The App author’s developer account was also terminated on the same day. Google Play Protect now shows that the App is harmful and recommends users to uninstall it.  On the same day the author has filed an appeal and requested clarification under Google’s appeal mechanism. The auther believes that this is a false positive case of Google’s malware detection AI, considering that the background call blocker might, by its nature, share some patterns of permissions and usages with some categories of malware.

常見問題及建議請参閱另文。

Please refer to this article for FAQs and recommended actions.

Google 的電郵

「小鴨幹線」於9月8日上午，在事前沒有任何警告下，收到來自 Google Play Support 的 2 個 email，第一個表示因小鴨觸犯 「惡意軟件」（malware） 政策，已把「小鴨幹線」程式移除 （用戶安裝數及評語等全部刪除，即永久下架)。

Hi Developers at Headuck,

After a recent review, 小鴨幹線 DEV (香港廣告及詐騙來電攔截App – 免費無廣告) (com.headuck.headuckblocker.dev) has been removed from Google Play.

 

Publishing status: Suspended Your app has been suspended and removed due to a policy violation.

Eligibility Issue by versions Version(s) Eligibility Issue APK:26 MALWARE Your app is not compliant with the Malware policy. We don’t allow apps with any code that could put a user, a user’s data, or a device at risk.

一如以往小鴨及其他開發者收到的下架通知，email 中除了 “not compliant with policy” 外，沒有任何違規詳情。

第二封 email 進一步表示，吊銷小鴨的開發者戶口，更指出不要試圖登記新的戶口，亦不會重啟原有戶口，換句話說是無限期封禁。

Hi Developers at Headuck,

This is a notification that your Google Play Developer account has been terminated.
Reason for termination: Violations of the Developer Program Policies and Developer Distribution Agreement.

As explained in our Enforcement Process, repeated or serious violations of our policies may result in the termination of your Google Play Developer account and related Google Play Developer accounts.

You can visit the Developer Policy Center to better understand how we enforce Developer Program Policies. If you’ve reviewed the policy and feel this termination may have been in error, please reach out to our policy support team.

Please do not attempt to register a new developer account. We will not be restoring your account at this time.

The Google Play Team

第二封 email 亦沒有任何詳情，不過時間上顯然與小鴨被指違反 malware 政策有關，亦有可能與之前下架累積了的紀錄有關。

究竟小鴨為什麼被指含有惡意軟件呢，又犯下什麼大罪，要在沒有警告下永久從 Google Play 封禁?

Google 的惡意軟件政策

先看被指違反的 Google 惡意軟件政策，當中惡意軟件包含十多大類﹕

• 後門 – 程式碼讓攻擊者以遙控方式在裝置上執行不必要且可能有害的操作。
• 帳單欺詐 – 程式碼有意以欺詐方式自動向使用者收費。
• 商業間諜軟件 – 程式碼未經充分通知或同意，即將裝置上的個人資料傳送至其他裝置，並且不會持續顯示相關通知。
• 拒絕服務 (DoS) – 執行拒絕服務 (DoS) 攻擊。
• 惡意的下載程式 – 下載其他惡意程式。
• 非 Android 威脅 – 對其他平台有害。
• 仿冒詐騙 – 泛指會偽裝來自可信的來源，要求取得使用者驗證憑證或帳單資料。
• 進階權限濫用行為 – 程式碼會破壞應用程式沙箱、取得進階權限，或者變更或停用核心安全性功能的存取權，藉此影響系統的完整性。
• 勒索軟件
• 有 root 權限 – 有 root 權限的非惡意與惡意程式碼之間有分別 … 有 root 權限的惡意應用程式不會通知使用者將在裝置上進行 root 權限操作，或者在預先通知使用者將進行 root 權限操作時，同時執行適用於其他 PHA 類別的其他操作。
• 垃圾內容 – 向使用者的聯絡人傳送垃圾訊息，或使用裝置轉發垃圾電郵。
• 間諜軟件 – 未充分告知使用者或徵求同意的情況下，傳送裝置上的個人資料 … 舉例來說，程式碼會在未披露相關資料或使用者不知情的情況下傳送 通訊錄  … 通話記錄。
• 木馬程式 – 看起來無害 (例如聲稱純粹是遊戲的遊戲)，但會對使用者執行不當動作。

由於「小鴨幹線」並無包括任何第三方的非開源軟件，作者很肯定不會錯誤地把不當軟件（如有後門的廣告程式庫）納入 App 內。小鴨沒有收費或要求任何認證，當然亦沒有勒索、攻擊或發垃圾訊息（這些相當易驗證），而且網絡存取亦相當有限（從hkjunkcall 下載名單，回報垃圾電話，及小鴨 server 下載防騙訊息，更新小鴨顯示訊息及一響收線IDD字頭等），與惡意行為毫不相干。單從 Google 惡意軟件政策，實在找不出頭緒。

小鴨如何成為「惡意軟件」

當然， Google 事實上不會用真人逐隻 App 檢查是否「惡意軟件」，而應是自動掃描並按一些不透明的準則（ 俗稱 AI ）決定 App 是否有害。此「AI」顯然沒有真正理解 App 功能以及藉上述政策分析 App 內容的能力（ AI 還未發展到這地步）。Google 最有可能採用的方法，是收集以往被審核為「惡意軟件」的 App 與其他非惡意軟件為樣本，透過抽取最能分辨兩者的特徵，例如權限，使用什麼API，以至程式外的特徵如有否收費，作者背景（是否大公司?），下載數量，用戶評語，以至 icon，screenshot，甚至 Google Search 取得的網上連結數之類，去訓練 AI 模型，以將 App 區分是否「惡意軟件」。

從這個角度，推測「小鴨幹線」可能與上述「惡意軟件」有一些共通元素：

進階權限：小鴨為顯示彈出通知﹐有使用其他程式上繪製權限，亦使用存取通知以作靜音及（若其他方法失效）模擬藍芽耳機掛線。例如「惡意軟件」可以用繪製權限，假扮其他App功能以騙取用戶。雖然較新版 Android 已要求明確授權，但舊版 Android （如 5.1 以下）仍受影響。

root 權限：以往部份機種要 root 權限才能掛線，以及通話中將新來電掛線。（root方法須使用者明確選擇掛線方式及授權，方可使用，但作為攔截程式當然不會每次取 root 掛線前彈出通知徵求同意。）

使用通訊錄及通話記錄：或許與「間諜軟件」相似，在背景（非用戶操作中的程式）讀取這些記錄。

此外，小鴨亦有使用 native code（包括 LMDB 資料庫引擎及用以核對下載資料數碼簽名以確保完整性的加密程式庫，兩者都是開源的，亦已在 App 內列出），而「惡意軟件」亦可能使用 native code 以增加反編繹難度，作隱藏之用。

當然其他攔截軟件或許同樣有相關權限，但未必與小鴨有同樣的特徵及功能（例如小熊早已移走 root 功能），也許小鴨一些程式外的特徵，如安裝數字等，亦與「惡意軟件」的樣本較刎合。

不過上述「特徵」，並非新增，例如 root 權限，native code等，自小鴨推出已經一直存在，而自去年 3 月經人工批核獲准繼續使用電話權限以來，小鴨只在本年 6 月更新一次（即第一封電郵所指，內部版本編號為 26 的 0.2.17 版），而且沒有加入新功能，只做了符合 64-bit 要求的修訂及小量 bug fix。

因此，有理由相信，這種 AI 模型的分類「準則」，會隨模型更新或訓練樣本不同，而隨時間改變。小鴨在 6 月的更新，雖然沒有大幅改變本身的原有特徵，但可能因而觸發了 Google 以新的「準則」掃描舊有的特徵，得到不同的結果（當然亦可能與更新沒有直接關係，Google 都會定期對 App 進行掃描）。

球證，旁證，足協 … 全部都係 AI

以「AI」輔助找出「惡意軟件」未身並必有問題，但 Google Play 一直為人詬病的，是這類對開發者很大影響的決定（如主要靠 App 在 Google Play 賺錢的公司，取消戶口已可以執笠），似乎沒有經人手審核，便自動作出。甚至連開發者上訴等機制，由於提出問題往往只獲空泛的官方回覆，亦被指可能是全自動進行，待遇據稱與 Apple 以至同是 Google 的其他產品，有相當分別。

可參考以下於 2008 年尾一間小型開發公司講述其被取消戶口遭遇，並列出一系列類似個案。該文得到相當迥響。

https://android.jlelse.eu/google-just-terminated-our-start-up-google-play-publisher-account-on-christmas-day-5cb69a454da0

（特別一提的該文提及的封禁連坐法，一人戶口被封，可能會牽連相關僱主，同事的戶口都被封，並可以連還引伸。以 Google 擁有的資料來說，取得這些關係資料以作 enforcement 並不困難。）

跟進

作者會在本文跟進上訴進展，目前請在此頁下載完整版。

Link to English version

問1：為什麼會出現「小鴨幹線」是「有害程式 / 可能會擅自註冊定期付費服務，造成帳單費用增加」的警告?

答1：Google Service 內置並預設啟用的 App 惡意程式掃描機制（Google Play Protect），誤將「小鴨幹線」分類為帳單欺詐的惡意程式（malware)。詳細情況在此文。

問2：有何證明是 Google Play Protect 誤報而不是「小鴨幹線」真的藏有惡意程式?

答2：Virus Total 此頁綜合了數十隻掃毒服務對Google Play下架前同一版本的掃描結果，全為陰性。有懷疑可到一些第三方 Google Play mirror / archive 如 APKMonk，核對掃描的是同一 Hash 的版本。

問3：Google Play Protect 是 Google 官方掃毒機制，以Google實力，結果是否應較其他掃毒服務更可信?

答3：剛剛相反，Google Play Protect 無論假陰性（偵測不到惡意程式）及假陽性（將無害程式列為有害），比率都遠較其他防毒掃描為高。這是因為 Google 是靠機械學習（或統稱 AI）而不是傳統的人手分析去偵測惡意程式，根據長期進行防毒軟件比較的 AV-test 最新結果顯示，Google Play Protect 假陽性比率往往亦比同行高十多至數十倍，但很多月份只能成功偵測6，7成的惡意程式。其他報導： T客邦（中文），Tom’s Guide(英文)

問4：我選擇了不刪除「小鴨幹線」，但手機一直彈出警告?

答4：可行方法：若你只從 Google Play 或可信任的來源下載程式，可以在設定>保安中，停用 Google Play Protect，（新版 Google Play 亦可到達此頁）。因為 Google Play 的程式在供下載前已經掃描，日後「復陽」風險不高。如仍不放心，可安裝其他更可靠的防毒程式。不過請留意，有回報指 Google Play Protect 仍可能終止小鴨背景運作，需要留意一下；

而建議方法，是到 http://blog.headuck.com/?p=215 ，下載及安裝「完整版」小鴨，過程中不用 delete 原來的 Google Play 版本，以讓設定及資料繼續保留。據悉目前 Google Play Protect 尚未對「完整版」彈出警告，但此版不會自動更新，要留意日後自行更新。

問5：「完整版」和 Google Play 版本有何不同?

答5：Google Play 版本（0.2.17g）在兩年前 兩次被Google 下架，及 Google 加強規限 Google Play App 的來電權限後，被迫刪去部份功能，如攔截後關上快速關上屏幕以省電，及刪除來電紀錄。而沒有刪去功能的完整版（0.2.17），APK 繼續在小鴨 blog 供下載。

目前若自行下載「完整版」安裝，在有更新時不會自動更新及發出通知，不過小鴨可在App內首頁提醒，亦可以留意本 blog。日後再考慮加入更新通知及方便更新的功能。

問6：會否將「小鴨幹線」放到到其他 App Store?

答6：目前尚未詳細研究，但據了解三星是 App 用到三星特有功能才可上架，因此未符資格，而華為本身 AI 都會殺小鴨，放上去似是自找煩惱。

問7：有沒有辦法支持「小鴨幹線」?

答7：感謝支持，「小鴨幹線」因為 Google Play Protect 誤報，預計導致大批用戶刪App，但「小鴨」在此的澄清可能只有十分一的用戶見到。若你介紹過親友或長者使用本 App 或協助過他們安裝，請提醒他們有關本頁的資訊以作考慮，或幫助他們安裝「完整版」，謝謝！