Android 在物聯網方面能否像在移動終端一樣成功?
我在 Android Things 上的最初 24 小時
正當我在開發一個基於 Android 的運行在樹莓派 3 的物聯網商業項目時,一些令人驚喜的事情發生了。谷歌發布了Android Things 的第一個預覽版本,他們的 SDK 專門(目前)針對 3 個 SBC(單板計算機) —— 樹莓派 3、英特爾 Edison 和恩智浦 Pico。說我一直在掙扎似乎有些輕描淡寫 —— 樹莓派上甚至沒有一個成功的 Android 移植版本,我們在理想豐滿,但是實踐漏洞百出的內測版本上叫苦不迭。其中一個問題,同時也是不可原諒的問題是,它不支持觸摸屏,甚至連 Element14 官方銷售的也不支持。曾經我認為 Android 已經支持樹莓派,更早時候 「谷歌向 AOSP 項目發起提交」 中提到過樹莓派曾讓所有人興奮不已。所以當 2016 年 12 月 12 日谷歌發布 「Android Things」 及其 SDK 的時候,我馬上閉門謝客,全身心地去研究了……
問題?
關於樹莓派上的谷歌 Android 我遇到很多問題,我以前用 Android 做過許多開發,也做過一些樹莓派項目,包括之前提到過的一個真正參與的。未來我會嘗試解決這些問題,但是首先最重要的問題得到了解決 —— 有完整的 Android Studio 支持,樹莓派成為你手裡的另一個常規的 ADB 可定址設備。好極了。Android Studio 強大而便利、十分易用的功能包括布局預覽、調試系統、源碼檢查器、自動化測試等都可以真正的應用在 IoT 硬體上。這些好處怎麼說都不過分。到目前為止,我在樹莓派上的大部分工作都是通過 SSH 使用運行在樹莓派上的編輯器(MC,如果你真的想知道)藉助 Python 完成的。這是有效的,毫無疑問鐵杆的 Pi/Python 粉絲或許會有更好的工作方式,而不是當前這種像極了 80 年代碼農的軟體開發模式。我的項目需要在控制樹莓派的手機上編寫 Android 軟體,這真有點痛不欲生 —— 我使用 Android Studio 做「真正的」 Android 開發,藉助 SSH 做剩下的。但是有了「Android Things」之後,一切都結束了。
所有的示例代碼都適用於這三種 SBC,樹莓派只是其中之一。 Build.DEVICE
常量可以在運行時確定是哪一個,所以你會看到很多如下代碼:
public static String getGPIOForButton() {
switch (Build.DEVICE) {
case DEVICE_EDISON_ARDUINO:
return "IO12";
case DEVICE_EDISON:
return "GP44";
case DEVICE_RPI3:
return "BCM21";
case DEVICE_NXP:
return "GPIO4_IO20";
default:
throw new IllegalStateException(「Unknown Build.DEVICE 「 + Build.DEVICE);
}
}
我對 GPIO 處理有濃厚的興趣。 由於我只熟悉樹莓派,我只能假定其它 SBC 工作方式相同,GPIO 只是一組引腳,可以定義為輸入/輸出,是連接物理外部世界的主要介面。 基於 Linux 的樹莓派操作系統通過 Python 中的讀取和寫入方法提供了完整和便捷的支持,但對於 Android,您必須使用 NDK 編寫 C++ 驅動程序,並通過 JNI 在 Java 中與這些驅動程序對接。 不是那麼困難,但需要在你的構建鏈中維護額外的一些東西。 樹莓派還為 I2C 指定了 2 個引腳:時鐘和數據,因此需要額外的工作來處理它們。I2C 是真正酷的匯流排定址系統,它通過串列化將許多獨立的數據引腳轉換成一個。 所以這裡的優勢是 —— Android Things 已經幫你完成了所有這一切。 你只需要 read()
和 write()
你需要的任何 GPIO 引腳,I2C 同樣容易:
public class HomeActivity extends Activity {
// I2C Device Name
private static final String I2C_DEVICE_NAME = ...;
// I2C Slave Address
private static final int I2C_ADDRESS = ...;
private I2cDevice mDevice;
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
// Attempt to access the I2C device
try {
PeripheralManagerService manager = new PeripheralManagerService();
mDevice = manager.openI2cDevice(I2C_DEVICE_NAME, I2C_ADDRESS)
} catch (IOException e) {
Log.w(TAG, "Unable to access I2C device", e);
}
}
@Override
protected void onDestroy() {
super.onDestroy();
if (mDevice != null) {
try {
mDevice.close();
mDevice = null;
} catch (IOException e) {
Log.w(TAG, "Unable to close I2C device", e);
}
}
}
}
Android Things 基於 Android 的哪個版本?
看起來是 Android 7.0,這樣很好,因為我們可以繼承 Android 所有以前版本的平板設計 UI、優化,安全加固等。它也帶來了一個有趣的問題 —— 與應用程序必須單獨管理不同,未來的平台應如何更新升級?請記住,這些設備可能無法連接到互聯網。我們可能不便於連接蜂窩 / WiFi ,即便之前這些連接能用,但是有時不那麼可靠。
另一個擔心是,Android Things 僅僅是一個名字不同的 Android 分支版本,大部分都是一樣的,和已經發布的 Arduino 一樣,更像是為了市場營銷而出現,而不是作為操作系統。不過可以放心,實際上通過樣例可以看到,其中一些樣例甚至使用了 SVG 圖形作為資源,而不是傳統的基於點陣圖的圖形(當然也能輕鬆處理) —— 這是一個非常新的 Android 創新。
不可避免地,與 Android Things 相比,普通的 Android 會有些不同。例如,許可權問題。因為 Android Things 為固定硬體設計,在構建好之後,用戶通常不會在這種設備上安裝應用,所以在一定程序上減輕了這個問題,儘管當設備要求許可權時是個問題 —— 因為它們沒有 UI。解決方案是當應用在安裝時給予所有需要的許可權。 通常,這些設備只有一個應用,並且該應用從設備上電的那一刻就開始運行。
Brillo 怎麼了?
Brillo 是谷歌以前的 IoT 操作系統的代號,聽起來很像 Android Things 的前身。 實際上現在你仍然能看到很多提及 Brillo 的地方,特別是在 GitHub Android Things 源碼的文件夾名字中。 然而,它已經不復存在了。新王已經登基!
UI 指南?
谷歌針對 Android 智能手機和平板電腦應用發布了大量指南,例如屏幕按鈕間距等。 當然,你最好在可行的情況下遵循這些,但這已經不是本文應該考慮的範疇了。 預設情況下什麼也沒有 —— 應用程序作者決定一切,這包括頂部狀態欄,底部導航欄 —— 絕對是一切。 多年來谷歌一直在告訴 Android 應用程序的作者們絕不要在屏幕上放置返回按鈕,因為平台將提供一個,因為 Android Things 可能甚至沒有 UI!。
智能手機上會有多少谷歌服務?
有一些,但不是所有。第一個預覽版本沒有藍牙支持、沒有 NFC,這兩者都對物聯網革命有重大貢獻。 SBC 支持它們,所以我們應該不會等待太久。由於沒有通知欄,因此不支持任何通知。沒有地圖。預設沒有軟鍵盤,你必須自己安裝一個鍵盤。由於沒有 Play 商店,你只能艱難地通過 ADB 做這個和許多其他操作。
當為 Android Things 開發時,我試圖為運行在手機上和樹莓派上使用同一個 APK。這引發了一個錯誤,阻止它安裝在除 Android Things 設備之外的任何設備:com.google.android.things
庫不存在。 這有點用,因為只有 Android Things 設備需要這個,但它似乎是個限制,因為不僅智能手機或平板電腦上沒有,連模擬器上也沒有。似乎只能在物理 Android Things 設備上運行和測試您的 Android Things 應用程序……直到谷歌在 G+ 谷歌的 IoT 開發人員社區組中回答了我的問題,並提供了規避方案。但是,躲過初一,躲不過十五。
可以期待 Android Thing 生態演進到什麼程度?
我期望看到移植更多傳統的基於 Linux 伺服器的應用程序,將 Android 限制在智能手機和平板電腦上沒有意義。例如,Web 伺服器突然變得非常有用。已經有一些了,但沒有像重量級的 Apache 或 Nginx 的。物聯網設備可以沒有本地 UI,但通過瀏覽器管理它們當然是可行的,因此需要用這種方式呈現 Web 面板。類似的那些如雷貫耳的通訊應用程序 —— 它需要的僅是一個麥克風和揚聲器,而且在理論上任何視頻通話應用程序,如 Duo、Skype、FB 等都可行。這個演變能走多遠目前只能猜測。會有 Play 商店嗎?它們會展示廣告嗎?我們能夠確保它們不會窺探我們,或被黑客控制它們么?從消費者的角度來看,物聯網應該是具有觸摸屏的網路連接設備,因為每個人都已經習慣於通過智能手機工作。
我還期望看到硬體的迅速發展 —— 特別是有更多的 SBC 擁有更低的成本。看看驚人的 5 美元樹莓派 Zero,不幸的是,由於其有限的 CPU 和內存,幾乎可以肯定不能運行 Android Things。多久之後像這樣的設備才能運行 Android Things?這是很明顯的,標杆已經設定,任何有追求的 SBC 製造商將瞄準 Android Things 的兼容性,規模經濟也將波及到外圍設備,如 23 美元的觸摸屏。沒人會購買不會播放 YouTube 的微波爐,你的洗碗機會在 eBay 上購買更多的清潔粉,因為它注意到你很少使用它……
然而,我不認為我們會過於沖昏頭腦。了解一點 Android 架構有助於將其視為一個包羅萬象的物聯網操作系統。它仍然使用 Java,其垃圾回收機制導致的所有時序問題在過去幾乎把它搞死。這僅僅是問題最少的部分。真正的實時操作系統依賴於可預測、準確和堅如磐石的時序,要麼它就不能被用於「關鍵任務」。想想醫療應用、安全監視器,工業控制器等。使用 Android,如果宿主操作系統認為它需要,理論上可以在任何時候殺死您的活動/服務。這在手機上沒那麼糟糕 —— 用戶可以重新啟動應用程序,殺死其他應用程序,或重新啟動手機。但心臟監視器就完全是另一碼事。如果前台的活動/服務正在監視一個 GPIO 引腳,而這個信號沒有被準確地處理,我們就完了。必須要做一些相當根本的改變讓 Android 來支持這一點,到目前為止還沒有跡象表明它已經在計劃之中了。
這 24 小時
所以,回到我的項目。 我認為我會接管我已經完成和儘力能為的工作,等待不可避免的路障,並向 G+ 社區尋求幫助。 除了一些在非 Android Things 設備上如何運行程序的問題之外,沒有其他問題。它運行得很好! 這個項目也使用了一些奇怪的東西,如自定義字體、高精定時器 —— 所有這些都在 Android Studio 中完美地展現。對我而言,可以打滿分 —— 至少我能夠開始做出實際原型,而不只是視頻和截圖。
藍圖
今天的物聯網操作系統環境看起來非常零碎。 顯然沒有市場領導者,儘管炒作之聲沸反連天,物聯網仍然在草創階段。 谷歌 Android 物聯網能否像它在移動端那樣取得成功?現在 Android 在移動方面的主導地位幾近達到 90%。我相信如果真的如此,Android Things 的推出正是重要的一步。
記住所有的關於開放和封閉軟體的戰爭,它們主要發生在從不授權的蘋果和一直擔心免費還不夠充分的谷歌之間。那個老梗又來了,因為讓蘋果推出一個免費的物聯網操作系統的構想就像讓他們免費贈送下一代 iPhone 一樣遙不可及。
物聯網操作系統遊戲是開放的,大家機遇共享,不過這個時候,封閉派甚至不會公布它們的開發工具箱……
前往 Developer Preview網站,立即獲取 Android Things SDK 的副本。
作者:Carl Whalley 譯者:firstadream 校對:wxy
本文轉載來自 Linux 中國: https://github.com/Linux-CN/archive