code

2018年7月22日 星期日

Google IO 2018 - 用Android App Actions與Android OS深度整合

將現有的android app與android深度整合

Google assistant有個關鍵的entity叫做actions,那什麼是actions?



由於使用者非常少會再重複使用一個app (reengagement is low!!!),所以Google想要協助app developers把app的功能(actions)展現給使用者看,透過AI自動判斷目前使用者可能需要做的動作(Actions),而不只是App。

如果一個android app定義了自己的app actions之後,則這就是一個快速跟Google assistant app接口的方法,使用者可以透過Google Assistant做出task-based query,我們的android app actoins也能獲得展露頭角的機會。




 甚至是content-based query,google assistant會預測接下來使用者的動作,同樣也能讓我們的app actions浮現上來(例如以下查詢lady gaga的姓名,google assistant預測可能接下來的有許多買票或是訂購音樂相關的動作:)


也能在google search bar下方的action prediction出現:(android O之後)


還有就是一些OS深度整合(例如text selection預設action):



總之只要implement了app action,就有機會跟android平台(不只是手機OS) 做深度的整合。


Semantic Intents

Google已經幫我們把下圖中左邊的語意換成右邊的Intent with params:



我們programmer要做的就是在我們的apk中加入actions.xml,然後定義好裡面的fullfillments。


所謂intents,其實是一個semantic intents(注意這不是android intent! 這是Actions by Google這個平台定義的semantic intents),是需要被Google service分析過後的結過,而fulfillment是一個deep link直接指向我們app內可以提供內容或是action的頁面。以上兩者構成了actions.xml。

Semantic intents不是只有給android actions用而已,他可以在任何Google assistant能出現的地方,都被當作是一個intent。

這邊有一個可以integrate的東西叫做usage logging(透過Firebase app indexing api),這個可以幫助Android 將action suggestion 個人化(how?)



目前google 提供了不少built-in intents,當然還在持續增加中:





勁量使用built-in intents,因為這樣Google已經做好所有的semantic analysis,也不會有什麼ambiguity的空間,而且多國語言的語意分析也幫你弄好了,基本上只要專注在準備fulfillment就可以了。

App Actions基本上是黏著semantic intents和android intents的橋樑:



用URL當橋樑的好處是,這個資料型態還能符合很多其他的服務:




 Fulfillment

fulfillment可以有兩種model來形容:


 1. url template model: 基本上就是對那種app就能解決的問題來說適合的。此時actions.xml裡面定義的url是一個app中的deep link,而所謂的template就是語意分析引擎會把分析出來的參數填入url template中的place holder部分,這樣deep link到的頁面就能處理。

2. content-driven model: 這對content serving action有用,而且通常content會連結到網站上,所以此時的actions.xml中的url就是連結到某個我們有所有權的網站中的網頁,當然能夠符合structured data形式 (可以說semantic intent定義了動詞,而structured data定義了名詞或是受詞)是最好,這個要另外一篇來提了。



測試與提交actions.xml

這其實是把actions.xml送到 Actions on Google這個平台資料庫,這樣讓所有安裝google assistant的device (不限於android devices)都能使用。對android app來說,最簡單的提交方法就是放在apk裡面,然後submit到google play console:



不過在提交之前,要先測試吧!
Android studio有一個plugin叫做actions test tool可以用來測試actions.xml是否正常運作:



這個plugin能讓developer account單獨看到actions(即便submit到Actions on Google的database),其他使用者不會被影響到,接下來就是用Google Assistant來測試各種語言組合是否有正確連結到url defined in actions.xml。



URL Template-based example: Taxi app

這個叫車的app的actions.xml如下:


這個action使用的semantic intent為一個built-in intent ORDER_RIDE,使用者可能會說出以下的句子:

這個intent會被分析成以下的parameters,他們的type是schema.org/xxx:


可以看到在actions.xml中,fulfillment定義的urlTemplate是一個接受兩個參數placeholders(注意type) 的urls,不過這邊不一定要是http的schema。

如果在App Actions Test Tool中看到如下:






Content-driven example: Coursera app

coursera的android app已經做了這個app actions的深度整合,來看他們怎麼做的。

如果使用者說出以下:


Coursera app註冊了一個built-in intent,由於Google Assistant知道該怎麼parse這段語音成有意義的參數,所以這些參數會丟向Coursera app actions:



可以看到此TAKE_COURSE intent有定義一個parameter叫做course,那他的type是schema.org/Course,所以在每個Coursera app的網頁中,如果加上以下的strucutured data markup:


Google Assistant就能知道這個action要提供的url content是什麼,也就是一個fullfillment。

所以coursera app的actions.xml就是以下這麼簡單的幾行xml:



在test tool中看到會是這樣:




在Google Assistant中的互動中,take course就變成一個predictable actions,當然coursera app就會出現在此predicted action list中:




Usage logging with Firebase indexing APIs

整合這個的目的就是要讓我們的App Actions在Android的app suggestion中更能被看到。
Firebase提供api來記錄in-app action usages可以達到這個目的。


透過Slices與Android/Google App整合

Android 19+ 提供了Slices - 一個UI template有點類似widget,讓app的一些內容或功能呈現出來,可以被其他app所展現(例如Search, Gmail等)。

不過這又是另一個topic了。



如何與非Android devices整合 - Conversational Actions

以上說的利用actions.xml來定義app actions,這是只對android devices有用。那如果想要延伸到非android devices但是五億台google assistant enabled devices上呢?

基本上Google努力建置technology stack出來,而應用程式開發商就專注在experiences上:


由於這些非android devices共同的介面就是語音,所以就要定義另一個action介面:conversational actions。

待下回分解。

2 則留言: