How to make "Dark mode" listed in Facebook APP on Android Tablet

I've been annoyed by Facebook's dark mode on my Android tablet for a long time. 

After one of the update several months ago, my Facebook app doesn't list "dark mode" on menu any more. All articles on the internet said you can find it under "Setting & Privacy" of burger menu. But I just can't find it for a long time

Today I accidentally found the root cause. Therefore I write this to share my finding in English to let more people know about the tricky thing. It's all about display setting. If you have the same issue, please check your "Display size" in the "Display" menu of Settings. 

For some Android tablet users, they want to show more on the screen, so it would be changed to "default", "small", "smaller", or "smallest". There is no identical setting that will make dark mode be shown on menu. Just try "default", "large", "larger" or "largest" one bye one. After eche changing of the setting,  please remember to kill Facebook app and the relaunch it. Then you will find a setting that works. (According to my experience, the "middle" one will be the first working setting.)

Hope this article would be helpful for some people.

Android 軟體架構轉變的進行式

今日在 Google 的 Android Developer Blog 上貼出了篇名為的 "Here comes Treble: A modular base for Android" 貼文, 這是一件對於 Android 生態系統的大事, 也是 Google 方面嘗試來解決 Android 的碎片化與安全性上的問題.

這件事必須先從 Android 裝置的軟體是經過什麼樣的流程抵達每個使用者手上, 在這篇文章中即是一開始的五步驟圖:

1. Android 團隊向世界發佈最新版本的原始程式碼
2. 晶片製造公司為了讓他們各自的晶片在 Android 裝置上俱備更多優勢, 針對他們特定的硬體, 修改了來自 1. 的原始碼與增添驅動程式.
3. 這些晶片製造商接著將這些修改提供給他們的客戶 - 也就是那些設計與生產 Android 裝置的品牌商. 這時裝置生產商再次針對他們的產品對 1. 的軟體做了修改.
4. 裝置生產商與電信網路商測試與驗證新的版本.
5. 裝置生產商與電信網路商提供新的版本給他們的使用者

 在以往 Android 裝置間是透過相容性文件 Compatibility Definition Document (CDD) 所規範的介面以及現在已經涵蓋上百萬對應測項的相容性測試套件 Compatibility Test Suite (CTS) 來避免軟體相容性上的問題. 然而面對來自上述 2. ~ 5. 項目的修改與限制, 造成了 Android 軟體層上碎片化不容易解決, 1. ~ 3. 表示裝置生產商會 follow 的不是 1. 的官方實作而是 2. 的 chip vendor 的 Android Framework 的修改, 此外 4. 與 5. 反映了 Android 裝置的安全性修正完全取決於裝置生產商自己的更新意願(特別是裝置生產商不願意透入成本在維護已發售許久的裝置).

為此 Google 在 Android O 開始要著手解決這樣的問題, 提出了 Project Treble, 其目的在於強化對於 Android 系統軟體這塊的控制與掌握, 這必須談到在以往即已經存在, 但是界線並沒有明確規範的 Vendor Implementation (廠商實作層), 現在 Google 將明確的對 Android Framework 與 Vendor Implementation 切出這一條線:

因此先前所採用的 CDD + CTS 方式, 將轉為 Vendor Interface + Vendor Test Suite(VTS), 這件事最大的意義在於 Chip Vendor(晶片商) (或是很有可能以後包含 Device Vendor(裝置生產商) )將不再能夠直接修改上述五步驟中 1. 裡面的 Android Framework 的原始碼, 而優化與性能提升的方式也被限縮在圖中灰黑色(這顏色是不是特別選過阿...) 的 Vendor Implementation 這一層, 介面也是所定義規範出的 Vendor Interface.

藉由明確規範 Vendor Interface 的好處如上圖, 也就是 Android OS framework 的更新將獨立於 Vendor Implementation, 而在該篇文章是這麼說的 "device makers can choose to deliver a new Android release to consumers by just updating the Android OS framework without any additional work required from the silicon manufacturers", 翻成中文就是裝置生產商能夠無需藉助於晶片商額外的處理下, 就能夠自行更新 Android OS framework 的部分(這或多或少都是裝置商對於更新推托的理由與藉口). 是的, 目前 Project Treble 並沒有強勢到一次將 Android Framework 客製的權力全部收回, 這或多或少是出於市場考量, 但是至少讓 Google 頭疼的源頭 - Chip Vendor 的客製已然受限, 當然這樣作法背後還是在於 Google 對於 Chip Vendor 的客製只能道德勸說並無其他的約束能力, 而 Chip Vendor 還是會嘗試對客戶提供他們自己客製的 Android Framework, 一方面這樣介面的建立會讓裝置系統商意識到不正確與不當的客製修改, 另一方面來說對於裝置生產商來說來自 Google 相關的軟體生態系(Google Play)的授權是相當重要的, 因此 Google 還是有一定其他要求與控制能力. 一旦架構建立了 Treble Architecture, Google 即更能順利的要求裝置廠商去提供裝置的軟體更新(而以往的理由會凸顯背後的問題, 讓 Google 更能第一時間掌握有問題的平台).

