Google I/O 2018 Android 相關 Session 摘要 – 上集

今年 2018 我們也針對 Google I/O 影片中的 Android 相關議題做了懶人包分享，雖然說是各影片的摘要，但篇幅還是有點長，不過還是建議從事 Android App 開發工作的朋友們讀讀，對於了解這一年過去及未來即將發生的事會很有概念。

此為前半部，若需要 下集連結請到這裡

What’s new in Android

講者在這篇俗稱 Android Developer Keynote 的 Session 中，簡單扼要地描繪出 Andorid 新 APIs 有什麼功能，可以說是為了之後有關 Android Session 所做的開場白。

• Android App Bundles
  新的 App 配送格式，可以節省 App 的檔案大小，讓用戶可以更快的下載 App。

• Android Jetpack
  提供開發元件讓開發者更快速建立起一個高品質的 App。

• Android Support library
  改使用 Androidx.* 取代 android.support.v4.* , android.support.v9.*。

• Android Test
  支援 Kotlin，新的 API 可以減少模板化的 code 產生，並且增加程式碼的可閱讀性。

• Jetpack Architecture
  去年 IO 有介紹 Architecthre Component，經過一年後社群給了一些回饋，在近期會推出 1.0 的版本給開發者使用，除了舊有的 componet 之外， 1.0 新增了一個 Paging compoent，用來處理在 RecyclerView 上非同步資料的處理。

• Battery
  為了節省電力的使用，提出了兩個功能，app standby buckets，用來監控電池的使用量，量測 app 對電力的消耗程度。background restrictions，用戶可以在設定中，限制 app 在背景的使用，來達到省電的目的。

• Background Input & Privacy
  限制 App 在背景的狀態下使用相機以及麥克風權限，並且在背景狀態下也沒辦法自動從感測器去獲取資料。

• Kotlin
  在 ART, R8 & D8 上的效能增加， suppot library 和 libcore 的支援，以及增加 nullable annotation，另外也提供了 android-ktx ，Koltin extension 來擴充 Kotlin 在 Android 開發的便利性，讓 code 變得更簡潔，開發更加方便。

• Mockito
  可以對 final methods , static methods 以及系統所產生的物件做 mock 的操作。

• Background Text Management
  處理文字時，在 Measurement 階段處理上是非常耗時的，大多的花費都會在 UI thread 上，有可能會造成畫面的延遲，因此，新增一個 Pre-computed class API 將這些大量花費的資源改在背景來處理，在處理上可以變得更加快速。

• Magnifier
  提供一組 API，可以在 View 上使用放大鏡的功能

• Baseline Distance
  在 text 的處理上，提供屬性來去調整 baseline 上下的間距

• Smart Linkify
  Linkify 可以讓文字上呈現的 email address，URLs …等變得可以點按，並且會送出對應的 intent 呼叫網頁去處理 URLs，現在 Linkify 透過機器學習的 model 可以變得更加的聰明。

• Location
  API android.net.wifi.rtt.* ， 讓開發者可以透過此 API 獲取室內位置，不需要去連結 AP，但需要搭配特殊的硬體設備並且使用者必須允許 Fine Location 權限才能使用。

• Accessibility
  改善了 App 瀏覽的行為，增加更多無障礙輔助的功能。

• Security
  廢棄使用 FingerprintManager ，將此功能歸類在 BiometricDialog，未來有一些生物特徵的辨識，例如透過虹膜辨識也會統一在 BiometricDialog。為了保護用戶隱私，Build.SERIAL 將不再被使用，在 Andorid P 將會回傳一個假資料。

• Enterprise
  在企業用途上，可以透過一個簡單的 Tag 可以將 Apps 分類，例如分類成個人使用或工作上使用的區塊，另外，允許用戶在 lock mode 的狀況下，可以讓 Apps 放置在裝置螢幕上，最後，提供暫時使用裝置的用戶一個新的模式，kiosk mode。

• Display Cutout
  可以透過 android:windowLayoutInDisplayCutoutMode ，來去設定裝置瀏海的模式。

• Slices
  一個新的方式去操作 App，讓用戶可以藉由 Google Assisant 來操作開發者的 App，方便用戶快速找到他所想要的資訊。 Slices 具有豐富且有彈性的 layout ，有結構性的資料並支援在 support library，Android API 19+。

• Action
  類似 shortcut 的概念，但可以帶上參數傳遞，例如可以帶上專輯字串，直接開啟到某個特定的專輯頁面，為了達到這樣的目的，開發者需要在 actions.xml 定義行為，此外，還需要去註冊 App indexing。

• Notifications
  Google 發現用戶非常喜歡傳送訊息，特別為了訊息顯示的 UI 做了調整，在 Android P 可以直接在 Notification 裡傳送圖片，並且為了簡化使用者的輸入，提供 smart reply 幫助用戶快速回覆訊息。

• Deprecation Policy
  App 的 Traget SDK 需要使用最新的版本，2018 年 8 月之後上架的新 App Target SDK 需要使用 API level 26，在 2018 年 11 月後更新的 App 也一樣遵守此規範，在 2019 年 8 月， App 需要提供 64 bit ABI。

• App Compatibility
  Google 不允許開發者透過反射的方式來呼叫 private API，希望開發者能夠遵守，並列出三種等級的 list 來限制呼叫 private API，從嚴格的程度來說，Blacklist 最嚴謹, Greylist, Light greylist 次之。

• NDK
  提供簡便的 CPU profiler 來觀察 natvie lib 的行為

  • r17
    提供神經網路(Neural Network) API，新的 JNI 共享 memory API，支援在非 root 的裝置下使用 ASAN，移除 ARMv5 , MIPS, MIPS64 廢棄的 APIs。
  • r18
    移除了 GCC compilier 的功能
• Camera
  提供新的 API 可以擷取 OIS(光學穩定器) 資訊，此外，還有外接 USB Camera 的功能，以及支援多相機的控制

• ImageDecoder
  類似 BitmapFactory，不只可以 decode bitmap，drawable，更能 decode 動態的 drawable

• Media
  支援 HDRVP9 ， HEIF (High Efficiency Image Format) 檔案格式

• Vulkan 1.1
  為一個圖像 API 可以用來控制 GPU

• Neural Networks API 1.1
  設計成 C 語言的 API來處理機器學習的部分

• ARCore
  提供一組 API 用來追蹤現實世界的物體，並在模擬器上增加一組 AR 模擬器方便開發者使用。

• ChromeOS
  Android Studio 可以在 Chrome OS 上使用。

What’s new in Android accessibility

一開始提到目前全球有數十億的殘疾人口，其中有 1.5億的人難以處理基本的日常生活，例如簡單的拿一杯水、出門或看網路視頻等等的，對他們而言這些動作不是那麼容易實現， Google 打算用科技的能力來改變這一點，共分為以下幾個議題：

• Hearing
  在日常生活裡環境噪音是最不需要的聲音之一，常常會干擾與朋友的交談，目前 Google 增強了手機上的訊號引入了聲音放大器，幫助用戶可以專注於對話。
  聲音放大器基礎建立於四個階段的信號處理，第一階段是 Pre EQ 、第二階段是 Multi-Band Compressor、第三階段是 Post EQ、最後一階段是 Limiter。

• Motor and Dexterity
  在部份用戶日常中無法單手完成手機上的特定功能，因此推出了 accessibility menu ，這功能簡化了以下功關機、鎖螢幕、截取螢幕畫面及音量的控制等，手勢只要向上滑動就可以出現最近的使用的應用程式、通知及快速鍵，此外也設計成非常大的觸摸目標這可以方便手比較小的用戶使用。

• Vision
  發表了一款新的應用程式叫 Lookout，他對盲人或視力不好的人用有幫助，可以在一個新的空間裡幫助找到椅子或剪刀等的物品的方向，因此 Lookout 是幫忙用戶可能簡單的知道實體空間中的物品方位，只要透過穿戴掛在身上或放上衣口袋裡不必取出設備就能很快速的讓 Lookout 幫忙告知目前空間裡設備的方向。

• Cognitive
  在一年前有推出叫 Select 的服務，針對閱讀困難的用戶，現在加入了 OCR 的功能可以讀取圖片中的內文。

• User Research
  主要研究什麼樣的開發對用戶是最好的，所以需要做使用者分析試圖了解用戶行為、需求及動機，因為在10個創新公司有9個是失敗的，但大家可能不知道失敗的第一個原因就是缺乏產品的市場需求，所以在這情況下設計開發的產品需要先尋找可能有興趣使用他的用戶，通過用戶可以驗證你的想法是對的。

What’s new with Android TV

今年 Google IO 發表了 Android TV 新功能，首先 Google Assistant 的整合，將會是未來硬體發展的重點方向，影片最後介紹了 JBL Link Bar 支援 Android TV 與 Google Assistant
看得出 Google 對未來利用 Assistant 整合家電設備市場的重視與企圖心。

Google Assistant 支援 android M 以上的版本，以下三個步驟可以讓你使用 Google Assistant

• Content search
• Deeps link into your app
• Playback control

另外，Android TV UI 提出了「Content First」設計以提供使用者更好的體驗，首先可以看到 Apps row 從原本兩行變成一行，並且讓使用者可以自行設定喜愛的 App 顯示在這個區塊。原本 Recommendation row 從 android N 以下都將拆分為以下兩部份來顯示

• Play Next
  這邊主要加入曾經播放尚未完畢的內容，可以吸引使用者再次接續收看

• App Channel
  Android TV 可以讓開發者建立自己 App 的頻道，頻道內容加入詳細說明與預覽功能，讓使用者更有機會接觸到 App 中可能有興趣的節目

最後介紹 Android P 以上支援的新功能，在 Performance 方面，為了支援低階硬體的 Android TV 裝置，提供 isLowRamDevice() 判斷裝置記憶體容量等讓開發者調整效能的方法。還有支援了藉由手機快速首次設定 Android TV 的功能，包括 Play auto installs (自動安裝手機中有支援 Android TV 的 App)、Autofill with Google (Android TV App 帳號密碼 Google 認證自動填寫)、Suggested settings (提供建議使用者的設定選項)

Build with Google Pay

主持人在整場演說興奮了很多次 XD，主要是興奮 Google Pay 在全世界推行的非常好，且 Google Pay 經由 App 或 Web 等各種平台所得到的消費資訊，現在都會整合到 Google Pay 用戶管理介面並提供更全面的資訊與操作。

在 Google Pay API 的主要優化包括以下幾項

• Cross-Browser
  JavaScript for the Google Pay API for checkout

• Cross-Surface
  API use a very consistent JSON

• Streamlined
  Enhance the ready-to-pay API to streamline the checkout experience

Android vitals: debug app performance and reap rewards

當用戶在 Google Play 給出 1 星評價時，其中 42% 的 user 都會提到 Stability & bugs 的問題，而在給 5 星評價時，73% 的用戶會提到 Speed, design & usability，因此 App 的效能是件很重要的事情。效能同時也是你的 App 能被用戶搜尋、被 Google 推薦與得獎的重要的指標。

