worklog -- 碎碎唸 - gps & suspend wakeup

gps port 使用 usb-serial。

所以 suspend 時要先 close，resume 後再 open。
-- 這部份最好作到 transparent。

framework jvm 部份可以由 ACTION_SCREEN_OFF/ON 知道 suspend/wakeup 的時機。
c standalone program 可以由 /sys/power/wait_fb_suspend/wakeup 知道。

---

但是，

usb-serial 在 resume 後，需要2 sec 的時間，krenel module 才會被 probe, ttyUSB 才會出現。
-- 這個比 ACTION_SCREEN_ON, wait_fb_wakeup 的時間晚。

gps 的應用有點問題：
ap 可以各自在 system wakeup 時，作 startNavigating, 和 enable gps 的動作。
不一定經由哪一個 api 來作。

---

所以.

suspend/wakeup 的 close, open 動作可以作在 jni, hardware lib 的部份：是 C code。
也可以坐在 framework 的 GpsLocationProvider.java 裡。

作在 C code 比較乾淨，可以作到讓上面的 framework 都不知道有作這個動作。

但是

他要自己經由 /sys/power/wait_fb_suspend.wakeup 來作。
這樣架構有點醜，

因為 jni code 是跟 framework code 是 link 在一起的， framework 的 LocationManager 已經有　monitor SCREEN_ON/OFF 了，
這裡還重作一次，而且是 monitor 不一樣的地方，
--- 所以很醜..

如果作在 LocationManger，會要處理一堆 ap 不統一的 , 在 wakeup 時的 enable/startNaigating 動作。
用一個 flag 來檔的話，code 的架構也很醜。


如果在 LocationManager 收到 SCREEN_ON/OFF 時，改 call jni function 作，
這樣，就要增加 jni interface -- 好像 break 了 framework 的 interface。

---

最後還是開 thread 在 libhardware 的 jni 裡... (醜1).