TWI412951B - 用於Ａｎｄｒｏｉｄ系統之帳號管理方法及帳號管理裝置 - Google Patents

Description

用於Android系統之帳號管理方法及帳號管理裝置

本發明係指一種用於Android系統之帳號管理方法及帳號管理裝置，尤指一種不需更動Android系統的核心運作，而可使Android系統針對不同用戶提供差異化服務的帳號管理方法及帳號管理裝置。

「Android」是Google於2007年11月發佈的手機軟體介面平台，早期由Google開發，後由開放手機聯盟(Open Handset Alliance)開發。它採用了軟件堆層(Software Stack)的架構，最低層以Linux核心工作為基礎，只提供基本功能，其它的應用程式則由各公司自行開發，以Java作為編寫程式的一部分。因此，製造商與開發者可以自由做出符合不同需求的手機，使得日後手機的應用得以如同個人電腦應用般的多元發展。

Android可視為一種專為智慧型手機設計的作業系統平台，但除了作業系統之外，還包含中介軟體(Middleware)負責硬體與應用程式之間的溝通、手機應用軟體及應用軟體開發套件，允許嵌入式系統的開發人員使用它來開發Android。而Android的各項優點，如開放原始碼、強大的網路應用及廣大的應用軟體市場等，使得Android也受到小筆電(Netbook)廠商的青睞。然而，不論將Android應用在智慧型手機上或是小筆電上，Android仍是一手機作業系統平台，與傳統的電腦作業系統仍有些差異。舉例來說，在手機上，是使用用戶識別模組(Subscriber Identity Module，SIM)卡來分辨使用者。若不同的使用者想要操作同一隻手機，就必需要更換SIM卡，並在核對密碼後才能開始使用。而傳統電腦的作業系統，只需在登入時，依照不同的使用者輸入的帳號及密碼即可開始使用。且傳統電腦的作業系統，可以依照不同使用者來管理使用者的檔案、設定等。手機則是將個人資訊存在SIM卡中，若存在手機之內，即便是不同的使用者，也能看到存放在手機中的資訊。此外，手機的作業系統也無法依據不同的使用者採用不同的設定，手機的作業系統一旦經設定後，後續的使用者都會套用相同的設定，而無法將不同使用者的設定動態地儲存下來。此一缺點，在小筆電上將造成相當大的不便。

因此，本發明主要在於提供用於Android系統之帳號管理方法及帳號管理裝置。

本發明揭露一種帳號管理方法，用於一Android系統中，該Android系統提供服務予複數個帳號，該帳號管理方法包含有針對該Android系統之複數個程序，產生複數個帳號資料夾，每一帳號資料夾儲存有該複數個帳號對於一對應程序之設定資料；以及於該複數個帳號之一特定帳號登入後，將該複數個帳號資料夾中對應於該特定帳號之複數個設定資料載入至該複數個程序中。

本發明另揭露一種帳號管理裝置，用於一Android系統中，該Android系統提供服務予複數個帳號，該帳號管理裝置包含有一微處理器；以及一記憶體，用來儲存一程式，該程式用來指示該微處理器執行以下步驟：針對該Android系統之複數個程序，產生複數個帳號資料夾，每一帳號資料夾儲存有該複數個帳號對於一對應程序之設定資料；以及於該複數個帳號之一特定帳號登入後，將該複數個帳號資料夾中對應於該特定帳號之複數個設定資料載入至該複數個程序中。

由於Android架構中各功能模組的名稱係本領域具通常知識者所熟知之特殊技術名詞，在不會產生混淆的情況下，為明確且充分揭露本發明之精神，使本領域具通常知識者能瞭解並據以實施，因此以下說明係沿用習知技術對Android之各功能模組的原始命名。需注意的是，Android平台係使用開放原始碼，各功能模組所代表之意義係本領域具通常知識者所熟知，亦可輕易取得，例如網站「http://www.android.com/」中已完整且詳細揭露Android架構，其典型示意圖係如第1圖所示。

為了使Android平台之電腦系統、可攜式裝置等可依據不同的使用者採用不同的設定，本發明係於Android架構的「APPLICATIONS」層、「APPLICATION FRAMEWORK」層及「LIBRARIES」層中，增加了三個模組：「User Account」、「Account Service」、「Account Manager」，如第2圖所示。「User Account」模組負責關於使用者帳戶管理的所有互動介面，包括了使用者登入介面、使用者管理介面等。「Account Service」為一背景服務程序，負責接收「User Account」模組所傳遞的指令及使用者資訊，並定期對「Account Manager」模組下達儲存使用者的資訊與設定的指令。此外，「Account Service」模組也負責監聽程序安裝、移除及系統關機之事件，以新增、移除或儲存使用者之資訊。「Account Manager」模組在接收「Account Service」模組之指令後，實際對Android系統中所有的程序檔案，依使用者的不同，針對此使用者之資訊及設定進行存取的動作。