Google 在去年推出了 Android vitals 提供各種資訊來讓開發者增進 App 的效能。Starbucks 透過 Android vitals 發現了一個 3rd party library 的 issue，因此降低了 70% 的 ANR rate，也透過它來降低了 85% 的 crash rate。Subway Surfers 這款遊戲 App 透過 Android vitals 降低了 95% ANR rate，同時也增加了 9% 的 DAU。

Google Play Console 除了去年已經提供的 Battery、Stability 與 Rendering 報表，現在多提供了 App startup time 報表，其中包含 Slow cold start、Slow warm start 與 Slow hot start 的數據，也提供了可以看 Permission requests denials 與 Category benchmarks 的數據，同時也發表了 Anomaly Detection 功能，可以偵測 ANR 或 Crash rate 的劇烈變化，並即時利用 email 通知開發者。

第三位講者提到在如何在你的 App 裡面改善 Core vitals。例如在開發時使用 StrictMode 來找可能發生 ANR 的原因。面對 Crash 的問題，講者建議使用 Android Jetpack 的各個元件套用到你的 App 之中，或是根據你的需求使用其他第三方套件。另外，Kotlin 本身 null safety 的特性，也能讓 App 開發者避免這些冗長的判斷。

最後，Android P 也開始限制使用 private / hidden API，在 Battery vitals 的部分，講者則是講到 wake lock 的 leak 的情形，當呼叫了 acquired wake lock，卻沒有在適當的時機做 release 就會造成這個狀況。如何避免這個問題呢？講者說就是不要使用 wake lock，因為現在已經很少需要用到 wake lock 的需求了，取代的方案可以在 Activity 中，使用 FLAG_KEEP_SCREEN_ON 屬性，對於 Services 則可以利用 JobScheduler 來處理。當過度呼叫 AlarmManager 時同樣也會造成 Battery 的 issue，因此，若可能請移除它或者降低頻率，又或者可用 FCM、WorkManager、JobScheduler、SyncManager 取代他。最後，Android Profiler 也新增了 Energy Profiler 可以讓你看到相關的細節。

Grow and optimize your subscriptions with new Google Play features

Google Play 中對於減少用戶流失與增加用戶體驗新增了一些新功能

• Real-time developer notifications (Google Cloud Platform Pub/Sub)
  當用戶的訂閱狀態改變時獲得通知，以便在他們自願退訂的時候，即時提醒他們訂閱的好處或給出優惠，誘使他們重新訂閱。

• Account hold + grace periods (寬限期)
  讓因付款失敗的用戶繼續保有訂閱身分，並送出通知，提醒他們更新付款方式，這麼做可減少70%的非自願退訂。

• Play Console subscriptions reports
  play控制台提供良好的反饋，以便開發人員分析業務並做出優化。

• 新的 Google Play 訂閱中心
  因為即使用戶知道能從訂閱中得到許多價值，但他們卻猶豫是否要訂閱，原因是他們認為取消訂閱可能很麻煩，甚至覺得會被困住而無法取消，或是擔心自己無從追蹤自己花了多少錢在訂閱上。為了解決這個問題，Google Play 更換了一個新的訂閱中心，為用戶提供更多的訊息與操作，開發人員也可透過 Deep-link 的方式，在應用程式中呼叫出訂閱中心，管理有問題的訂閱項目，另外，當用戶取消訂閱時，需先選擇取消訂閱的原因，開發人員即能在控制台中找到取消訂閱的報告。

• 新的退款機制
  現在可以使用 order ID 進行退款，這就表示也能退還過去週期續訂的訂單，而且，也能選擇部分退款，還可以修改 SKU 的金額，Google Play 會在用戶續訂前通知用戶，要求用戶同意價格變化。

• 新的訂閱報告
  新特性讓查看特定群組變得更靈活，可以使用不同指標，像是 SKU、日期、國家等等，來分析訂閱報告，這裡甚至可以告訴開發人員是怎麼贏回訂閱用戶的。

What’s new in Android Runtime

主要有三個重點

• 優化 Kotlin 效能
  使用一套研究方法來優化 Kotlin 的效能並排定優先順度以確保多數的 Kotlin 應用程式可以獲得改善。首先嚐試在 kotlinc 編譯器解決問題，其次是 D8/R8 bytecode converter 中嚐試解決，最終才是在 ART 解決，但若在 ART 修復即代表必須更新系統才能獲得效能提升。

• 針對 Entry-Level 裝置去優化記憶體以及儲存裝置
  在 dex 檔中程式碼和字串佔了 64% 的尺寸，這就是需要被優化的重點，方式包括去除重複的 Code Item、去除重複的 Multidex Data、引入新的 Dex layout optimization

• 新增 Cloud Profile
  裝置可以收集 JIT 編譯器產生的 Profile 並上傳至雲端，這可以改善安裝 App 時的效能，根據 Google 自家 App 使用狀況分析，此做法可以提昇約 20% 開啟時間，開發者也可以使用 Google 提供的 Dynamic Delivery 優化 APK 大小。

What’s new in Android development tools

今年年初發布了 Android studio 3.1 主要加強了 build, emulator 的速度、SQL Editor、Kotlin lint、Profiler、SVG preview。

而這次 I/O 帶來了全新的 Android studio 3.2 如下

