Các thành phần tạo nên một ứng dụng Android có thể được chia làm 4 loại chính:

- Hiểu một cách đơn giản thì Activity là nền của 1 ứng dụng. Khi khởi động 1 ứng dụng Android nào đó thì bao giờ cũng có 1 main Activity được gọi, hiển thị màn hình giao diện của ứng dụng cho phép người dùng tương tác.

- Ví dụ : Một ứng dụng email có thể có 1 activity hiển thị 1 danh sách các email mới, 1 activity khác để soạn email, và 1 activity để đọc email. Mặc dù các activity này làm việc cùng nhau trong 1 ứng dụng email, nhưng mỗi chúng lại độc lập với các cái khác. Như vậy, một ứng dụng khác có thể start bất kỳ một trong các activities này ( nếu ứng dụng email cho phép điều đó ). Chẳng hạn, một ứng dụng camera có thể start activity soạn mail mới trong ứng dụng email để cho phép người dùng có thể chia sẻ một bức ảnh.

- Một activity được implement như là một subclass của lớp Activity.

- Một service là một thành phần chạy ẩn ( runs in the background) để thực hiện các thao tác chạy lâu dài hoặc điều khiển các tiến trình. Service thì không có giao diện người dùng.

- Ví dụ : Một service phát nhạc ( không cần giao diện ) trong khi người dùng đang sử dụng một ứng dụng khác, hoặc nó trao đổi dữ liệu qua mạng mà không làm ngăn cản sự tương tác của người dùng với một activity. Một thành phần khác, chẳng hạn như một activity, có thể start service và tương tác với nó.

- Một service được implement như là một subclass của lớp Service

- Một content provider quản lý một tập hợp dữ liệu chia sẻ của ứng dụng. Bạn có thể lưu trữ dữ liệu trong file hệ thống, một cơ sở dữ liệu SQLite, trên web hay bất kỳ nơi lưu trữ nào khác mà ứng dụng của bạn có thể truy cập. Thông qua content providers, các ứng dụng khác có thể truy vấn hoặc thậm chí sửa đổi dữ liệu ( nếu content provider cho phép điều đó ).

- Ví dụ, hệ thống Android cung cấp một content provider quản lý các thông tin liên hệ của người dùng. Như vậy, bất kỳ ứng dụng nào được cấp quyền truy vấn đến một phần của content provider ( chẳng hạn như ContactsContract.Data) có thể đọc và ghi thông tin về một người cụ thể.

- Content providers cũng rất hữu ích trong việc đọc và ghi dữ liệu riêng tư cho ứng dụng của bạn và không chia sẻ nó.

- Một content provider được implement như là một subclass của ContentProvider và phải implement một tập hợp chuẩn các APIs cho phép ứng dụng khác có thể thực hiện giao dịch.

- Một broadcast receiver là một thành phần phản ứng với các thông báo từ bên ngoài gửi tới hệ thống. Nhiều broadcasts có nguồn gốc từ hệ thống – chẳng hạn, một broadcast thông báo các màn hình đã tắt, pin yếu, hoặc chụp hình. Các ứng dụng cũng có thể khởi tạo các broadcast – ví dụ, để cho các ứng dụng khác biết được rằng một số dữ liệu đã được tải về thiết bị và sẵn sàng để sử dụng. Mặc dù broadcast không hiển thị 1 giao diện người dùng, chúng có thể tạo một thông báo trên thanh trạng thái để cảnh báo người dùng khi có một sự kiện broadcast xảy ra. Thông thường hơn, một broadcast receiver là một “cửa ngõ” (gateway) cho các thành phần khác và được dự định để làm một số lượng tối thiểu các công việc. Ví dụ nó có thể khởi tạo một service để thực hiện một vài công việc dựa trên các sự kiện.

- Một broadcast receiver được implement như là một subclass của BroadcastReceiver và mỗi broadcast được dẫn xuất như là một đối tượng Intent

