40 年老工程師的告別作，全交給了 AI

將舊手機改造成監控鏡頭，是老題目，有不少現成 Apps，但免費版的影像解析度實在慘不忍睹。

這是我第一個完全借助 AI（Antigravity CLI + Gemini Flash 3.8）完成的專案。從開始到收工，全程只用自然語言與 AI 對話溝通；坦白說，直到程式寫完的今天，我都還沒認真看過一行原始碼。

專案已開放原始碼在 GitHub：https://github.com/samlu/CamMonitor

裡面包含完整原始碼、操作指南、編譯好的 APK，以及我最初與 AI 互動的完整對話紀錄。

回顧整個過程，一開始我只是丟出一份寫得粗糙、夾雜錯字與語病的需求草稿（user_requirement.txt），請 AI 整理並產出規格文件 Specification.md。來回對焦幾輪，不到半小時 (期間我這個人類是最大的瓶頸) 我們就敲定了系統規格。

接著，我直接讓 AI 依據規格文件開工。從一個空無一物的專案目錄，到主體程式碼成型，花了不到一小時。

當然，不可能一鍵奇蹟、一次到位。後續我零零星星花了幾天時間測試、打磨功能，總計大概花了 20 小時，才達到目前的穩定狀態。

最震撼的莫過於測試環節：我將兩支手機連上筆電後，直接交由 AI 接管操控，由它自行測試連線、抓出畫面顯示破綻、改寫程式碼並自動重新安裝。所有除錯都由它自主完成後再回報結果，我只負責在實機上做最後的體驗確認。雖然現實中仍免不了來回微調，但這種自主研發與除錯的速度，已經徹底顛覆了我的認知。

目前所有成果都已完整開放。你可以 Clone 下去體驗讓 AI 寫程式的快感，或是讓 AI 接手替它加上物件偵測、自動錄影等新功能；如果純粹想體驗這個應用，也有編譯好的 APK 可直接安裝。照我的老慣例，僅支援 Android，請別問我「iPhone 呢」。

這款 App 我並不打算上架 Google Play，某種程度上，這也是我為自己四十多年的程式開發者生涯，寫下的一篇告別預告。

在這個連外行素人都能寫程式的時代，技術早已不再是高不可攀的壁壘。最大的瓶頸已經不是「該怎麼做」，而是你是否能清楚說出：你究竟想解決什麼問題。

千萬別喪失了你發掘問題的能力，喔，還有你最特別的想像力。

繼續閱讀全文...

當防毒軟體說你的 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); }
繼續閱讀全文...