序言：
Android是設計來在很多不同種類的裝置上跑的，對於開發者而言，
如此多的裝置意味著潛在的閱聽者：越多人能跑Android的apps，
也就表示越多人可以用你的app。
與之交換的，這也表示你的app要能適合不同的硬體條件狀況。
幸運的(真的嗎XD)，Android有內建的工具和支援可以讓你的app輕鬆地做到相容，
並同時對於你的app所適用的裝置的種類進行對應的管理維護。
在提前考慮，並且對於你的app的manifest檔作一些修改後，
你可確保使用者的裝置種類，只要是不能跑你的app的版本，
他就不會在Google Play上面看到，也不會白白浪費時間下載。
這篇文章會解釋我們如何去管理app，
以讓它能正確地為相應的使用者所能使用。
What does "compatibility" mean?：
我們稱一個裝置是"Android compatible"，
如果它可以正確地在Android執行環境(execution environment)上跑app。
此細節被定義在Android Compatibility Definition文件中，
但當中最重要的特性及指標來說，
就是相容的裝置要有能力去安裝及正確地跑Android的.apk檔。
對每個Android API來說均剛剛好有一個一個API level，
而且對於同樣的API，裝在不同的裝置上都一樣。
並不會存在選擇性的部分API，所以當API Level定了以後，
透過最高的API level，我們就可以確定你的app，
在高於或等於某API level以上的裝置上，可以拿到所有該API level所會有的API。
當然有些API如果沒有特定的硬體條件或者功能的話，仍會無法正確運作。
但這並不是問題：
我們(Google)也將Android設計成讓缺乏特定硬體或功能的裝置，
在商店上會無法看到需求其功能的app。這些功能已經內建支援在SDK工具，
而且它是Android平台的一部分(也是Google Play的一部分)。
做為開發者，你必須要完成對於app在什麼狀況下可以安裝使用的管控。
Android有提供平台來讓你管理，管控app的可用性(availability)，
讓他們只會被能跑的裝置來看到。
How does it work?：
我們透過三個步驟程序來管理app的可用性:
1. 藉由陳述manifest檔裡的
<uses-feature>的元素來描述app所需要的功能(features)。2. 裝置本身需要向Google Play聲明他們所擁有的功能。
3. Google Play會用你app所陳述的需求條件來篩選。
這樣沒辦法用的app反正就沒辦法用了嘛XD，
只要正確設定app的執行需求，我們就不必擔心被使用者莫名其妙的指責相容性問題囉。
(當然也要你的app的確沒有其他bug......XDDD)
以網頁開發(web development)的角度來看的話，你可以把這個模式看作是"相容性偵測"(compatibility detection)。
網頁開發者通常會比較喜歡用"瀏覽器偵測"(browser detection)的解法，
因為要達到一旦新瀏覽器版本出來就馬上跟進實在太困難了。
藉由功能支援性的檢查來取代原來的方法，網頁開發者能得到更好的控管。
這也是Android的作法：既然不可能跟上所有被發行的Android devices，
我們用細分的管控來取代之。
Filtering for technical reasons：
Google Play會做相容性篩選。請見 Filters on Google Play。
Android包含了很多對軟硬體的支援。但並不是所有裝置都會支援所有功能，
比如有些可能不會有那種馬力去很好地顯示動態桌布(XD)。
管理上Android定義了所謂的feature IDs，每一個相容性都對應到一個feature ID，
舉例來說，對於羅盤的feature ID是
“android.hardware.sensor.compass”，而動態桌布的是
“android.software.live_wallpapers”。這些ID也有相應的Java-language常數定義在
PackageManager class裡，可以去查詢(query)看是否功能在執行期有支援。當Andorid新版本中加上新的功能，
新的feature IDs也會被加上去。
當在AndroidManifest.xml檔裡把app所需用的feature IDs加到<uses-feature>元素裡時，
不符合的裝置在Google Play就會看不到。
但注意只對於那些必要的來做這件事情。
比如說你的app就是要拍照來做實境AR的，如果不能拍照就相當於廢掉，
相較於一個可能跟附近商家優惠有關，但附帶了條碼掃描功能的app，
前者就必須要加上相機的feature ID，而後者因為缺了那個功能還是可用，
只是功能少了一點，所以沒有必要完全打死。
對於裝置的要求越高，閱聽使用者就會越少，但你的開發會越節省，
反之亦然，所以你必須自行去評估這中間的取捨。
Filtering for business reason：
為了商業或法律原因，你可能需要限制app的可用性(availability)。
舉例來說，台北捷運的地圖大概對於在台北以外的使用者沒太大用處。
其他app可能在特定國家不被允許(也是商業或法律上的原因)
因此Google Play本身也提供了在因非技術層面上的原因所需限制可用性的處理。
開發者可以用Google Play的發行者UI來:
1. 列出app在那些國家是可用的。
2. 選擇那些載體(carrier)的使用者是可以去存取app的。
技術層面的篩選是透過包在.apk檔裡的資訊，
而非技術層面的則是在Google Play的使用者介面。
Future-proofing：
還有一個忘了說的:保護app遠離因為未來的Android版本變更所帶來的侵害(XD)。
如果Android引進了新功能或者改變舊功能的操作方式，
那麼已有的app會有什麼樣的變化呢？
簡單來說，Android承諾不會去改變已存在app對於設備的可用性，就算平台改變。
比方說：
1. Android 1.0~1.5的時期相機沒有自動對焦，之後更新版本以後，
舊的app可能沒有處理這部分，所以新版會對其預設取得對應的權限，
並且仍會當作預設自動對焦來使用。
2. Android 2.2支援麥克風並可讓麥克風有語音篩選的功能，
但有些舊的app或舊的設備可能沒有做功能或者沒有麥克風，
這都是可以關掉的。如果你的app不是非麥克風不可，
那麼也可以不用去require使用者的裝置一定要有麥克風。
總之Google會處理相對應的功能讓不論是加新更能或者更改已有功能時，
都可以讓之前本來能跑的app現在仍然可以跑。
這部分有一部分是實作在SDK裡的aapt工具。
我們可以使用aapt dump badging來看自己app所需的功能要求有哪些。
Conclusion：
Android的目標是要製造一個龐大的安裝的基地讓使用者能獲得優勢。
其中一個將要做的作法是讓不同種類的硬體能在同樣的軟體環境下跑。
透過內建工具和設定規則(policies)及安裝需求(requirements)來確保app的管控。
現在經由剛剛所讀到的文件，你應該可以有信心去發布你的app，
且只讓可以跑的使用者能看到了！
沒有留言:
張貼留言