• Android P Developer Preview
• Android App Bundle
  依 CPU、螢幕大小、語言…等生成多㮔版本的 APK ，此外也可以新增 Dynamic Feature Module 讓用戶按自己的需求下載安裝。
• Android Jetpack
  將 Android support v4, v7 整理成 androidx 並提供轉換工具、新增 Navigation library 更簡單的規劃實作整個 App 頁面的流程及 Deep link、Material theming（Chip, BottomNav Layout）。
• Tool
  可儲存多個 profiling result 供比較、新增 Systrace 查看 kernel 內資訊、新增 Energy profiler 分析 CPU, network, wake lock… 資訊、 Emulator 變快並且加入了相機預覽及 AR 套件。

最後再分享一些可能再未來版本出現的新功能，像是規代中的新一代 Constraint Layout，能用 ConstraintSet 更輕鬆的做到更複雜的動畫，另外在 Chromebook 上也可以使用 Android Studio（ 雖然 ADB 暫時還不支援 ）

Drawn out: how Android renders

Android 繪製頁面是從 Root layout 開始，一層一層尋訪 ViewGroup 及它的 child View 後，將之設定至 Schedule Traversal 依序繪製。

而在繪製 layout 的過程有兩道程序，其一是 measure，如前言所提，會依層級從上到下將每個需要繪製的 View 的尺寸規格都計算完畢；其二則是 layout，會將所有 View 都定位妥當並根據前一道程序得到的數據進行繪製。

講者一步一步的透過簡報介紹了流程，並提到更多的有趣的 render sample 可以在這裡看到：https://github.com/google/grafika

Getting started with App Actions

使用者在手機內可能裝了上百個 App，提升回訪率是一個很困難的問題。使用 notification 和 email 是提醒使用者使用 App 的手段，但可能會被使用者覺得煩。因此使用對的手段在對的時機點，簡單地預測使用者下一步想執行的動作 (Action) 是很有幫助的。App Actions 的主要目的就是連結使用者，提升 App 的回訪率，並整合到整個 Google 的整個生態系(Android launcher, Smart text selection, Google Play Store, Google Assistant, Search App)，可以讓使用者更方便的使用或探索已安裝 App 的功能。

影片中詳細的示範了 App action API 的整合步驟、測試方式、如何提交 action 給 Google。包括利用 Android studio 新提供的 Actions test tool，然後提交到 Actions on Google 的 preview mode 供開發者做測試的流程。

The future of apps on Android and Google Play: modular, instant, and dynamic

為了解決在不同裝置上的 APK 建置及發佈困難、會使用戶降低下載意願以及增加刪除傾向的龐大 APK 的問題，未來將會以 Modular Development、Instant Discovery、Dynamic Distribution 方向進行。

去年發表了 Instant App，而今年 Android App Bundle 的出現簡化了建置及上傳 Multi-APK 的過程，開發者不需要再自行管理 Multi-APK，只需要跟之前一樣利用 Android studio 或 Gradle 建置 App bundle 並上傳，就能到 Play console 的 bundle explore 查看共分成了哪些 APK 以及各自的大小，除此之外也新增了 Dynamic feature 能夠模組化的開發新功能，讓依照裝置支援程度及使用者意願下載。未來也將支援 Instant App 中的模組和 Dynamic feature 中的模組互相轉換的功能。

New and advanced Google Play tools for game developers

Play Console 針對不同階段 (Pre-Launch, Launch, Post-Launch) 提供了一些工具，幫助遊戲開者改善品質與體驗。

Pre-Launch 階段著重在 Testing，Internal Testing, Closed Testing, Open Testing, Pre-Launch Report。

• Internal Testing 讓開發者可以更快速地發佈版本變更，進而改善測試的品質。
• Closed Testing，開發者可以透過 Play Console 發送 Email 或 Google Group 邀請合適或特定族群的測試者，並建立測試者論壇收集回饋。而和 Closed Testing 相反，只要發布 Open Testing 任何人都能在 Play Store 參加測試並回饋意見。
• Pre-Launch Report，這份報告是 Test Lab 中的 Bot 在實體裝置執行後並產生的，Demo Loops 則是透過 Firebase Test Lab 產生 PLR, Crash, Performance 的報告，這些報告可以幫助開發者提早發現問題。

Lauch 階段提供了 Device Catalog, Pre-registration, Country Targeting。

• Device Catalog 幫助開發者針對不同的裝置做出更好的策略或問題修正的方向，從 Device Detail Page 可以觀察 APP 在特定裝置上運行的狀況，及針對該裝置 Active 數量、平均 Rating…等。
• Pre-registration 對於用戶而言可以提早關注有興趣的遊戲，當遊戲發佈時會收到 Notification。對開發者而言，行銷上多了一些優勢，從 Pre-registration 的數量也可以提早為發佈做準備。
• Country Targeting 可以針對區域進行不同的測試或發佈，對不同區域獲得的回饋對遊戲開發有很大的幫助，甚至可以只先針對部分區域發佈，並觀察各項成效來調整策略。

Post-Launch 主要的三件事為用戶數量的成長、提高用戶的參與度和增加收入。

• Organic Acquisition Insights Report 可以看到用戶的來源(搜尋的關鍵字、Play Store 瀏覽…等)。
• 支援 Google Play Instant 可以在廣告或 Pre-registration 讓用戶試玩。
• 使用 Vitals 觀察 APP 的數據(電池用量、穩定性、效能…等)，並改善使用者體驗。
• 尚未 Release 的 LiveOps 會在 Play Store Detail Page 顯示目前遊戲中的活動訊息。
• 提供遊戲訂閱制，除了增加收入之外，訂閱後的用戶黏著度普遍比訂閱前高。

