Note: Project Celadon

之前Android-IA For UpBoard/Apollo Lake 提到有Intel 的計畫Android IA, 結果Intel 最近直接把該計畫全砍掉, 改稱 Project Celadon Github account 也看得出來是從Android IA轉移過來, 不過現在有比較清楚的Release Note

看起來就是Intel NUC 為基準平台, 但是從result 看來, 還有不少bugs

廣告

Note: Android Comms Test Suite的硬體控制模塊

Android Comms Test Suite是一個用來驗證Android Device各種無線互連機能是否能通過一般正常使用的測試架構, 它裡面有使用到一個Monsoon 的Power Monitor, 不過如果是本來做手機平板設計的公司本來就會購置測試用的BatterySimulator 去測功耗, 該裝置一般也是可以透過USB或是LAN遠端操作, 可以寫一個對應的Python 模塊去替換,, 基本上可以參考 monsoon.py這個裝置可以看到是用USB ACM裝置透過Serial port 去下命令的, 但是其他例如基站模擬它們使用Anritsu 的 MD8475A, 然後干擾的信號產生器 MG3710A, 然後配合的衰減器 是aeroflex  跟microcircuits 這兩家到是國內RF常見的設備, 然後上面都是透過socket 控制
還有用FTDI 去做Relay Board, BT Speaker/Headset 等於全套自動化交互測試都靠這些搭建起來

基本上控制用的模組代碼都在下面
https://android.googlesource.com/platform/tools/test/connectivity/+/master/acts/framework/acts/controllers

目前Google自己的TestCase 在 https://source.android.com/devices/tech/connect/connect_tests/google

看了一些TestCase 想到以前做Windows Mobile 進行 LTK (Logo Testing Kit certification) 時有做過不少類似的Case 去驗證裝置的基本穩定度

ref. https://source.android.com/devices/tech/connect/connect_tests

Note: Android x86 Bootloader

qummiboot 是一個EFI 的 Bootloader, 當初發展出來是因為Microsoft 主導了Windows 8/UEFI SecureBoot的需要, 透過 UEFI Shim 方法去做自我簽證

而Intel 在力推Android on Intel(ia32/amd64)時期, 就根據原本的gummboot 改寫了一個版本去吻合Android 的需要,它內部除了Shim, 還做了BCB(Boot Control Block) 傳遞替後面的Recovery/Bootloader 交換資料,並且也做了一個BIOS Update 的機制,實際上根據他的內容它可以作到更新Radio Firmware 也可以作到更新EC(embedded controller) 等其他需要更新的內容, 不由得想到之前工作被交代的任務是在Kernel 增加一個interface 跟EC配合的更新版本

不過後來Intel 重新做了一個叫做 KernelFlinger,實作了後來需要的A/B Update, DM-Verify , TEE-OS Access與幫助生產的Blobstore 等新增功能.

gummiboot 目前在Freedesktop 的版本已經被放棄,因為被改稱systemd-boot了, 但是Redhat 仍然有一個自己的版本

不過gummiboot 對我來說仍然是一個極具參考價值得版本, 因為在許多嵌入的x86系統上不見得只有上面提的的OS,  gummiboot 相對簡單的程式碼, 方便用來當做開發其他OS用的Bootloader 基礎

ref.
https://en.altlinux.org/UEFI_SecureBoot_mini-HOWTO
https://github.com/rhboot/shim
https://github.com/android-ia/platform_external_gummiboot
https://github.com/intel/kernelflinger
https://cgit.freedesktop.org/gummiboot/
https://github.com/todorez/tummiboot
https://github.com/android-ia/hardware_intel_efi_kernelflinger
https://www.phoronix.com/scan.php?page=news_item&px=Gummiboot-Is-Dead

 

Note: Android IA – Apollo lake/Up Board

currently Android-IA team provide Android BSP
ref. https://github.com/android-ia/manifest/wiki
see https://github.com/android-ia/manifest/commit/b1df5863dcc65cbb0de78453e1e124f5f10f78fb