Ba trong 4 loại component : activities, services và broadcast receiver được kích hoạt bởi thông điệp bất đồng bộ gọi là Intent. Intent ràng buộc các thành phần với thành phần khác lúc runtime ( bạn có thể coi chúng như những sứ giả yêu cầu một hành động từ các thành phần khác ) cho dù thành phần thuộc về ứng dụng của bạn hay thuộc ứng dụng khác .

Một intent được tạo bởi một đối tượng Intent, cái mà định nghĩa một thông điệp để kích hoạt một thành phần cụ thể hoặc một loại thành phần cụ thể. Nó có thể được ép kiểu ngầm định hoặc tường minh.

Đối với activities và services, một intent định nghĩa hành động để thực hiện ( ví dụ, để “view” hay “send” cái gì đó) và phải chỉ định URI của dữ liệu để thao tác trên đó ( trong số nhiều thứ khác mà thành phần khi start cần phải biết). Ví dụ : một intent có thể truyền tải một yêu cầu cho một hành động để hiển thị một hình ảnh hoặc để mở một trang web. Trong một số trường hợp, bạn có thể start một activity để nhận kết quả, hoặc một cách khác là activity cũng có thể trả về kết quả trong một Intent ( ví dụ, bạn có thể đưa ra một Intent cho phép người dùng chọn một liên lạc cá nhân và trả lại cho bạn một Intent bao gồm một URI trỏ đến liên hệ được chọn )

Đối với broadcast receivers, Intent đơn giản là định nghĩa một thông báo đang được phát sóng ( ví dụ, một broadcast cho biết pin của thiết bị yếu chỉ bao gồm một chuỗi thông báo ” battery is low”).

Content provider không được kích hoạt bởi intent. Nó được kích hoạt khi mục tiêu được yêu cầu từ một ContentResolver. Hệ thống xử lý nội dung xử lý tất cả các giao dịch trực tiếp với content provider. Điều này tạo ra một lớp trừu tượng giữa content provider và thành phần yêu cầu thông tin ( vì mục đích an ninh ) .

Có nhiều cách khác nhau để kích hoạt mỗi loại component :

- Bạn có thể start một activity ( hoặc cung cấp cho nó một số thông tin để thực hiện ) bằng cách truyền vào một Intent thông qua phương thức startActivity() hoặc startActivityForResult() (khi bạn muốn activity trả về một kết quả).

- Bạn có thể start một service ( hoặc cung cấp các chỉ dẫn để một service xảy ra) bằng cách truyền vào một Intent thông qua phương thức startService(). Hoặc bạn có thể liên kết với service bằng cách truyền vào một Intent thông qua phương thức bindService().

- Bạn có thể khởi tạo một broadcast bằng cách truyền vào một Intent thông qua phương thức như sendBroadcast(), sendOrderedBroadcast(), hoặc sendStickyBroadcast().

- Bạn có thể thực hiện một truy vấn đến content provider bằng cách gọi phương thức query() trên một ContentResolver.

Trước khi hệ thống Android có thể start một thành phần ứng dụng, hệ thống phải biết về các thành phần đã tồn tại bằng cách đọc file Android Manifest.xml của ứng dụng (file “manifest”). Ứng dụng của bạn phải khao báo tất cả các thành phần của nó trong file này, nó phải được đặt ở thư mục root của project ứng dụng của bạn.

Manifest thực hiện thêm một số việc để khai báo các thành phần của ứng dụng, chẳng hạn như :

- Xác định các yêu cầu quyền truy cập ứng dụng của user, chẳng hạn như truy cập Internet hay truy cập đọc địa chỉ liên lạc.

- Khai báo yêu cầu API Level tối thiểu cho ứng dụng

- Khai báo các tính năng phần cứng và phần mềm được sử dụng hoặc yêu cầu bởi ứng dụng như camera, bluetooth hay màn hình đa điểm

- Các thư viện API mà ứng dụng cần liên kết đến ( ngoài Android Framework APIs), chẳng hạn như thư viện Google Maps.

Khai báo các thành phần : 

Nhiệm vụ chính của manifest là để thông báo cho hệ thống biết về thành phần của ứng dụng.

Ví dụ, một activity có thể được khai báo như sau :