Build the new, modular Android App Bundle

Android App Bundle 是一個新的 APK 發佈格式，上傳後會透過 Dynamic Delivery 針對使用者的裝置需求彈性提供適合的 apk 並減少約 20% APK size，降低使用者下載時間與空間的限制，而開發者也可以將非主要功能模組化，讓使者用真正需要的時候才下載。

Android App Bundle 與 apk 很相似，包含所有 app 的程式、資料，但使用者並不能直接安裝 app bundle 檔，其可被分解成多個區塊，包含主要功能的 base apk 與其他外觀顯示的 configuration apk，Google Play Store 會視使用者的裝置規格，提供各種不同組合的 APK。

目前在 Android Studio 3.2 的 Build 選單中，已經有提供 Build Bundles/APKs 的功能，其流程與建置 apk 一樣。

此外，當然也能經由 gradle 執行，建置 APK 的指令如下，若要建置 app bundle，只需將 “assemble” 改成 “bundle” 即可。

在完成建置後，接下來就是測試了，因為 App Bundle 無法安裝，那麼該如何測試呢？有兩種方法：在本地端使用 bundletool 或是透過 Google Play Console 提供的 Internal Test Track。
最後提到將 apk 功能模組化時，需考量三個問題：有多少使用者？ 該功能佔了多少空間？ 使用者是否禁得起等待即時下載獨立模組？ 建議是較少使用者開啟的非主要功能較適合。

Modern Android development: Android Jetpack, Kotlin, and more

首先介紹在 Android Studio 中的好用工具，Layout Inspector (可替代 Hierarchy Viewer)、Profiler (可替代 Trace View)。

再來談到 Kotlin 讓 code 變得更易寫易讀，並且一個 project 中可同時存在 Java 和 Kotlin，所以不需要一次就將所有的 code 轉成 Kotlin，在 https://android.github.io/kotlin-guides/ 有 Kotlin style guide 和 interop guide。

之前常有開發者問 Google 要使用哪種架構來寫 App，但 Google 官方說法是他們沒有一定的標準，選擇符合 App 需求的架構即可；而現在有了 Architecture Components 讓開發者來使用，Architecture Components 可以幫助管理複雜的 Android Lifecycle 且更有效的管理資料(LiveData, ViewModel, LifecycleObserver, LifecycleOwner, Room)

Analyze your audience and benchmark metrics to grow on Google Play

這場議題介紹了 2018 上半年 Google Play Console 推出了哪些新的工具。講者認為每個 App 開發者最在意的事情有「用戶發現、獲取用戶、用戶安裝、使用次數、移除、再次安裝、流失」這些，而 Google Play Console 近期就是在這些範圍積極的想增加對開發者有用的報表與工具。

在用戶發現，即到訪但未安裝服務的方面，官方提供了客戶在各種情境發現 App 的比例報表，例如搜尋時、瀏覽時，甚至是搜尋時用了哪些關鍵字，讓開發者知道由哪處加強行銷與廣告，是否修改文案或圖案等。在使用過程中，新的 Events timeline 報表可以看出哪些事件造成 engage 量的起伏，例如某次新版上線、推出新價格方案等事件。在近期 Firebase 也提供了 Firebase Predictions 功能，透過 AI 對未來可能產生的移除、新用戶數量進行預測。新的 Subscription dashboard 加入了讓開發者選擇國家、商品等條件進行各別分析，開發者可以看出購買某些價格方案的用戶可能持續性支出較高，還會列出用戶取消付款的數項可能原因。最後是 Win-back 這個重要指標，目前還沒有實際上線的新功能，但未來會針對用戶在哪些事件、哪些時間、來源等因素而 uninstall 的報表。其他相關報表也加入了日收入、日 Crash、日安裝等更細的範圍。

Android Slices: build interactive results for Google Search

講者首先介紹 Slices 的目的以及特性， Slices 的目的是希望為了幫助用戶透過 Google Search快速獲得想要的資訊或讓用戶能夠即時與 App 的互動，所誕生出來的一個元件。這個元件有四個特性，第一個是樣板化， Slices 提供許多的模板供開發者做使用。第二個是互動性， 用戶在 Slices 上，就可以點選 Slices 觸發 action 達到例如開關 wifi / 訂房的目的。第三個是可更新性， Slices 是 Jetpack 套件中的一部分，更新速度會比傳統 Android 平台 release 的週期還要快。最後一點是相容性，這個功能在 KitKat/API 19 後都是可以使用的。

Slices architecture，這個部分則是談到 Slices 整體的架構為何，是如何運作的，首先 Slices 是一個結構化的物件，slice 的列表物件中會包含其他小 slice 的物件，一層包一層的資料結構。Slices 的架構是建置在 ContentProvider 之上，Slices 的 UI 介面會送一串 URI 告知 APP 的 ContentProvider ，解析後回傳適當的 Slices 給 Slices UI 介面，讓介面能夠產生相對應的 UI。

如何建置 Slices? 首先需要定義 SliceProvider 在 AndroidManiefst.xml，接著將完成 SliceProvider 並在 onBindSlice 去建立 Slice 物件，然後定義 BroadcastRecivier 做事件處理，最後則是透過 SliceViewer 這個測試工具來做驗證。 講者在下個部分則是談到使用 template 來建置 Slices， Slices teamplate 有很多種類型，有 list ， grid ，進度條，圖片 … 等，有許多模板可以使用，與前者示範的差異是在於建置的 builder 不同，透過 GridRowBuilder 就能建立 grid 模板的 Slice。