<?xml version="1.0" encoding="UTF-8"?>
<manifest>

  <remote  name="aosp"
           fetch="https://android.googlesource.com" />
  <default revision="refs/tags/android-8.1.0_r7"
           remote="aosp"
           sync-j="4" />

  <remote  name="github"
           fetch="https://github.com/android-ia/" />

  <remote name="kernelorg" fetch="https://git.kernel.org/" />

  <remote  name="graphics"
           fetch="https://github.com/01org/" />

  <remote  name="intel"
           fetch="https://github.com/intel" />

  <remote  name="trusty-ia"
           fetch="https://github.com/trusty-ia" />

  <include name="include/aosp_vanilla.xml" />
  <include name="include/remove-android_ia.xml" />
  <include name="include/bsp-android_ia.xml" />

</manifest>

可以看到 graphics driver 用的是 01org上的mesa,
verify boot 用的是trusty-ia
然後透過嵌套讓 remove-android_ia.xml 移掉 aosp 上面不需要的 repositories , 透過bsp-android_ia.xml 加進去需要的

ref. Intel 官方 Demo video https://software.intel.com/en-us/videos/up-squared-bring-up-bkm-with-android-omr1 , the Demo video from Intel SSG OTC and the BSPs need NDA
SSG OTC (Intel Software and Services Group Open Source Technology Center)

Note: Treble

從Android Oreo, Google 透過Treble 機制去解耦合HAL 跟Framework的相依性,希望借此機制去解決Android 碎片化跟安全性的問題。雖然目前還看不出有達成他想要的目的,但是真的有達成更進一步緊縮Android 裝置的控制權,不過最主要的原因實際是控制了GMS,跟Microsoft 藉由Office 控制桌面作業系統一個道理,是終端使用者離不開這些軟體與服務進而綁住供應商。
下圖是Android 的HAL 跟Framework的連結方式從1的傳統Legacy HAL 到2,3和4的Treble 實作方式,2 and 3的方法是為了提供舊的裝置單純升級到Android Oreo 提供的方法,如果裝置一開始就是Android Oreo 必須使用4 的方法

HIDL 是透過IPC 解藕合HAL與Framework 等於可以動態升級,不再是編譯時期繫結(Bind)。

而除了上述透過HIDL去分離界面外,再Kernel跟Disk Paratitions也做了規範,強制引入了/vendor or /odm paratitions 從/system or /boot 去分離HAL實作 而且也透過Kernel 4.4 and Later 去加入device tree overlays功能,讓廠商達成同一個 /boot and /system 去適應不同裝置的可能性

Update:
而Treble 的這種解藕合方式實際上有很大可能是為了新的Fuchsia OS (Kernel : Zircon)鋪路,透過IPC溝通系統內的所有組件,是micro kernel 的一個基本特徵, 而且透過這種方式後很可能Android P 之後會實現透過OTA切換 Linux/Zircon kernel

Note: GATT service with Bluetooth Low Energy

傳統的Bluetooth Device 透過 SDP service 使用Profile UUID 去讓兩者相連, 但是BLE則擴充了這個方法, 透過提供 GATT (Generic Attributes) Profile 去取代 SDP的功能,使用GATT Service 內的 Service/Characteristics 功能可以更方便跟分類各種服務跟屬性值, 並且透過GATT 可以自我宣告特定應用的Service與Characteristics 去創建自己的特殊應用 常見有iBeacon/Eddystone Beacon 或是 像是 TI SensorTags 可以參考這個 Andorid Source 去使用Ti 自定義的Barometers service

官方說法 from https://www.bluetooth.com/specifications/profiles-overview
For two Bluetooth devices to be compatible, they must support the same profiles. And while profiles generally describe the same use case behaviors, they are different for Bluetooth BR/EDR and Bluetooth Low Energy (LE) implementations. Compatibility between Bluetooth BR/EDR and Bluetooth LE implementations requires a dual-mode controller on at least one. For BR/EDR, a wide range of adopted Bluetooth profiles describe many different, commonly used types of applications or use cases for devices. For Bluetooth LE, developers can use a comprehensive set of adopted profiles, or they can use Generic Attribute Profile (GATT) to create new profiles. This flexibility helps support innovative new applications that maintain interoperability with other Bluetooth devices.