最後 Google 還在文末說道目前 Pixel 上運作的 Developer Preview of O 已經採用了這樣的架構方式.

Gaming 或許是 Android 5.0 Lollipop 其中一項重點

Android 5.0 在近日正式釋出了
而在 10/17 也已釋出了 SDK for Android 5.0
對於 Android 5.0 網路上相關介紹文件不少
由於先前並沒有花心思看 Android L Preview 的介紹
所以這幾日花了點時間消化相關新的系統特性

這裡想指出 Google 對於 Android 平台在 Gaming 的野心
首先是 Android 5.0 除了 OpenGL ES 3.1 的支援外提出的 Android Extension Pack(AEP)
The extension pack supports:
* Guaranteed fragment shader support for shader storage buffers, images, and atomics (Fragment shader support is optional in OpenGL ES 3.1.)
* Tessellation and geometry shaders * ASTC (LDR) texture compression format
* Per-sample interpolation and shading
* Different blend modes for each color attachment in a frame buffer

其中前兩點是最重要的,
請搜尋 Tessellation 稍微了解其目的
另外必須知道 Tessellation 是 OpenGL 4.0/DirectX 11 後的特性
Tessellation & Geometry Shader 是近年 GPU 提升模型動態細緻化的重大演進
對於 AEP 詳細的規範可以參考 Khronos 的 spec

而另外一個點在於此次 Google 裝置除了 Nexus 6/9 外
還有個不太受到注目的 Nexus Player,
多數的 Nexus Player 分析著重於 Android TV 與具有語音控制/搜尋的遙控器上, 這點無可厚非
但 Ｎexus Player 有許多有趣的特性(像是它是第一個官方 x86 Nexus 裝置)
其一便是 Nexus Player 提供了選購的無線藍牙 GamePad
目前已知 Nexus Player 中的 Intel Atom 所使用的 GPU 是 PowerVR 6000 系列
這系列的 GPU 俱備了支援 AEP 的規格
此兩點顯示 Google 有意透過 Nexus Player 做為 Android Gaming Console 的示範平台的野心
儘管 Android Extension Pack 對於 Android 並非必要項目,
但在智慧裝置利潤逐漸下滑的今日, 平台差異化顯得重要
AEP這樣明確規範的規格, 是很容易成為各家IC生產商軍備競賽的比較條件之一...
況且, 若無市場戰略目標, 維持目前 Android 圖形需求, 跟隨 OpenGL ES 標準也已足夠 (若要與 iOS Metal 競爭那又是另外一個面向的事情了)
並無制定這套延伸 OpenGL ES 擴充標準的必要

淺談 OpenCore execution model

由於新工作與 OpenCore 有關, 前輩考量到未來對效能調整, 希望我能了解 OpenCore 架構
為此而稍微細看OpenCore, 感到非常"新奇", "有趣"

在此先不細談 OpenCore 整體 Object Model, 而這部份網路上的談論也不少
大致上即是分為 Engine - PVMF Node - Component 三層

這裡談 OpenCore 中的執行運作模式
或許是OpenCore 受到 Symbian Active Object Framework 諸多影響(文件上也有諸多Symbian字眼)
基本上, 對於Symbian 個人認知不深
然而對於OpenCore這樣注重 realtime 特性的 Multimedia Framework 採用這樣的方式感到"新奇"


上圖為運作的圖解
OpenCore 內基本執行單位為 PVActiveBase
而衍生出的 class 為 OsclActiveObject(AO) 與 OsclTimerObject(TO)
實作中需要被執行的元件繼承 AO or TO
而每個繼承AO/TO的類別需要個別實作其要不斷被執行的 Run() 介面