Slices 在 Google Search 中主要有兩種方法來觸發，一個是從 App names 觸發，輸入特定 App 的名稱 (例如 Youtube)，該 APP 如果有實作 Slices 機制的話，就會在 Google Search 頁面呈現對應的 Slices，要完成這個功能要注意兩個地方，MainActivity 需要和 Slice URI 做連結，第二個則是需要去要求 Search & Google Play services 的權限，關於開發者要求 Slices 權限時，需要注意的有，必須透過 SliceProvider 來向使用者要求權限，切記的是，不要在 Manifest 定義 permission。另一種觸發方法是 General Terms，輸入像是 data 到 Google Search 的介面中，Google Search 會產生對應的 Slices 元件，例如手機傳輸資料的設定給用戶，讓用戶快速地去做適當的處理，要如何達到呢? 需要透過整合 firebase 的 app indexing。

What’s new in automotive

今年 Android Auto 最重要的是與 Google Assistant 的整合、針對 Messaging 與 Media 可用聲控操作、增加駕駛人便利與安全性。

在 Messaging 方面新增了 Group Message Style，在 Media 上提供管理瀏覽物件排列結構與設定可播放物件的詳細資料與播放控制台支援的功能，且實作 MediaBrowserService.onSearch 即可支援 Google Assistant 搜尋結果。

在 UI 上可針對搜尋結果定義群組，不同於以往清單式的瀏覽資料呈現，現在可以切換格狀排列，建議用於可播放的內容，格狀排列可顯示更多細節資訊。

What’s new in Android Things

傳統的智能裝置只能送往雲端，現在可以更多的在裝置上運算以改善延遲問題，這就是 Android Things 的目標。Android Things 是為 IoT 裝置設計的，是一個全面性的管理者。

Android Things 的目標是：如果你會實作一個 Android app 就能使用 Android Things 照樣做出一個 IoT App。

現在 Android Things 1.0 已經公開上線，目前已經合作的裝置有 LG 的 smart speaker 與 Lenovo、JBL、LG 也有出影音閱聽裝置。

軟體方面因為 IoT 裝置跟 Android 裝置不太一樣，不一定會有螢幕，因此拿掉很多 UI 介面的部分，Android Things Support Library 也會提供控制硬體層的 API、Device Configuration 和 Security 等 API。

Android Jetpack: how to smartly use Fragments in your UI

這一篇講了一些 UI 架構的變遷與調整。

早期 Activity 是 UI 的主體，後來越來越複雜的功能，以及 tablet 的崛起，設計出了 Fragment。
Fragment 可以做到大部份 Activity 能做的事情，但在收到許多開發者回饋的意見後，在 Architecture Component 內推出了幾項新的架構。
LifecycleObservers 的出現，可以協助開發者自主決定 view 在每個 lifecycle 階段要做的事，且可以獨立測試。
ViewData 可以用於取代 Fragment 的 RetainInstance，儲存資料，也可以自定義更新資料的邏輯，View 可隨時與資料重新建立聯繫，且可以獨立測試。
而 Navigation 可以掌握各個 View 的切換，解決 Fragment transection 的各種弊端，比如狀態揭露不全等等。

既然 Fragment 有這麼多問題，已經設計出了這些新的架構，那為什麼還需要 Fragment？ 因為如果只使用 View，那 View 又做太多事情了， View 應該只要做好顯示及回報 user 行為，關於 lifecycle 或更高層級的掌握還是應該由 Fragment 掌控。

講者提到 DialogFragment 仍然是很值得使用的，但 Android 也提供了其他選擇，比如 snack bar，在非必要中斷使用者使用流程的訊息時使用。

接下來回答了一些開發者常問的問題，如 option menu 的使用、如何測試 Fragment、Loaders 現在已經跟 Fragment 互相獨立了。

最後展望一下 Fragment 之後的演進計畫。（FragmentManager 已經 Deprecated 了）

Build real consumer devices with Android Things

這篇在講如何利用 Android Things 做成的 prototype，在短短幾個月做成 production level 的東西。

藉由 Android Thigns，他們很快的做出 Smart Display 的 PoC，讓他們可以 demo 他們所構想的 key use cases。他們第一個做的是字幕機，將你所說的話逐字顯示在螢幕上。接著做了他們稱為 Knowledage card 的東西，可將文字的意涵以及圖片顯示在畫面上。雖然 PoC 的硬體沒辦法播放影片，但它具有播放串流音樂的能力，因此他們也做了個可以播放/暫停音樂的功能。最後他們也在螢幕閒置時加上 photo slideshow / 顯示天氣預報的功能。以上功能大約花 2 個禮拜以及少許人力完成，過程中就利用這個 PoC 進行討論及修改。做出 PoC 後，接著就是找 potential OEM partner 來製作並販售產品。同時，他們也最終確認系統的最低需求，也花了很多時間針對 Application 的部分進行調整。中間講述了一些他們為這個 PoC 設計並製作 case，也講到了關於 SoM 的部分的規格，分別選了哪些晶片，並且幫你把那些東西都整合好，也制定了 reference design，同時也讓 OEM 廠商可以自行決定某些部分的東西。最後講到了整個開發過程中間需要經過哪些 Validation test，都通過了之後最終才成為產品。

Android Jetpack: what’s new in Architecture Components