關於「User Account」模組、「Account Service」模組及「Account Manager」模組的詳細運作方式，配合第3圖至第8圖說明如下。首先，當開機後，Android系統會逐步對各模組進行初始化。如第3圖所示，當「Account Service」模組的初始化完成後，「Account Service」模組會先判別此系統是否為初次建立；若是，則「Account Service」模組會下達指令給「Account Manager」模組，以建立一管理者帳戶並將帳號及密碼存入資料庫之中。當「Account Manager」模組收到建立帳戶的指令後，如第4圖所示，將在磁碟槽的「DATA」資料夾中，為每一個已安裝完成的程序產生一「Accounts」資料夾，用來存放與個別使用者相關於資料，並立即建立一「Admin」資料夾，用以存放管理者之資訊及設定。

接著，當Android系統完成「APPLICATION FRAMEWORK」層的初始化後，會進入到「APPLICATIONS」層，執行「Home」程序，而在此之前(即完成「APPLICATION FRAMEWORK」層的初始化後，但啟動「Home」程序前)，本發明會先執行「User Account」模組所對應的程序，啟動使用者登入畫面，以要求使用者輸入帳號及密碼，來判別登入之使用者。

當使用者進行登入之後，如第5圖所示，「User Account」模組會先透過「APPLICATION FRAMEWORK」層至資料庫(「SQLite」模組)，查詢使用者的帳號(Account)及密碼(Password)，再根據資料庫回傳的結果(RST)，判斷使用者所輸入之帳號資料是否正確。

在確認使用者所輸入之帳號資料無誤之後，如第6圖所示，「User Account」模組會透過「Account Service」模組下達指令(CMD)告知「Account Manager」模組，載入使用者之資訊與設定檔。

當「Account Manager」模組收到載入使用者資訊之指令後，如第7圖所示，「Account Manager」模組會根據使用者資訊，將磁碟槽之「DATA」資料夾下所有程序中相關的使用者資訊載入至系統。例如，若使用者所對應之帳號為「User1」，則「Account Manager」模組會將所有相關於「User1」帳號的設定檔載入至對應的程序中。

此外，如第8圖所示，在系統運作過程中，「Account service」模組會定時下達儲存指令，以定期儲存使用者的資訊及設定檔；同時，當「Account service」模組收到使用者關機事件時，亦會立即傳到儲存指令至「Account Manager」模組，以儲存所有的使用者資訊。

另一方面，當使用者新安裝一程序時，「Account service」模組將下達一指令至「Account Manager」模組，如同第4圖之例，替新安裝之程序產生「Accounts」資料夾，並建立使用者資料夾，以存放使用者對此程序的個人資訊及設定檔。

由上述可知，本發明之基本概念係針對所有已安裝之程序，分別建立對應的帳號資料夾，其內存有不同使用者的資訊與對所屬程序的設定檔。當確認使用者之身分(帳號)後，本發明就將儲存於每一程序之「Accounts」資料夾中該帳號的設定資料載入對應的程序中，以依照使用者所喜好之設定或權限，提供適當的服務。在此需注意的是，每一已安裝的程序都會有一對應的「Accounts」資料夾，其內存有各帳號針對該程序的設定檔。當然，若使用者未對某一程序進行設定，本發明亦可使用一預設設定檔，而此預設設定檔可於使用者帳號建立後自動產生，並於使用者更動設定檔時被置換。

簡單來說，為了管理不同帳號，本發明係在原有Android系統的「APPLICATIONS」層、「APPLICATION FRAMEWORK」層及「LIBRARIES」層中，增加「User Account」、「Account Service」、「Account Manager」等三個模組，換言之，本發明不需更動Android系統的核心運作。由於「APPLICATIONS」層、「APPLICATION FRAMEWORK」層及「LIBRARIES」層係製造商或開發者可自由修改的部分，因此任何採用Android系統之小筆電、智慧型手機等資訊設備皆可輕易改採本發明之架構，而不需負擔額外的成本。

此外，需注意的是，在前述說明及圖示中，與現有Android系統相同之模組或程序皆沿用原始命名，以使本領域具通常知識者能據以實施，該些模組或程序的詳細運作應係業界所熟知，故未多作解釋。而本發明所新增之模組、程序、資料夾、控制指令等元件的命名，如第2、3、5、6圖中的「User Account」、「Account Sernice」、「Account Manager」、第4圖中的「Accounts」、「Admin」、第5圖中的「RST」、「Account」、「Password」、第6圖中的「CMD」、第7圖中的「User1」、「User2」、「User3」、「Accounts」等，皆是為說明本發明之概念所定，其亦可以其他方式命名，不以此為限。

