編輯:關於android開發
到目前為止,我們學習和討論的都是利用Google的賬戶來訪問Google的在線服務,假如您有自己的在線服務,卻沒有Google類型的賬戶,這個時候該怎麼辦呢?本節課的目的就是來解決上面提到的問題,為自己的在線服務創建一個自定義的賬戶類型,並且像設備的內置賬戶一樣的方式工作。
要想創建一個新的自定義類型的賬戶,首先要做的工作是生成用戶憑據(credentials),該過程可以很簡單,比如要求用戶輸入賬戶名和密碼,也可以復雜一些,要求用戶設置一次性密碼或啟用生物特征掃描(如視網膜掃描,指紋識別)。不論是哪種方式,這是您必須要做的工作。
具體包括:
通常這三個步驟可以在一個 activity 中完成,我們可以將這個activity 稱之為認證 activity (authenticator activity)。
因為 authenticator activity 需要訪問系統的賬戶管理器 ,比普通的 activity 有更多的權限要求,Android framework 為了方便應用程序的開發,特意提供了一個基類 ,您可以通過繼承該類來實現自定義的賬戶驗證器。
前兩個步驟(收集憑據和服務驗證)如何實現完全取決於您應用程序的設計,最後一個步驟(存儲憑據)是一個標准的實現,代碼如下:
final Account account = new Account(mUsername, your_account_type); mAccountManager.addAccountExplicitly(account, mPassword, null);
需要特別注意的是: 本身並不對用戶憑據(credentials)做任何的加密處理,以純文本的方式進行存儲,在大部分的設備上,這都沒有問題,因為 credentials 保存在只有 root 權限才能讀取的數據庫中,但是對於已經 root 解鎖的設備來說,就有可能出現問題,此時任何人可通過 adb 工具來讀取系統中存儲的 credentials 信息。
考慮到這些因素,您就不應該簡單的把用戶的實際密碼通過 來保存,相反,應該存入一個更加安全的加密的安全令牌來抵御安全攻擊。如果您的用戶憑據用來保護非常有價值的數據,您在設計的時候應該慎重考慮。
Remember: When it comes to security code, follow the “Mythbusters” rule: don’t try this at home! Consult a security professional before implementing any custom account code.
OK,到此為止安全問題就暫告一段落了,驗證器的代碼框架我們也已經熟悉了,接下來的工作就是把整套流程銜接起來。
為了要讓系統的賬戶管理器 來管理您自定義的賬戶類型,那麼您必須要實現 用來管理帳號的一個接口,這個接口就是驗證器 authenticator class。
創建一個自定義驗證器的最簡單的方法莫過於繼承系統提供的驗證器虛類 ,然後實現裡面的抽象方法 (abstract methods)。如果您已經接觸過前面的課程,那麼這些抽象方法應該是很熟悉了,他們就是獲取賬戶信息和授權令牌後的回調方法。
實現一個自定義的驗證器需要下面幾部分的代碼,首先您需要實現 中存在的7個抽象方法,其次您需要在 manifest 文件中加入 for “android.accounts.AccountAuthenticator“(下一節課程會講解),最後,您還需要提供兩個 XML 資源文件,除了其他的事項,需要提供自定義賬戶的類型名稱和圖標,系統顯示賬戶的時候需要將這兩項信息顯示在賬戶的旁邊。
您可以參照該 指導文件一步一步實現一個自定義的驗證器,這邊還有 Demo 示例 ()可供參考。
閱讀Demo 示例 ()的過程中,您可能發現很多方法都在 bundle 中返回一個 intent,這個 intent 同時也用來啟動您的自定義驗證器 (custom authenticator activity)。如果您需要特殊的初始化參數,那麼可以通過調用方法 進行添加。
前面的代碼中您已經實現了自定義的驗證器類,現在需要一個服務來啟動驗證過程。因為該驗證器能夠被多個程序使用,並且後台運行,那麼最佳的選擇方案莫過於創建一個服務(),我們稱之為驗證器服務。
驗證器服務的實現可以很簡單,在服務的 方法中創建一個驗證器實例,在方法中調用 ,Demo 示例()中可以找到怎麼樣定義一個驗證器服務。
最後要做的工作就是在 manifest 文件中的 <service> tag 中添加 intent filter 和聲明驗證器。
示例代碼:
<service ...> <intent-filter> <action android:name="android.accounts.AccountAuthenticator" /> </intent-filter> <meta-data android:name="android.accounts.AccountAuthenticator" android:resource="@xml/authenticator" /> </service>
到此為止,工作算是順利完成了!現在系統的賬戶管理器可以正常識別您的自定義賬戶類型了,同系統已有的其他賬戶類型相似,比如 “Google” 和 “Corporate”。 您可以在系統的 Accounts &Sync 設定界面添加賬戶, 當用戶選擇賬戶類型的時候,您新添加的賬戶類型就可以正常選擇了。
當然,所有這些的前提是您的驗證器服務已經正確地安裝到設備上。假如只有一個APP會使用此服務,肯定不會出現什麼問題,APP和該服務綁定即可。但是如果有多個應用需要使用您的驗證器服務,情況會變得稍微復雜些,您可不願意每一個APP都綁定一個此服務的副本,這回占用很多的設備空間。
一種解決方法是將您的驗證器服務做成一個獨立的小的APK安裝程序,當一個APP想要使用您的自定義的賬戶類型時,先檢查一下設備的賬戶管理器,看是否支持,如果不支持的話,可以引導用戶從 Android Market 上面下載和安裝。這看起來似乎比較麻煩,但是比較起每次使用APP的時候都需要重復輸入賬戶憑證來說還是好多了。
參考文摘:
原文 : http://blog.zhourunsheng.com/2012/01/android-%e7%94%a8%e6%88%b7%e7%ae%a1%e7%90%86%e4%b8%93%e9%a2%98%e4%b9%8b%e5%88%9b%e5%bb%ba%e8%87%aa%e5%ae%9a%e4%b9%89%e5%b8%90%e6%88%b7%e7%b1%bb%e5%9e%8b/ | 潤物無聲
[Android]OkHttp的簡單封裝-輔助框架 序言 OkHttp 的強大算是毋庸置疑了;OkHttp 基本在網絡層能完成任何事情,適用任何情況;正因為如此 OkH
今天帶著個人疑問與實際項目開發中遇到的問題,跟大家一起學習下安卓活動與任務堆棧方面的知識,直入正題:相信大家都碰到過並沒有過多的操作內存但應用自動強
Activity啟動模式之SingleTop,activitysingletop 當活動的啟動模式指定為singleTop,在啟動活動時如果發現返回棧的棧頂已經是該活動
linux2.4.18----25.文件系統的構建一. 文件系統的構建1.busybox的編譯方法: 用虛擬機的redhat9.0進行編譯版本: busybox-1.00
集成websocket即時通訊 java聊天源碼 代碼下載 java後台