將現有的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之後）
還有就是一些ＯＳ深度整合（例如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。
待下回分解。