在習知技術中，由於Android係專為智慧型手機設計的作業系統平台，故其原始設計不支援多用戶的服務。在此情形下，當應用於小筆電或類似之資訊設備時，就會造成極大的不便。為改善此缺點，本發明不改變Android的核心運作，而是為每一程序提供不同使用者的設定檔或資料，當確認某一使用者之身分後，就將該使用者所對應之設定檔或資料載入各別程序中。換言之，透過本發明，Android系統亦可提供多用戶之差異服務。

上述針對Android系統之帳號管理機制可進一步歸納為一帳號管理流程90，如第9圖所示。帳號管理流程90包含以下步驟：

步驟900：開始。

步驟902：針對Android系統之複數個程序，產生複數個帳號資料夾，每一帳號資料夾儲存有複數個帳號對於一對應程序之設定資料(對應於第4、7、8圖中的「Accounts」資料夾)。

步驟904：於該複數個帳號之一特定帳號登入後，將該複數個帳號資料夾中對應於該特定帳號之複數個設定資料載入至該複數個程序中(對應於第7圖之「載入」)。

步驟906：於固定週期或該特定帳號登出或關機時，將該特定帳號對該複數個程序所產生之該複數個設定資料儲存至該複數個帳號資料夾(對應於第8圖之「儲存」)。

步驟908：結束。

帳號管理流程90之詳細運作與說明可參考前述。進一步地，在步驟902中，關於帳號資料夾(「Accounts」資料夾)的建立，可於Android系統之複數個程序初次安裝時完成；亦可於程序安裝後，透過更新的方式產生，以利於系統升級的實現。此外，在步驟904中，除了透過密碼方式，驗證帳號有效性以決定其是否可登入外，亦可利用如金鑰、聲紋、指紋等方式，且不限於此。再者，若某一帳號移除其中之一程序，則可將該帳號對該程序所產生之設定資料由對應的帳號資料夾中移除。

另一方面，在硬體實現方面，可以軟體、韌體等方式，將帳號管理流程90轉換為一程式，並儲存於Android系統之一記憶體中，以指示微處理執行帳號管理流程90之步驟。此等將帳號管理流程90轉換為適當程式以實現對應之帳號管理裝置，應為本領域具通常知識者所熟習之技藝。

綜上所述，本發明不需更動Android系統的核心運作，而是為每一程序提供不同使用者的設定檔或資料，即可使Android系統針對不同用戶提供差異化服務。同時，在實現本發明時，只需於Android系統的「APPLICATIONS」層、「APPLICATION FRAMEWORK」層及「LIBRARIES」層增加適當的模組，即可達成本發明之功效，因此任何採用Android系統之小筆電、智慧型手機等資訊設備皆可輕易透過系統更新，而改採本發明之架構，不需負擔額外的成本。

以上所述僅為本發明之較佳實施例，凡依本發明申請專利範圍所做之均等變化與修飾，皆應屬本發明之涵蓋範圍。

Accounts．．．資料夾

Admin、User1、User2、User3、Account．．．帳號

Password．．．密碼

RST．．．結果

90．．．帳號管理流程

900、902、904、906、908．．．步驟

第1圖為一典型Android架構之示意圖。

第2圖為本發明實施例一Android架構之示意圖。

第3圖為第2圖之Android架構進行模組初始化之示意圖。

第4圖為第2圖之Android架構建立「Accounts」資料夾之示意圖。

第5圖為第2圖之Android架構查詢使用者的帳號及密碼之示意圖。

第6圖為第2圖之Android架構下達指令之示意圖。

第7圖為第2圖之Android架構載入使用者之資訊與設定檔之示意圖。

第8圖為第2圖之Android架構儲存使用者之資訊與設定檔之示意圖。

第9圖為本發明實施例一帳號管理流程之示意圖。

90．．．帳號管理流程

900、902、904、906、908．．．步驟

Claims (16)