去年的 Google I/O 發佈了 Android Architecture Component，在過去一年得到了許多回饋也修正了很多問題，今年新增了 Paging, Navigation, WorkManager，而 Data Binding 也在今年正式成為 Architecture Component 的一員。這篇影片簡單的介紹各個元件的變動與新元件應用。

• Lifecycle
  Observe LiveData 時可以提供自訂的 LifecycleOwner 改善了 LiveData 因為 Fragment Lifecycle 而產生的 State 問題。
• Data Binding
  從 3.1開始支援 LiveData，Compiler 的部分也進行了效能上的調整與對 Instant App 的支援。
• Room
  從 1.1 開始支援 WAL，讓 DB 的讀寫可以平行處理。@RawQuery 解決了 @Query 遇到動態 Query 需要手動組成SQL 語句，必須回到原始 Cursor 寫法的問題。
• Paging
  當 RecyclerView 有大量資料需要顯示時，使用 Paging 開發者可以更容易管理 Memory, Database 和 Server 的資料，除此之外，和 Room、RxJava 也有很好的搭配讓開發者更容易實作。
• Navigation
  統整 App 轉換畫面時遇到的各種麻煩事 (Fragment Transaction、Animation、Back Stack…等)，可以簡單透過 XML 管理。
• WorkManager
  整合了 Job scheduler、Firebase Job Dispatcher、Alarms Manager，提供更簡潔的寫法，每個 Worker 可以自訂 Constraint、Input/Output、Error Criteria，甚至可以串連不同的 Worker。

Improve app performance and stability with Firebase

這部影片主要以實際 App 作為例子說明如何使用 Firebase 來建置品質良好的 App。

以下是影片提到一些新增的事項：
– Firebase Test Lab 現在支援 iOS & Android 跨平台服務。
擁有超過 1000 種裝置來提供多方面的測試環境。
且使用上也很簡單，只要將 Apk 丟上去即可，剩下的就是 Test Lab 的事。

• Crashlytic 已經可以在 Firebase 上使用了。
  Crashlytic 目前已經在超過 30 億的裝置上使用，且處理了非常大量的 Crash Data。
  在經過分析後，將 Crash Data 整理後顯示在 Dashboard 上以方便開發者找出問題。
  且提供 Email 通知新的 Issue 狀況。

• Firebase Performance 也可以使用了。
  這是一個支援 iOS & Android 的 SDK，它可以收集許多從使用者角度上關於你的 app 使用資訊。
  新增 Rendering Data 以讓開發者可以更了解問題點對應到程式的什麼地方。
  像是 Frozon Frame，現在可以告知問題是出在哪個 Activity。
  新增 Issue Feeds，可以幫助開發者哪個 Performance Issue 應該優先被解決。

• 開源以 Firebase 為基礎寫的一個 App : Friendly Pix

• 可以使用 Slack 傳送通知了。

Protips: a fresh look at advanced topics for Android experts

過去十年來 Android 變化的很快，這對於開發者及使用者都是件好事，但新版的 API 對於開發者來說通常需要做點取捨，像是新的功能、舊版本用戶的相容性…等，因此有了 Jetpack 來幫忙處理上下相容的問題，開發者可以更專注在給予用戶好的體驗。

而目前 Android 有了根本上的變化，像是 Kotlin 成為官方支援的語言、引進了 Architecture Component: VIewModels, LiveData, Room Database 大大的改變了我們管理資料及 Activity 生命週期的方法、和為了解決 Android O 傾向於 kill service 而出現的 JobScheduler，但事情改變的很快！就在現在 JobScheduler 也被棄用了，取而代之的是 WorkManager，它解決了 Job Scheduler 只支援 api 21+ 裝置的問題，不需再依裝置判斷該用 JobScheduler、Firebase JobDispatcher 或 AlarmManager 了、取代了 GCM ( Google Cloud Messaging ) 的 FCM ( Firebase Cloud Messaging ) 、取代 Location Manger 的 Fused Location Provider 封裝了大量的實作細結及簡化使用的便利性，也因為 Android O 的背景限制下出現了 Proximity alerts，但由於效能上的的問題衍生出了 Geofencing API 及 Awareness API、取代了 Mediaplayer 的 Exoplayer。

儘管開發的工具、 API 的改變很大，但驅動著整個 Android 開發進步的是社群。

Release management: successful launches and updates on Google Play

Google Play Console 提供一連串上架過程中可利用的測試功能，包括 Alpha、Beta 項目或是 Internal Testing，讓開發者可以經由更改 verison code，讓 Google Play 提醒測試人員的裝置有新版本，達成快速迭代的目的。

開發者現在能利用 Gradle Play Publisher 這種 library 快速上架至 Alpha 或 Beta 之類的項目，讓上架手續更為迅速；另外 Google 也強化了 Publishing API，讓開發者可以更有彈性的客製化自己的 CI/CD 流程。

Build for Android (Go edition): optimize your app for global markets

Android Go 為初階手機的使用者建立一個能使用優質硬體與軟體的生態系統。

Google 做過全世界的使用者調查，發現使用者在使用入門級的手機有特別的痛點，APP 使用起來不太順暢，在入門級的手機上，這些手機包含了處理器速度，容量大小，電池壽命都較為低階。不論是在開發者或是使用者的世界，都會用到這些較為低階的裝置，所以 Google 和 OEM 的合作夥伴發起了挑戰，希望能在這些類型的裝置上提供更好的使用者體驗。

接著深入探討手機容量，效能和安全性，根據之前所提到的使用者調查，大約有 2/3 的使用者手機的容量小於 8G。在 2018 年，拍照、下載APP、下載遊戲都會需要手機容量，因此 Google 有責任帶頭以身作則做得更好，讓使用者有更多的容量來使用，確保在這些入門級的手機上能順利的運行。

