當防毒軟體說你的 app 有病毒時

當 app 開發者真的很辛苦，app store 會用下架來嚇你，廣告平台會用倒閉來陰你，連防毒軟體都會說你的 app 有病毒來搞你。

別笑、我真的被防毒軟體搞過好幾次，store 上滿是 "Fxxx 有病毒別下載" 的留言，透過 email 來罵你的信，更是如雪片般飛來，當下心想如果這些信都是訂單該有多好。

如果你將來和我一樣遇到這無妄之災，第一時間先叫你的使用者給那個防毒軟體一顆星（誤），再來透過底下這個網頁內提供的各家防毒軟體 false positive (false alarm) 回報系統回報。

http://www.techsupportalert.com/content/how-report-malware-or-false-positives-multiple-antivirus-vendors.htm

希望你不會用到。

繼續閱讀全文...

千萬不要用加速 apps

最近看到 HTC Boost+ app 強調可以透過清除背景程式的方式，來達到加強手機效能的目的。 其實市面上這類加速 apps 不僅是做白工，啟動程式變得更慢，最糟的是讓手機更耗電。

我剛簡單做個實驗，用他的加速功能清除記憶體 (我的手機是Nexus 6)，清除後號稱清出 700 MB。 十分鐘後再打開加速功能，你會發現原先號稱清除的記憶體空間幾乎都長回來了。

為什會這樣？

原來這些佔用記憶體的背景程式有分三種類型︰
1. 常駐程式 (如 facebook)
2. 會自我啟動的程式 (如 gmail)
3. 不用的程式 (按 BACK 或 HOME 跳離)。

如果你手動用這類加速 apps 殺掉這些背景程式，幾分鐘內系統會自動重啟 1, 2 類的程式，只有第三類背景程式才真正可被清除，這解釋我先前的實驗結果。 所以如果你頻繁地用加速 apps，導致殺掉又重啟程式的不斷循環，不僅是做白工，還會讓手機更加耗電。

你可能會說他還是有殺掉第三類背景程式啊。 要回答這個問題，要先知道系統為什麼要保留第三類背景程式。

原因是，當記憶體空間還充足時，系統保留第三類背景程式，就是為了讓你再次執行該程式時，不需重啟程式。 這是系統內建的加速啟動機制，結果反而被這些所謂的加速 apps 變得慢速。

其實當記憶體空間不夠時，系統會自動依照 3, 2, 1 的順序逐一殺掉背景程式騰出空間。 所以，你根本不需要這些加速 apps。

這些 Android 記憶體空間管理機制，做手機的 HTC 比誰都懂。

HTC 今天推出這樣的 app，我實在很失望。

更多討論也可以看我 Facebook 上的文章。

繼續閱讀全文...

在 Android 中，有哪些 IPC 方法？

前不久在我的 Facebook 上，問了底下這個問題：

在 Android 中，當 process A 要向 process B 索取動態 parcelable 資料 (動態資料指，資料是經由計算所產生) 時，你會用甚麼方式來做？

1. 最常見的方法是 Service + AIDL (http://developer.android.com/guide/components/aidl.html)。

還有誰要貢獻其他方法？

最後找出將近十種方法，還有範例與文件，有興趣的自行點下面連結參考。

https://www.facebook.com/samlu128/posts/10204283071555842

繼續閱讀全文...

在 Android M 上如何檢查我的程式已取得要求的權限？

How to check if a requested permission has been denied by users?

Android marshmallow 以上的手機開始允許使用者取消程式所要求的某些權限，從使用者的角度來看，這個新功能當然很好。不過從開發者來看，這卻是一個災難的開始。

為什麼？因為我就遇到使用者之前曾經手動取消我的程式所要求的某些權限，過了一陣子，他來信抱怨某些功能無法正常執行。查了半天，原來事實上是，他早已忘了他曾手動取消權限這檔事；或者他根本不知道取消這些權限，會導致那些功能無法正確運作。

身為開發者的你，要怎麼知道權限被使用者偷偷取消了呢？

如果你程式的 targetSdkVersion 是設為 23 或以上的值，可用下列方法檢查：

boolean bGranted = (ctx.checkSelfPermission(Manifest.permission.READ_CALENDAR) == PackageManager.PERMISSION_GRANTED);

或是：

boolean bGranted = (ctx.checkPermission(Manifest.permission.READ_CALENDAR, android.os.Process.myPid(), android.os.Process.myUid()) == PackageManager.PERMISSION_GRANTED);

如果你程式的 targetSdkVersion 是設為 22 或以下的值，那上述方法都會傳回 true，即使使用者已手動取消權限。所以你要換成下列方法：

String strOp = AppOpsManager.permissionToOp(Manifest.permission.READ_CALENDAR); if (strOp != null) { AppOpsManager mgrAppOps = (AppOpsManager)ctx.getSystemService(Context.APP_OPS_SERVICE); boolean bGranted = (mgrAppOps.checkOpNoThrow(strOp, android.os.Process.myUid(), getPackageName()) == AppOpsManager.MODE_ALLOWED); } else { boolean bGranted = (ctx.checkPermission(Manifest.permission.READ_CALENDAR, android.os.Process.myPid(), android.os.Process.myUid()) == PackageManager.PERMISSION_GRANTED); }
繼續閱讀全文...

Material style Dialogs

如果你依照 AppCompat v21 — Material Design for Pre-Lollipop Devices! 文件中的說明，為你的 APP 加上 material style 的顏色設定 (colorPrimary, colorPrimaryDark, colorAccent)。執行時，你會發現只有 Activity 內的 ActionBar(Toolbar) 或 Views 會套用這些顏色設定。就算在 Android 5+ 上面執行，Dialog (AlertDialog) 中各 Views 的顏色並不支援 material style 的顏色設定。就像上圖中的左邊，RadioButton 不是 colorAccent 所定義的顏色。

這原因在於 AppCompatV7 (r21) 並不支援 Dialog 或 AlertDialog。要解決這個問題，有兩種方法：

第一種解法是加一個 res/values-v21/themes.xml，其內容如下範例：

<resources> <style name="Theme.MyTheme" parent="Theme.AppCompat.Light"> <item name="colorPrimary">@color/color_primary</item> <item name="colorPrimaryDark">@color/color_primary_dark</item> <item name="colorAccent">@color/color_accent</item> <item name="android:dialogTheme">@style/MyDialogStyle</item> <item name="android:alertDialogTheme">@style/MyDialogStyle</item> </style> <style name="MyDialogStyle" parent="android:Theme.Material.Dialog"> <item name="android:colorPrimary">@color/color_primary</item> <item name="android:colorPrimaryDark">@color/color_primary_dark</item> <item name="android:colorAccent">@color/color_accent</item> </style> </resources>

這解法的的好處是簡單，不用額外的套件。壞處是在 Android 4- 平台上，Dialog 的長相與 Views 顏色仍然與原生平台相同。

第二種解法是採用 Material Dialogs 這個套件。優點是在 Android 4+ 平台上會有一致的 Dialog 長相與 Views 顏色，缺點是這位開發者三天兩頭就改個版本，看來離穩定版還有一段距離。

如果你問我，我現在是用那個解法？答案是解法一，因為用第三方套件的風險實在很高，非必要盡量少用，以免增加無謂的程式錯誤與維護程式的複雜度。

繼續閱讀全文...