<?xml version="1.0" encoding="utf-8"?>
<manifest ... >
    <application android:icon="@drawable/app_icon.png" ... >
        <activity android:name="com.example.project.ExampleActivity"
                  android:label="@string/example_label" ... >
        </activity>
        ...
    </application>
</manifest>

Trong element <application< , attribute android:icon trỏ đến resources yêu cầu một icon cho ứng dụng.

Trong element <activity>, attribute android:name xác định tên class đầy đủ của subclass Activity; attribute android:label xác định một chuỗi được dùng như nhãn để người dùng có thể nhìn thấy activity này.

Bạn có thể khai báo tất cả các thành phần của ứng dụng bằng cách :

- <activity> : cho activities

- <service> : cho services

- <receiver> : cho broadcast receivers

- <provider> : cho content providers

Activities, services và Content provider nằm trong mã nguồn của bạn nhưng nếu không được khai báo ở file manifest thì sẽ không hiển thị trong hệ thống và do đó, không bao giờ được chạy. Tuy nhiên, broadcast receivers có thể không cần khai báo trong manifest hoặc tạo động trong code ( dùng đối tượng BroadcastReceiver) và đăng ký với hệ thống bằng cách gọi registerReceiver())

Như ở phần trên đã nói, để kích hoạt các thành phần, bạn có thể sử dụng một Intent để start activities, services và broadcast receiveers. Bạn cũng có thể chỉ định rõ tên của thành phần đích ( sử dụng tên của class) trong Intent. Tuy nhiên, sức mạnh thật sự của các intent nằm trong khái niệm của intent actions. Với các intent actions, bạn chỉ đơn giản là môt tả loại của action muốn thực hiện ( và tùy chọn thêm dữ liệu mà bạn muốn thực hiện hành động) và cho phép hệ thống tìm kiếm một thành phần trên thiết bị để thực hiện hành động và start nó. Nếu có nhiều thành phần có thể thực hiện hành động được mô tả bởi intent thì người dùng lựa chọn một trong số chúng để sử dụng.

Cách để hệ thống xác định các thành phần có thể trả lời một intent là so sánh intent nhận được với các intent filters được cung cấp trong file manifest của các ứng dụng khác trên thiết bị.

Khi bạn khai báo một thành phần trong manifest của ứng dụng, bạn có thể tùy chọn thêm intent filter sẽ khai báo các khả năng của thành phần, bởi vậy nó có thể trả lời các intent từ các ứng dụng khác.  Bạn có thể khai báo một intent filter cho thành phần bằng cách thêm element <intent-filter> như là một tag con của thành phần được khai báo.

Ví dụ, một ứng dụng email với một activity dùng để soạn thảo một email mới có thể khai báo một intent filter trong manifest của nó để trả lời intent “send” ( dùng để gửi email). Một activity trong ứng dụng của bạn có thể tạo một intent với action “send” (ACTION_SEND), cái mà hệ thống so khớp với activity “send” của ứng dụng email và chạy nó khi bạn invoke intent với startActivity().

Có nhiều loại thiết bị khác nhau được hỗ trợ bởi Android và không phải tất cả trong chúng đều được cung cấp cùng tính năng và khả năng. Để tránh việc ứng dụng của bạn được cài đặt trên một thiết bị thiếu các tính năng cần thiết cho ứng dụng của bạn thì một điều quan trọng là bạn cần định nghĩa rõ ràng các thông tin về loại của thiết bị mà ứng dụng của bạn hỗ trợ bằng cách khai báo phần cứng và phần mềm yêu cầu trong file manifest. Hầu hết những khai báo này chỉ là các thông tin và hệ thống không đọc chúng, nhưng các services bên ngoài như Google Play sẽ đọc chúng để cung cấp bộ lọc cho người dùng khi họ tìm kiếm các ứng dụng từ thiết bị của họ.

Ví dụ, nếu ứng dụng của bạn yêu cầu một camera và sử dụng APIs được gới thiệu trong Android 2.1 (API Level 7), bạn cần khai báo các thông tin này trong file manifest. Theo đó, các thiết bị không có camera và phiên bản Android nhỏ hơn 2.1 không thể cài ứng dụng của bạn trên Google Play.

