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 去適應不同裝置的可能性


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
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.

Note: Modular Kernel

官網看來需要把module driver 放到專屬的partitions (vendor/odm) 而且要可驗證的 並且ReadOnly, 而且Google 會強制你必須要用v3.18 (2017年以前出品的SOC 的最低要求), 而之後的SoC 則是不能低於v4.4 這應該是GMS/VTS 強制認證規範才是

然後Module file 不應該在/system 之下

/vendor or /odm 是被建議的Partition 裡面建立起 /lib/modules

然後透過early mount (VBoot v1 or VBoot v2)載入 /vendor and /odm


Note: Tethering provision for Telecom operator config on Android

use jgrep to search the below keywords, will got detail information, just need to change string resource, may to use override method like this

  • config_mobile_hotspot_provision_app
  • config_mobile_hotspot_provision_response
  • config_mobile_hotspot_provision_check_period
  • config_mobile_hotspot_provision_app_no_ui

And you need to check system property “net.tethering.noprovisioning" value

Note: How to make Android O v8.0.0_r4 for Hikey960

  1.  ref .  Using Reference Boards step to download source code, but change branch name to android-8.0.0_r4, like the below
    repo init -u -b android-8.0.0_r4
  2.  repo sync -jN (#N for your Host machine, Normally use 8~12, dependency network, SSD/HDD state)
  3. change the below projects to master branch and checkout with special commit hash
    device/linaro/bootloader/OpenPlatfprmPkg — “ca8a8eeb"
    device/linaro/bootloader/arm-trusted-firmware — “d2baddd"
    device/linaro/bootloader/edk2 — “99d893a"
    device/linaro/hikey-kernel — “7517d7dbe"
    device/linaro/hikey — “0ac1c5c5c41
  4. modify device/linaro/hikey/hikey960/
    diff –git a/hikey960/ b/hikey960/
    index 00598e7..92321b4 100644
    — a/hikey960/
    +++ b/hikey960/
    @@ -3,8 +3,20 @@ include device/linaro/hikey/
    -TARGET_CPU_VARIANT := cortex-a73
    -TARGET_2ND_CPU_VARIANT := cortex-a73
    +TARGET_ARCH := arm64
    +TARGET_ARCH_VARIANT := armv8-a
    +TARGET_CPU_ABI := arm64-v8a
    +TARGET_CPU_VARIANT := generic
    +TARGET_2ND_ARCH := arm
    +TARGET_2ND_ARCH_VARIANT := armv7-a-neon
    +TARGET_2ND_CPU_ABI := armeabi-v7a
    +TARGET_2ND_CPU_ABI2 := armeabi
    +TARGET_2ND_CPU_VARIANT := generic
    +#TARGET_CPU_VARIANT := cortex-a73
    +#TARGET_2ND_CPU_VARIANT := cortex-a73
  5. make -jN (dependency your build machine, for me, the value is 8)
  6. waiting build success, then to ref. Using Reference Boards, for update your hikey960 board
  7. enjoy the play