元件是一個Android程式至關重要的構建模組。每一個元件都是系統進入你的應用的不同途徑。但並不是所有的元件都是使用者進入程式的真實入口，其中一些要依賴於其它元件, 但是每一個元件都以自己獨有的形式存在，併發揮特殊的作用；每一個元件都是一個唯一的模組，幫助你實現程式的各種行為。

有四種不同的應用程式元件。每一種元件都有其唯一的目的並且有獨有的生命週期，這個生命週期定義了附件被建立和銷燬的方式。

Activity
一個 activity 為一個使用者互動提供一個單獨的介面。例如，一個郵件程式可能有一個activity,它展現了一個新郵件的列表。 另一個activity用來編輯郵件，還有一個是用來閱讀郵件。 雖然這些activity組合在一起構成一個緊密的使用者體驗，但每一個都是相對獨立的。 同樣，其它程式也可以啟動這些activity(如果這個郵件程式允許)。 例如，一個相機程式可以啟動這個郵件程式的編輯郵件activity,如果使用者想分享一張照片。

Service
一個 service是一個執行在後臺的元件。它用於執行耗時操作或者遠端程序。 一個service並不提供使用者互動介面。例如，當用戶在使用另外一個程式的時候，一個服務可能在播放音樂或者在 通過網路獲取資料，這樣不會阻塞住使用者與activity的互動。其它的元件，例如一個activity,可以啟動一個service並讓其執行或者與其繫結，繫結後可以與其互動。

Content provider
一個content provider負責管理應用程式的資料共享集。 你可以通過檔案系、SQLite資料庫、網站，或者其它的你的應用程式可以訪問的持久化儲存位置來儲存資料。 通過content provider,其它的應用程式可以查詢甚至修改你的資料（如果這個content provider允許它們這麼做）。 例如，Android系統提供了一個content provider來管理聯絡人資訊。 同樣地，任何程式擁有了適當許可權都可以查詢這個content provider (例如 ContactsContract.Data) 去讀寫某人的資訊。
Content provider在讀寫程式的私有資料時也很有用。例如，Note Pad 範例程式就使用了一個content provider來儲存筆記。
一個content provider是作為ContentProvider的一個子類被實現的。 並且必須實現一些標準的API集，這樣其它的應用程式才能執行事務。

Broadcast receiver
broadcast receiver 是一個用來響應系統範圍內的廣播的元件。 很多廣播發自於系統本身。—例如, 通知螢幕已經被關閉、電池低電量、照片被拍下的廣播。 應用程式也可以發起廣播。—例如, 通知其它程式，一些資料被下載到了裝置，且可供它們使用。 雖然廣播並不提供使用者互動介面，它們也可以建立一個狀態列通知 來提醒使用者一個廣播事件發生了。儘管如此，更多的情形是，一個廣播只是進入其它元件的一個“門路”，並試圖做一些少量的工作。 例如，它可能發起一個服務，並通過服務執行與這個廣播事件相關的工作。
broadcast receiver是BroadcastReceiver 的子類實現，而且每一個廣播通過Intent 物件來傳遞。

Android系統設計的一個獨特方面是，任何程式都可以啟動其它程式的元件。 例如，如果你想讓使用者使用裝置相機捕捉一個相片，有另外一個程式做這件事，那麼你的程式將可以呼叫它， 而不是你自己開發一個拍照的activity。你不必從相機程式中嵌入程式碼或者連連結程式碼也不需要。取而代之地，你可以簡單地啟動相機程式中拍照的activity。 當拍照完成，相片就會返回給你的程式供你使用。從使用者的角度，就好像相機就是你程式的一部分。

當系統啟動一個元件，它其實就啟動了這個程式的程序（如果這個程序還未被啟動的話）並例項化這個元件所需要的類。 例如，如果你的程式啟動了相機程式裡的activity去拍照，這個activity實際上是執行在相機程式的程序裡，而不是你自己的程序。 因此，不像其它系統裡的程式，Android程式並不是單入口的（例如它沒有main方法）。

由於系統把程式執行在一個個獨立的程序中，並使用檔案許可權來限制對其它程式的訪問，所以你的程式不能從其它程式中直接啟用元件。 儘管如此，Android系統可以做到！啟用一個其它程式的元件，你必須向系統傳送一個資訊，這個資訊需要指定你的intent 來啟動一個指定的元件。 然後系統就會為你啟用這個元件。