OpenCore 執行模式為 single thread
在 OsclScheduler::BlockLoopL() 這個無線迴圈當中
透過 WaitForActiveObject() 來取得下一個需要被執行的AO/TO
接著呼叫 CallRunExec() 來執行 AO/TO 的 Run()

對於規劃中需要被執行的AO/TO物件
只要沒腦地執行 PVActiveBase::AddToScheduler() 即可
接著便會依序被執行該AO/TO所實作的 Run()

看似簡單的行為, 然而直覺操作上卻讓人毫無頭緒
是的, 介面上無需透過具體的 scheduler instance, 從何來, 哪裡去就像黑盒子般
這點一時間讓我有點難以接受
細看實作上透過 macro 的方式取得 current thread 的 scheduler
只能說如此的 execution model 機制顯得不太clean
這樣的 model 基本上如果是為了 single thread/co-operative multitasking 的考量
也算說得過去, 只能說真的不是很優雅與直覺

再來, 其中最有趣的一點便在於 OsclTimer 與 PVMFMediaClock 這兩個 timer 類別
實作中AO/TO通常向此兩者註冊callback function 希望通知特定 time event 的發生
OsclTimer (oscl/oscl/osclproc/src/oscl_timer.h) 仰賴著 CallbackTimer
CallbackTimer 繼承自 "OsclTimerObject" ~ Wow~
看看 PVMFMediaClock (pvmi/pvmf/include/pvmf_media_clock.h)
一堆繼承物件中, 第一個物件即為 "OsclTimerObject"
而兩者的 Constructor 都呼叫了 AddToScheduler()
其時間的資訊是去 polling 系統的 OsclTickCount 得知

這麼看來 Timer 這點可"有趣"了, Timer 的運作與通知機制也仰賴著這個 BlockLoopL
而如果某一 AO/TO Run() 稍微久一點, Timer Event 可能就失真不少

ex:
試想, 假若一個 decoder 具有硬體加速, 然而 interrupt 有問題
因此採用 polling 方式以得知硬體狀態
component 中期望 timer 能夠每 10 ms 通知一次,
方便於 check 硬體狀態來決定是否要命令硬體 decode 下一張 frame
而在此同時 audio decoder 為軟體實作, 每解一個單位需要 30ms
這麼一來 ......

是的, 如果要遷就這樣的 model, 每個 component 實作上必須特別考量到 timing
而軟體實作上可能必須是 progressive 的方式, 不要一次將全部結果解出, 減少 Run() 單一執行時間長度
以這樣的方式, 來換得 timing 的精確度

如果是為了遷就不用 thread 而使用這樣的 timer 實作呢?
那 Audio 處理與 proxy interface 中就不該大剌剌地使用 OsclThread

anyway, 很高興在 trace 期間自 jserv 那聽到 2.2 已是預設的 StageFright
雖然目前實作不若 OpenCore 完整, 然而看來就個人的理解是"正常"多了 ...

20100727 後記: 應該好好說明一下 proxy interface, 其實本文中舉的例子並不一定會出現, 這裡用這樣的例子來解釋這樣的方式的問題, 文中例子的發生與否取決於是否使用proxy interface(是的, 這是compile option, 而且意義並非網路proxy), 在OpenCORE 中 codec 以 openmax 封裝為 omx_xxx_component, 若透過 proxy interface 即 create 了各 codec 的 thread. 儘管 OpenCORE 中透過使用proxy interface如此與設計不同的方式來避開 codec 的時間問題, timer 依舊容易受到 system I/O 與 parser 之類的影響.

Android 已移植至 PowerPC 平台 & Android 2.0 釋出

在兩年前的拙作"到底 Google Android 是甚麼"一文中提到
Google Android 建構了標準 library 環境與使用Dalvik VM是相當聰明的規劃
相較於WinMobile 與 其他Embedded Linux Distribution而言,
Android這樣的系統特性使得在硬體平台轉換時, 依然保有長期累積的應用軟體資源
當時已可看出Android的架構並非依附在特定硬體平台上.

這樣的特性對於系統與SoC廠商這都是樂觀其成的事情, 特別是使用非ARM Processor的廠商
而這個效應正逐漸發酵中, 繼Android移植到MIPS後
近日LinuxDevices.Com上的新聞顯示現在也已經移植到PowerPC
可以遇見的是, Android 平台的優勢會漸漸浮現