1. 一種帳號管理方法，用於一Android系統中，該Android系統提供服務予複數個帳號，該帳號管理方法包含有：分別於該Android系統之一APPLICATIONS層、一APPLICATION FRAMEWORK層及一LIBRARIES層中產生一第一模組、一第二模組及一第三模組，其中該第一模組用來處理使用者帳戶管理介面，該第二模組用來接收該第一模組所傳遞的指令及資料，並對該第三模組下達指令，以及該第三模組用來對Android系統中的程序檔案進行存取的動作；針對該Android系統之複數個程序，該第二模組控制該第三模組以產生複數個帳號資料夾，每一帳號資料夾儲存有該複數個帳號對於一對應程序之設定資料；以及於該複數個帳號之一特定帳號登入後，該第一模組透過該第二模組以控制該第三模組將該複數個帳號資料夾中對應於該特定帳號之複數個設定資料載入至該複數個程序中。
2. 如請求項1所述之帳號管理方法，其中該複數個程序係初次安裝於該Android系統。
3. 如請求項1所述之帳號管理方法，其中該複數個程序係先前已安裝於該Android系統。
4. 如請求項1所述之帳號管理方法，其中針對該Android系統之該複數個程序，該第二模組控制該第三模組以產生該複數個帳號資料夾之步驟，係於該複數個帳號建立時，針對該Android系統之該複數個程序，該第二模組控制該第三模組以產生該複數個帳號資料夾。
5. 如請求項1所述之帳號管理方法，其中於該複數個帳號之該特定帳號登入後，該第一模組透過該第二模組以控制該第三模組將該複數個帳號資料夾中對應於該特定帳號之該複數個設定資料載入至該複數個程序中之步驟，係於該第一模組判斷該特定帳號通過有效性驗證時，允許該特定帳號登入。
6. 如請求項1所述之帳號管理方法，其另包含該第二模組控制該第三模組以將該特定帳號對該複數個程序所產生之該複數個設定資料定期儲存至該複數個帳號資料夾中。
7. 如請求項1所述之帳號管理方法，其另包含於該特定帳號登出時，該第二模組控制該第三模組以將該特定帳號對該複數個程序所產生之該複數個設定資料儲存至該複數個帳號資料夾中。
8. 如請求項1所述之帳號管理方法，其另包含於該特定帳號移除該複數個程序之一程序時，該第二模組控制該第三模組以將該特定帳號對該程序所產生之設定資料由一對應帳號資料夾中移 除。
9. 一種帳號管理裝置，用於一Android系統中，該Android系統提供服務予複數個帳號，該帳號管理裝置包含有：一微處理器；以及一記憶體，用來儲存一程式，該程式用來指示該微處理器執行以下步驟：分別於該Android系統之一APPLICATIONS層、一APPLICATION FRAMEWORK層及一LIBRARIES層中產生一第一模組、一第二模組及一第三模組，其中該第一模組用來處理使用者帳戶管理介面，該第二模組用來接收該第一模組所傳遞的指令及資料，並對該第三模組下達指令，以及該第三模組用來對Android系統中的程序檔案進行存取的動作；針對該Android系統之複數個程序，命令該第二模組控制該第三模組以產生複數個帳號資料夾，每一帳號資料夾儲存有該複數個帳號對於一對應程序之設定資料；以及於該複數個帳號之一特定帳號登入後，命令該第一模組透過該第二模組以控制該第三模組將該複數個帳號資料夾中對應於該特定帳號之複數個設定資料載入至該複數個程序中。
10. 如請求項9所述之帳號管理裝置，其中該複數個程序係初次安裝 於該Android系統。
11. 如請求項9所述之帳號管理裝置，其中該複數個程序係先前已安裝於該Android系統。
12. 如請求項9所述之帳號管理裝置，其中該程式指示該微處理器針對該Android系統之該複數個程序，命令該第二模組控制該第三模組以產生該複數個帳號資料夾之步驟，係於該複數個帳號建立時，針對該Android系統之該複數個程序，命令該第二模組控制該第三模組以產生該複數個帳號資料夾。
13. 如請求項9所述之帳號管理裝置，其中該程式指示該微處理器於該複數個帳號之該特定帳號登入後，命令該第一模組透過該第二模組以控制該第三模組將該複數個帳號資料夾中對應於該特定帳號之該複數個設定資料載入至該複數個程序中之步驟，係於該第一模組判斷該特定帳號通過有效性驗證時，允許該特定帳號登入。
14. 如請求項9所述之帳號管理裝置，其中該程式另指示該微處理器命令該第二模組控制該第三模組以將該特定帳號對該複數個程序所產生之該複數個設定資料定期儲存至該複數個帳號資料夾中。
15. 如請求項9所述之帳號管理裝置，其該程式另指示該微處理器於該特定帳號登出時，命令該第二模組控制該第三模組以將該特定帳號對該複數個程序所產生之該複數個設定資料儲存至該複數個帳號資料夾中。
16. 如請求項9所述之帳號管理裝置，其該程式另指示該微處理器於該特定帳號移除該複數個程序之一程序時，命令該第二模組控制該第三模組以將該特定帳號對該程序所產生之設定資料由一對應帳號資料夾中移除。