有一些產品團隊決定移除一些功能，有一些團隊決定對這些特別的裝置加入特別的功能，其中之一特別有名的是 File Go，讓使用者能整理他們的手機空間，使用者對這款 App 有很高的評分。安全性對 Android 系統來說是很重要的，所以發布了 Google Play Protect，它就是像一個標章，讓使用者對他們所讓下載的 APP 和遊戲感到安心。

在過去的十年間 Google Play 上的 App 容量一直再增加，在過去的五年增加了 250%，App 容量的大小對於影響使用者的下載意願有很大的影響，APK 大小每多增加 6MB，就可以看到下載的轉換率降低 1%，這個趨勢可以套用在小於 100MB 的 APP 並且全球通用。App 越大，使用者成功完成下載 APP 的機率越低，有可能因等太久，而取消了 APP 的下載，在入門級的手機影響更為明顯。

在對於 Android Go 優化 APK 的過程，不只是對使用 Android Go 手機的使用者有幫助，同時也會對所有使用此 APP 的使用者有幫助，這些人可能是使用高階的手機。第一步要設定 target SDK 為 26 或更高，可以確保讓使用者使用到最新的 Android 體驗。

第二步為降低 APK 容量，對於 APP 來說要小於 40MB，對於遊戲來說，可以到 65MB，包含來打開後的第二次下載。從記憶體的使用來說，APP 一開始使用到的必須小於 50MB，對遊戲來說，可以到 150MB PSS (Proportional Set Size: 為 APP 所使用到的記憶體加上 shared 的記憶體)。

APP 的開啟時間，要小於五秒鐘，迅速地開啟能避免被使用者移除，要確認 APP 的開啟時間，可以使用 Firebase Performance 來測量，會自動統計並將結果會顯示後台上。

並沒有特別 Go 版本的 Google Play，只有 Google Play 對 GO 版本特別優化，所以的使用者應該都可以使用到優化後的版本。為了提升在 offline 的體驗，在連線到 wifi 時，Google play 會盡可能地將資料儲存到 cache，在網路連線不佳時，也能瀏覽 cache 的內容。並加入了另外一個功能，當手機重新建立連線時，通知使用者在斷線時想要看的內容已經好了，可以給使用者良好的體驗。

最後有四點做總整理：

• Android Go對開發者是一個很大的機會，讓App可以讓全世界的使用者使用，不會因為硬體而有所限制。
• 開發者盡量讓App容量小一點。
• 開發者要進一切努力提升APP品質。
• Google play會提升這些使用者的App體驗。

Build effective OEM-level apps on Android Things

如果你想要在 Android Things 上開發一些東西，該如何規劃你的服務，以及需要遵守一些什麼規則，這個 session 主要就是在跟你說這些事情。

首先，Android Things 上不一定會有螢幕，permission 是否被授與的狀況就不會在 runtime 時決定，取而代之的是會在 Android Things console 授權。Android Things 1.0 後將不再自動在 reboot 時給予權限，你必須自己透過指令來給予授權。

即使裝置上可能沒有螢幕，Activities 還是有存在的必要，例如他能處理 User input events，像是經由觸控螢幕、Game controller 或是鍵盤等等，也能處理 orientation change 一些與 lifecycle 有關的狀況。除此之外，你應該要把事情分散給其他元件來處理。

與 mobile device 大約有 2 ~ 4G 左右的記憶體相比，Android Things 上大約只有 512 MB ~ 1G 的記憶體可以使用，且每個應用程式可使用的 Heap size 也有限，也被限制在一個固定的大小，因此將會常面臨到 GC 相關的問題。若直接將 mobile 上的 App 直接 porting 至 Android Things，所有關於 object allocation 的部分都將要特別注意。由於在 Android Things 上，唯一一個應用程式就是你的 App，你必須妥善利用裝置上所有的資源，處理方式就是將程式分成多個 process，例如分為前景的 Activity 與多個負責不同功能的背景服務。

另外，講者建議用 bindService() 來啟動 background service，藉此可以讓 background service 能主動與 foreground app 做連結，因此你可以知道 service 何時正在運行，又或者因為某些理由而結束運行，讓你可以自行決定是否要重新運行這個 service；同時，利用 bindService() 也可以讓 foreground app 與 background service 直接溝通，而不需要靠 Intent 等來傳遞資料。最後，在管理專案時，你可以在 Android Studio 裡面建立 Android Things Module，讓多個 apk/process 在同一個專案中管理。由於 Android Studio 一次只能 deploy 一個 module 到 Android Things 上面，因此講者建議使用 Gradle CLI 一次把所有 modules deploy 到裝置上，最後再透過 adb 指令來跑特定 component or activity。

Android Jetpack: what’s new in Android Support Library

為解決 Support Library 版本不夠直覺且已造成混淆的問題，像是最小支援的 SDK 版號為 14，但其中有些套件或組件版本為 v7，因此釋出了 AndroidX alpha，計畫完全取代 Support Library。但因現在仍屬於 alpha 測試版本，不建議開發者使用在線上產品。

AndroidX 新元件包含 RecyclerView Selection、RecyclerView ListAdapter、Androidx.webkit、Browser library、HeifWriter、Slices、MaterialComponents。
RecyclerView Selection。

關於轉換至 Android Jetpack 的步驟與上述元件的使用詳情可以參考影片。

This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International License.