[討論] Android O: Project Treble

看板MobileComm作者 (OCISLY)時間7年前 (2017/05/13 12:43), 7年前編輯推噓15(15推 0噓 41→)
留言56則, 15人參與, 最新討論串1/1
打從4.0 ICS起谷歌養成了會挑特定領域組團打怪改進Android的習慣。 今天新鮮公佈是Android O的計劃是Project Treble。 “treble： a threefold quantity or thing, in particular.” 這回終於輪到針對安卓的更新瘟疫做出的小改善。 此計劃目的是將Android OS模組化， 區分開谷歌主導的Android OS架構代碼與”由特定晶片供應商撰寫的“硬體代碼。 這麼做理論上可達成'當晶片供應商沒有參與的情況下'， 單靠OEMs本身就能著手準備為手機提供Android更新。 http://i.imgur.com/jaso5br.png
新版本安卓由谷歌釋出後還要經過三關才有機會送達你我手中， 分別為： 1. 晶片供應商(高通Snapdragon, 三星Exynos, 聯發科Helio)基於自家生產硬體針對新版Android的改變做出對應修改， 確保各關鍵組件如驅動和電源管理機制在新版本能夠正常運作。 2. OEMs (Samsung, LG, HTC) 投入確保自家手機使用的所有硬件都正常運作， 為自家皮膚改版， 準備系統內建應用程式， 對Android OS上層做出修改並添加各種OEMs喜愛的花俏功能。 3. 營運商測試及批准更新，加入更多沒人愛的apps。 這一項美國是重災區， 其他地區營運商沒那麼大討價能力，也沒這麼做得這麼極致的習慣。 可見Project Treble非萬用救命仙丹， 它嘗試解決的是上圖中第一二步驟之間的阻礙。 The Vendor Interface (供應商界面) http://i.imgur.com/zwv7zZd.png
一開始Android的目標就是要在各式各樣各家的硬體上都能運行， 因此谷歌曉得維持API行為一貫的重要性。 一直以來都藉著兼容定義文件(Compatibility Definition Document) 搭配兼容性測試套件（Compatibility Test Suite )來確保Android裝置的一致性。 只有這樣應用程式開發者才能開發出一個在各式Android裝置上都能運作的應用程式。 Project Treble主要概念是將大多由晶片供應商負責的底層部分剝離中上層Android OS架構。 為此Android O新增了的供應商界面， 可視它為Android OS架構與晶片供應商硬體間的穩定橋樑。 谷歌也就此設計了類似CTS的供應商測試套件(Vendor Test Suite)， 來驗證晶片供應商所寫的界面， 同時確保該供應商界面的向後兼容性。 Project Treble的益處 由於安卓一路走來都沒有形式上的供應商界面， 每回有新Android系統要更新時需要先將散佈在各方的零散供應商提供的代碼一併更新才能達成目的。 http://i.imgur.com/xBIAMJW.png
有了穩定的供應商界面作為兩者之間的媒介， OEMs也有了選擇僅更新上層Android OS架構的能力。 這就能省去等待晶片供應商提供新版本BSP一環。 http://i.imgur.com/5dI2Wqh.png
Project Treble將會出現在Android O起的新Android版本， 實際上它現在已被應用在開發版Android O的手機上了。 此外，谷歌也和夥伴們合作將一些特定國家營運商使用的特定功能移入AOSP中，這樣OEMs便不再需要每更新一回都得重新自行移植一回一樣的功能。 https://goo.gl/DE6Ipn ----- Project Treble在Google旗下手機的Android O DP1韌體已上線， 意味著高通已將Snapdragon 810, 820兩條維護線的供應商界面預備好了。 按常理說使用這些高通SoCs的手機， 只要OEMs有心便能更快就獲取Android O更新了。 至於其他晶片供應商的情況如三星Exynos就不曉得了，但要轉移去新界面若現在還沒開始整合應該會慢些， 好處是使用供應商界面以後會方便許多。 最後則是醒腦部分， 有了供應商界面以後是能免去高通無預警中斷Snapdragon 800線的Android 7支援的慘劇。 新安卓推出後至各廠手機獲得更新的時程會縮短， 但這不代表OEMs會提供像蘋果iOS那麼長的OS更新支援時間， 我這話包括了谷歌旗下的Pixels系列的2年系統更新。 三方ROMs方面將會大大受益， 要支援新版本安卓方面應會容易許多。 有了供應商界面後，各種硬件也不會亂壞東壞西的， 廠商不支援後的新版本Android也不需要自行再駭出一堆補丁勉強用了。 -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 60.51.8.123 ※ 文章網址: https://www.ptt.cc/bbs/MobileComm/M.1494650595.A.90E.html
推
05/13 12:44, , 1F
我也覺得2699辦完後速度很順
05/13 12:44, 1F
推
05/13 12:50, , 2F
所以簡單來說就是能確保特定soc可以更快的獲得更新
05/13 12:50, 2F
→
05/13 12:50, , 3F
嗎
05/13 12:50, 3F
推
05/13 12:51, , 4F
會變成Project Terrible還是Project Table平台呢？
05/13 12:51, 4F
推
05/13 12:53, , 5F
2699可以停了吧你
05/13 12:53, 5F
→
05/13 12:58, , 6F
一樓開玩笑也要看對地方，好笑嗎？
05/13 12:58, 6F
推
05/13 13:11, , 7F
就像微軟系統 內建相容性驅動的概念一樣
05/13 13:11, 7F
→
05/13 13:12, , 8F
新系統裝在舊裝置上 就算沒原廠驅動也能用
05/13 13:12, 8F
→
05/13 13:26, , 9F
大致就像樓上說的那樣 假如今天手機用x86早就和Wind
05/13 13:26, 9F
→
05/13 13:26, , 10F
ows一樣搞 阻礙在ARM設計是給各種奇怪便攜裝置的 連
05/13 13:26, 10F
→
05/13 13:26, , 11F
線路都要寫死在核心
05/13 13:26, 11F
推
05/13 13:34, , 12F
值得期待
05/13 13:34, 12F
我怕是省下的 人力資源都被拿去cost down
推
05/13 13:41, , 13F
要完成這個價格，ROM Usage又要犧牲好幾G @@
05/13 13:41, 13F
摸摸mog大 下面回你文
→
05/13 13:42, , 14F
TYPO@@架構~~
05/13 13:42, 14F
※ 編輯: mainline (60.51.8.123), 05/13/2017 13:44:17
推
05/13 13:46, , 15F
好文章! 期待未來Android 都能用google 直接更新!
05/13 13:46, 15F
只要還是以ARM架構為主 不可能啦 ※ 編輯: mainline (60.51.8.123), 05/13/2017 13:54:26
推
05/13 15:08, , 16F
"只要oem有心"… 只能說呵呵
05/13 15:08, 16F
推
05/13 16:29, , 17F
只要OEM要介入就...
05/13 16:29, 17F
※ 編輯: mainline (60.51.8.123), 05/13/2017 16:39:12
→
05/13 16:50, , 18F
不會佔ROM空間 Linux核心才幾MB 剩下的大多是本來就
05/13 16:50, 18F
→
05/13 16:50, , 19F
要ship的binaries 值得一提一年半前Nexus已經有個ve
05/13 16:50, 19F
→
05/13 16:50, , 20F
ndor分區開始把驅動binaries移過去了 當時主流猜測
05/13 16:50, 20F
→
05/13 16:50, , 21F
是把為未開源驅動移走方便分開更新
05/13 16:50, 21F
推
05/13 17:12, , 22F
直接google更新..還是不要想吧
05/13 17:12, 22F
推
05/13 17:14, , 23F
除非google限制OEM廠一年可出的手機數量並契定更新
05/13 17:14, 23F
→
05/13 17:14, , 24F
年數、版本，否則不給新版本or使用授權..但是某個
05/13 17:14, 24F
→
05/13 17:14, , 25F
兩年更新保障都不鳥了
05/13 17:14, 25F
推
05/13 17:38, , 26F
將重要功能 拉成 app 跟 webview 一樣更新
05/13 17:38, 26F
推
05/13 23:06, , 27F
我怎聽說要多割一塊System partition ^_^"
05/13 23:06, 27F
→
05/14 01:04, , 28F
你說的是seamless updates 谷歌沒逼人起用 目前只知
05/14 01:04, 28F
→
05/14 01:04, , 29F
Pixel和G6用了 那功能很好很強大 若擔心沒空間可只
05/14 01:04, 29F
→
05/14 01:04, , 30F
在旗艦啟用就好 我深信它能降低手機升級失敗回廠率
05/14 01:04, 30F
推
05/14 01:30, , 31F
好像一出場so 是o的被要強迫使用@@
05/14 01:30, 31F
→
05/16 03:36, , 32F
Google 沒有逼人用A/B(seamless) update應該是牽扯
05/16 03:36, 32F
→
05/16 03:36, , 33F
到Partition layout的改變(有二組partition,名字一
05/16 03:36, 33F
→
05/16 03:37, , 34F
樣,但結尾以_a,_b區分是那一組),recovery變成boot_b
05/16 03:37, 34F
→
05/16 03:37, , 35F
,cache變成system_b, etc.,換言之就是在 A/B
05/16 03:37, 35F
→
05/16 03:37, , 36F
partiton 下是沒有recovery以及cache partition的.
05/16 03:37, 36F
→
05/16 03:37, , 37F
再來是A/B update完整度約是 android_7.1.1_r1(也
05/16 03:37, 37F
→
05/16 03:37, , 38F
就是 Google XL出貨版本)才算真的有 90%完成.
05/16 03:37, 38F
→
05/16 03:38, , 39F
但很多晶片供應商一開始port的都是android_7.0.x,
05/16 03:38, 39F
→
05/16 03:38, , 40F
完整度約50%左右,不支援A/B update能夠理解.
05/16 03:38, 40F
→
05/16 07:53, , 41F
晶片廠會不會使用Treble 是個問號，像Qualcomm,mtk
05/16 07:53, 41F
→
05/16 07:53, , 42F
多SIM卡的支援是自己有更改Android framework層才
05/16 07:53, 42F
→
05/16 07:53, , 43F
達到的，這部分目前怎麼拆的開呢？
05/16 07:53, 43F
→
05/22 15:38, , 44F
樓上說的沒錯 這當然是要新機才能支援 我所指的自然
05/22 15:38, 44F
→
05/22 15:38, , 45F
是逼人在新機支援 看劇據mog大透露的看來谷歌會在O
05/22 15:38, 45F
→
05/22 15:38, , 46F
強制 我想應該還是會和加密需求一樣留後路 如設成64
05/22 15:38, 46F
→
05/22 15:38, , 47F
GB以上就得支援
05/22 15:38, 47F
→
05/22 15:48, , 48F
至於晶片廠和手機廠會不會想要treble 答案是yes 這
05/22 15:48, 48F
→
05/22 15:48, , 49F
本來就是為了它們搞的 也是它們想要的 Android頭兒
05/22 15:48, 49F
→
05/22 15:48, , 50F
也證實了 treble就是在決絕你說的framework和底層代
05/22 15:48, 50F
→
05/22 15:48, , 51F
碼混雜在一塊的問題 有了treble的隔離構造就不必每
05/22 15:48, 51F
→
05/22 15:48, , 52F
每新版本又得重新port一回晶片支援 高通聯發科自然
05/22 15:48, 52F
→
05/22 15:48, , 53F
愛死 廠商也能省下一堆精力 我擔心的是省下的都換成
05/22 15:48, 53F
→
05/22 15:48, , 54F
cost down而非在加速更新上
05/22 15:48, 54F
→
05/22 15:49, , 55F
對了 搭載O出廠的新機必須通過VTS 這點夠明確了吧
05/22 15:49, 55F
→
05/22 15:49, , 56F
一定會支援
05/22 15:49, 56F
‣ 更多 mainline 的文章
文章代碼(AID): #1P5exZaE (MobileComm)