同樣面對多元的硬體平台, 然而Microsoft 由於 Wintel 的成功經驗
預期相同的策略能夠在手持式平台市場複製
在Handheld Device上 Windows Mobile 硬體平台上決定限制使用ARM平台
雖然以此解決了硬體平台多元的問題, 如此的決策也造成了硬體的排他性
並非根本解決軟體相容性問題, 而相對地也同時樹立了非ARM平台業者的敵人


另外在 1.6 版發佈的一個半月後, Android 2.0 釋出了
在功能的改進與新增上有不少的更動

Play with Android 簡報上線

從決定開始要 porting android 到 zaurus 當練習
這段期間看了一些資料, 也看到一些關於Android有趣的實做與專案
以軟體架構的角度看來, Android 的確是個饒富趣味的系統
其特殊的軟體架構, 也讓Android在Symbian, WM, Linux 三強鼎立中走出自己的路外

這份簡報的主旨並不在於教導 porting 或是 marketing 分析
僅僅輕描淡寫地談了系統架構, 動手編譯Android 到客製系統
從慢慢地動手深入 Android, 進而瞭解其相較於其他系統不同的開放與特殊性
或是進而體會到其未至成熟的部份

可以確定的是即便到了 1.6, Android 還需要更多的實作與改善
套句物理頑童費曼的名言: "這下面的空間還大著呢!"
是的, 這下面的進步的空間還大著呢

Play With Android

View more presentations from Champ Yen.

Cont. Android on Zaurus - swap

finally, i compiled a static linked busybox for swap. now browsing is much responsive and smoonth. these words are input by my zaurus.

續 Android 1.6 on Zaurus C750 - Keypad/Screen View

當初構想中的Android Zaurus床頭機是Landscape View
因此無線網路通了之後, 就開始著手修改

在移植過程中就已經發現一件事,
當Zaurus蓋起來時Orientation會切換到Landscape
而一旦打開時就會切到Portrait
這一切都是因為螢幕編框有的凸起, 將鍵盤上方的一個switch 壓下
透過 getevent 指令, 可以確認這是 keyboard 所發出的事件
詳細的修改就不說了, 主要是 driver/input/keyboard/corgikbd.c
針對 SWA (Switch-A) 的結果, 傳回相反值

Android 1.6 已經很聰明的會轉換 Touchscreen 的事件座標
而keyboard 的方向鍵也是 .... 這才讓我注意鍵盤方向對應我的設定有誤
Android 原本的 Screen Orientation 和 方向鍵是針對 手機去設計的
所以要再次調整 /system/usr/keylayout/qwerty.kl 的數值

如此就是一台堪用的床頭機...

續 Android 1.6 on Zaurus C750 - Touchscreen/Wifi

近日已將 Touchscreen 與 Wireless 相關驅動程式與設定調整好
Touchscreen 驅動後即可使用, Wireless 方面是參考這篇
之後要將Screen自Portrait 轉為 Landscape

目前的執行結果如上圖
ZC750 + Android 在網頁瀏覽的反應與速度上差強人意
但是作為熟悉Android Porting是個很好的練習

Android 1.6 on Zaurus C750 - Basic System Works!

Zaurus 是個人在 2003 年時夠入, 近日也不太使用
這段期間從 Cacko, OpenZaurus, pdaXrom 到 Angstrom 都玩過
最近工作需要熟悉Android 移植流程, 在硬體平台尚未完備前
就先行拿這台舊PDA 研究 Android

圖上是 Android 1.6 在 Zaurus C750 開機完成後的畫面
kernel 部份是使用 OE 2.6.26 for Zaurus C7x0
對應的Android 修改是參考 OMAP kernel android-2.6.26
並且加入了 2.6.27 部份的更新與 PMEM 與 w100fb 的 double buffer與加速的修正
目前尚未完成, 無法使用, 還需要針對鍵盤輸入與電源偵測做處理
啟動CF WIFI 來使用也是必定的

相關 source code 與 binary 會在完工後一併釋出
(這陣子survey 發現很多相關網站只釋出binary, 但一直迴避釋出source ex: Omegamoon 釋出許多binary, Zubuntu 已經到 2.0 確從未釋出任何 kernel source)

總之, 這就是開放平台的好處
與C750 同時期的PDA, 硬體或許過時然而卻也不是不堪使用
SONY CLIE UX50 or WinCE/WM PDA 如今又能拿來做些甚麼?
然而相關軟體都已經過時許久, 而且也無持續更新
而規格與軟體不開放, 就算有心也難為無米之炊