之前介紹過 Google 在 Android 7 (Nougat) 中推出 GNSS measurements API ,由於這個功能受限於硬體韌體設計,暫時只有某些晶片才能支援,包含了 Exynos、Qualcomm、Broadcom BCM4774、Intel WCS2x00 等。預計今年之後會出現越來越多支持 GNSS Measurements API 的手機。
開發者網站提供一個參考列表,包含市面上幾個旗艦手機的對於 Pseudo-range and pseudo-range rate、Navigation messages、Accumulated delta range or carrier、Hardware (HW) clock 等支援現況,也提供了範例程式給開發者參考。
對於需要做 GPS 效能調校的硬體、韌體工程師,通常透過 Android HAL API 測試 GPS 訊號。在 Android 中最低階的協議是透過 NMEA sentence 協議取得衛星訊號數值,但是這其實還不夠低階到包含如 pseudoranges 等資料[5][6]。這些 raw data 資料只來自使用該晶片商獨家的 binary protocol,而沒有標準的 API 可用。
Google I/O 的講者 Steve Malkos 的演講 (37分30秒)[7] 其實只提到會拿到原始 GNSS 測量資料。但是他還沒有分享具體的設計會長什麼樣子,另外最大的改變是 GPS, Wi-Fi, Cell 等 Connectivity API 會被從較高階 API 移到底層的 Sensor Hub (low power domain),這樣可以更省電且有效的計算位址資料。
另外一個值得考慮的是晶片可以支援的處理頻道數量,理論上只要三個衛星就可以計算出平面定位,取得四顆衛星能取得 3D 定位。也就是說,裝置最低需要同時處理四個 L1 頻道訊號。但是在成功取得定位前,裝置必須搜索所有可能訊號,以找出最接近的衛星,在首次定位前,同時間能夠處理的衛星訊號數越多,首次定位也就越快、越省電,定位之後也能有效率的鎖定衛星訊號。以前只有美國系統,加上地表角度,天空最多同時可以看到一打以內的衛星,所以大概只需要十二組頻道。但是若加上俄國等系統,你也就需要更多的「處理頻道」。
通過天線,進入 RF Front end 後會依序進入上述元件進行訊號增強、過濾、轉換,但這些元件皆已經高度模組化,使用者很難從外觀去判斷性能差異或是進行客觀的評估,畢竟缺乏測試設備,也難以獨立的對每個元件進行測試,但是只要其中一個元件設計失誤,就會影響使用效能。特別是整合到電路板上後造成的訊號干擾問題,在在考驗製造商的工藝技術。
容易令人混淆的是在電信網路協定中,除了使用 TCP/IP 最多採行的 OMA 協定 “Secure User Plane Location” (SUPL) aka Mobile Station Based 外,還有另外一種 Mobile Station Assisted, Control Plane Protocol 則是透過基地台計算行動電話位址,然後將位址資訊傳送回手機。這兩種技術是完全相反的。
基本的概念是你可以用 XML 刻出一個軟體介面,只要使用者訂閱了你的服務 (add-ons),就會出現在 Fring 的選單列。所有使用者在介面上所觸發的行為,都會傳到 Fring Interface Server (FIS),然後再即時傳到你的 Add-ons Server。於是,你可以只懂著處理 XML 刻出來的使用者介面與傳輸過來的 XML 訊息,就可以將軟體移植到 Fring 目前已支援的平台,而不用弄髒自己的雙手去玩各種手機平台。目前 Fring API 提供了一組簡明的 PHP 範例,可於開發網站下載。
Introducing: The fring API
Fring API 才剛開放沒多久,還沒有太多可以參考的程式範例。不過相較於 Widsets 受限於 J2ME 的開發環境,Fring 顯然更好的 Native Application 優勢,可以存取更多系統資源,如 GPS 等。可惜的是目前的 API 稍嫌不足,如檔案交換、相機取用等,似乎都尚未開放。另外一個值得考慮的議題是,Fring 是否會開放出社交資料,讓第三方開發者應用。若是缺乏了行動社交網路功能,那麼 Fring API 可能也將只是另外一個 Mobile RSS Reader。