Tuy nhiên, bạn cũng có thể khai báo ứng dụng của bạn sử dụng camera, nhưng không yêu cầu bắt buộc có nó. Trong trường hợp này, ứng dụng của bạn phải thực hiện một kiểm tra tại thời điểm runtime để xác định xem thiết bị có camera hay không và sẽ vô hiệu tất cả các tính năng sử dụng camera nếu thiết bị không có.

Dưới đây là một số đặc điểm thiết bị quan trọng mà bạn cần xem xét khi thiết kế và lập trình cho ứng dụng của bạn :

Để phân nhóm thiết bị theo loại màn hình, Android định nghĩa 2 đặc điểm cho mỗi thiết bị : Screen size ( kích thước vật lý của màn hình) và Screen density (mật độ vật lý các điểm ảnh trên màn hình, hoặc là dpi – dots per inch). Để đơn giản hóa tất cả các loại khác nhau của các cấu hình màn hình, hệ thống Android tổng quát chúng thành các nhóm chọn để làm cho chúng dễ dàng được tìm kiếm.

Các kích thước màn hình gồm : nhỏ, bình thường, lớn và cực lớn

Các độ phân giải màn hình gồm : độ phân giải thấp, độ phân giải trung bình, độ phân giải cao và độ phân giải cực cao.

Mặc định ứng dụng của bạn sẽ tương thích với tất cả các kích thước và độ phân giải màn hình bởi vì hệ thống Android thực hiện các điều chỉnh thích hợp đối với bố cục và các hình ảnh. Tuy nhiên, bạn nên tạo các layout chuyên biệt cho một số kích cỡ màn hình và cung cấp hình ảnh chuyên biệt cho độ phân giải nhất định, sử dụng các tài nguyên bố trí thay thế và bằng cách khai báo trong file manifest chính xác kích thước màn hình mà ứng dụng của bạn hỗ trợ với element <supports-screen>

Nhiều thiết bị cung cấp các loại cơ chế đầu vào khác nhau, chẳng hạn như bàn phím trackball, hoặc pad điều hướng five-way. Nếu ứng dụng của bạn yêu cầu một loại phần cứng đầu vào nhất định thì bạn cần khai báo nó trong file manifest thông qua tag <use-configuration>. Tuy nhiên, rất hiếm khi một ứng dụng đòi hỏi một cấu hình đầu vào nhất định.

Có nhiều tính năng phần cứng và phần mềm có hoặc không có sẵn trên một thiết bị hỗ trợ Android, chẳng hạn như camera, bộ cảm biến ánh sách, bluetooth, một phiên bản OpenGL cụ thể, độ trung thực của màn hình cảm ứng. Bạn không nên nghĩ rằng một tính năng cụ thể nào đó là có sẵn trên tất cả các thiết bị chạy Android( ngoại trừ thư viện chuẩn Android), do đó bạn nên khai báo các tính năng được sử dụng bởi ứng dụng của bạn với element <uses-feature>

Sự khác nhau giửa các thiết bị chạy Android thường chạy các phiên bản khác nhau của Android platform, chẳng hạn như Android 1.6 hay Android 2.3. Mỗi phiên bản sau thường bao gồm thêm các APIs không có sẵn trong phiên bản trước. Để chỉ định tập hợp các APIs có sẵn, mỗi phiên bản platform được đặt một API Level ( ví dụ, Android 1.0 là API Level 1 và Android 2.3 là API Level 9). Nếu bạn sử dụng một APIs được thêm vào platform sau phiên bản 1.0, bạn cần khai báo API Level tối thiểu trong số các APIs được giới thiệu bằng cách sử dụng element <uses-sdk>

Việt khai báo tất cả các thành phần yêu cầu cho ứng dụng của bạn là một điều rất quan trọng bởi vì khi bạn phân phối ứng dụng của bạn trên Google Play, store sẽ sử dụng những khai báo này để lọc ra những ứng dụng phù hợp với một mỗi thiết bị. Bởi vậy, ứng dụng của bạn sẽ thích hợp với các thiết bị có đủ phần ứng yêu cầu cho ứng dụng.