Nghiên Cứu Phương Pháp Kiểm Thử Tự Động Đầu Vào Cho Ứng Dụng Android

Luận văn thạc sĩ nghiên cứu nghiên cứu một số phương pháp sinh đầu vào kiểm thử tự động cho android luận văn ths máy tính 604801, đánh giá hiện trạng, phân tích vấn đề, đề xuất

• Tác giả: Trần Thị Hồng Sim
• Người hướng dẫn: PGS. Trương Anh Hoàng
• Trường học: Đại học Quốc gia Hà Nội
• Chuyên ngành: Công Nghệ Thông Tin
• Đề tài: Phương Pháp Kiểm Thử Tự Động Đầu Vào Cho Ứng Dụng Android
• Loại tài liệu: luận văn thạc sĩ
• Năm xuất bản: 2017
• Địa điểm: Hà Nội

Mục lục chi tiết

• LỜI CAM ĐOAN
• LỜI CẢM ƠN
• 1. CHƯƠNG 1: NỀN TẢNG ANDROID
• 1.1. Giới thiệu chung về Android
• 1.2. Bản kê khai ứng dụng AndroidManifest
• 1.3. Hoạt động (Activity)
• 1.4. Vòng đời của một hoạt động
• 1.5. Dịch vụ (Service)
• 1.6. Vòng đời của một dịch vụ
• 1.7. Bộ nhận quảng bá (Broadcast Receiver)
• 2. CHƯƠNG 2: PHƯƠNG PHÁP SINH ĐẦU VÀO KIỂM THỬ TỰ ĐỘNG
• 2.1. Phương pháp kiểm thử Fuzz (Fuzzing)
• 2.1.1. Kiểm thử Fuzz là gì?
• 2.1.2. Các giai đoạn của kiểm thử Fuzz
• 2.1.3. Phân loại kiểm thử Fuzz
• 2.1.4. Các lỗi hổng được phát hiện bởi kiểm thử Fuzz
• 2.1.5. Ưu nhược điểm của kiểm thử Fuzz
• 2.1.6. Một số công cụ kiểm thử Fuzz
• 2.2. Phương pháp dựa trên mô hình (Model based Testing)
• 2.2.1. Kiểm thử dựa trên mô hình là gì?
• 2.2.2. Các loại kiểm thử dựa trên mô hình
• 2.2.3. Các mô hình khác nhau trong kiểm thử
• 2.2.4. Tiến trình kiểm thử dựa trên mô hình
• 2.2.5. Ưu nhược điểm của kiểm thử dựa trên mô hình
• 2.2.6. Một số công cụ kiểm thử dựa trên mô hình
• 3. CHƯƠNG 3: MỘT SỐ CÔNG CỤ SINH ĐẦU VÀO KIỂM THỬ TỰ ĐỘNG CHO ỨNG DỤNG ANDROID
• 3.1. Công cụ kiểm thử ngẫu nhiên – Monkey tool
• 3.1.1. Tổng quan chung về Monkey tool
• 3.1.2. Kiểm thử Fuzz với Monkey
• 3.2. Công cụ kiểm thử dựa trên mô hình – DroidBot
• 3.2.1. Tổng quan chung về DroidBot
• 3.2.2. Kiểm thử dựa trên mô hình với DroidBot
• 4. CHƯƠNG 4: NGHIÊN CỨU THỰC NGHIỆM
• 4.1. Thiết lập môi trường thực nghiệm
• 4.2. Chuẩn bị công cụ kiểm thử
• 4.3. Chuẩn bị thiết bị kiểm thử
• 4.4. Xây dựng ứng dụng kiểm thử
• 4.5. Tiến hành kiểm thử
• 4.6. Kết quả thực nghiệm
• 4.7. Phân tích – đánh giá
• 4.8. Tính hiệu quả trong việc phát hiện lỗi
• 4.9. Tính hiệu quả trong chiến lược khám phá
• 4.10. Tính khả dụng
• TÀI LIỆU THAM KHẢO

Tóm tắt

I. Giới thiệu về kiểm thử tự động đầu vào cho ứng dụng Android

Kiểm thử tự động đầu vào cho ứng dụng Android là một phần quan trọng trong quy trình phát triển phần mềm. Kiểm thử tự động giúp giảm thiểu thời gian và chi phí so với kiểm thử thủ công. Việc áp dụng các phương pháp kiểm thử tự động như kiểm thử Fuzz và kiểm thử dựa trên mô hình đã chứng minh hiệu quả trong việc phát hiện lỗi. Kiểm thử ứng dụng Android không chỉ giúp đảm bảo chất lượng sản phẩm mà còn nâng cao trải nghiệm người dùng. Theo nghiên cứu, việc sử dụng công cụ kiểm thử tự động có thể phát hiện lỗi nhanh chóng và chính xác hơn, từ đó cải thiện hiệu suất của ứng dụng. Các phương pháp này không chỉ đơn thuần là kiểm tra chức năng mà còn bao gồm kiểm tra hiệu suất và bảo mật của ứng dụng.

1.1. Tầm quan trọng của kiểm thử tự động

Kiểm thử tự động đóng vai trò quan trọng trong việc phát triển ứng dụng Android. Với sự gia tăng số lượng ứng dụng trên cửa hàng Google Play, việc đảm bảo chất lượng ứng dụng trở nên cấp thiết. Kiểm thử tự động giúp phát hiện lỗi sớm trong quá trình phát triển, từ đó giảm thiểu rủi ro và chi phí sửa chữa sau này. Hơn nữa, việc tự động hóa kiểm thử giúp tiết kiệm thời gian cho các nhà phát triển, cho phép họ tập trung vào việc phát triển tính năng mới. Theo một nghiên cứu, các ứng dụng được kiểm thử tự động có tỷ lệ lỗi thấp hơn 30% so với các ứng dụng không được kiểm thử. Điều này cho thấy kiểm thử tự động không chỉ là một lựa chọn mà là một yêu cầu cần thiết trong phát triển ứng dụng hiện đại.

II. Các phương pháp kiểm thử tự động đầu vào

Trong lĩnh vực kiểm thử tự động cho ứng dụng Android, có nhiều phương pháp khác nhau được áp dụng. Hai phương pháp chính là kiểm thử Fuzz và kiểm thử dựa trên mô hình. Kiểm thử Fuzz là một kỹ thuật kiểm thử ngẫu nhiên, nơi dữ liệu đầu vào được sinh ra một cách ngẫu nhiên để kiểm tra tính ổn định của ứng dụng. Phương pháp này giúp phát hiện các lỗi bảo mật và lỗi không mong muốn trong ứng dụng. Ngược lại, kiểm thử dựa trên mô hình sử dụng các mô hình để xác định các kịch bản kiểm thử. Phương pháp này cho phép kiểm tra toàn diện hơn và có thể phát hiện các lỗi mà kiểm thử Fuzz có thể bỏ qua. Việc kết hợp cả hai phương pháp này sẽ mang lại hiệu quả cao hơn trong việc phát hiện lỗi và cải thiện chất lượng ứng dụng.

2.1. Kiểm thử Fuzz

Kiểm thử Fuzz là một trong những phương pháp kiểm thử tự động phổ biến nhất. Phương pháp này hoạt động bằng cách gửi các dữ liệu đầu vào ngẫu nhiên đến ứng dụng để kiểm tra khả năng xử lý của nó. Kiểm thử Fuzz có thể phát hiện các lỗi nghiêm trọng như tràn bộ nhớ, lỗi bảo mật và các vấn đề khác mà có thể không được phát hiện qua các phương pháp kiểm thử truyền thống. Theo một nghiên cứu, kiểm thử Fuzz đã phát hiện ra 70% lỗi bảo mật trong các ứng dụng Android. Điều này cho thấy tầm quan trọng của phương pháp này trong việc đảm bảo an toàn cho ứng dụng. Hơn nữa, việc sử dụng các công cụ kiểm thử Fuzz như Monkey tool giúp tự động hóa quá trình này, tiết kiệm thời gian và công sức cho các nhà phát triển.

III. Công cụ kiểm thử tự động cho ứng dụng Android

Có nhiều công cụ hỗ trợ kiểm thử tự động cho ứng dụng Android, trong đó nổi bật là Monkey tool và DroidBot. Monkey tool là một công cụ kiểm thử ngẫu nhiên, giúp phát hiện lỗi bằng cách gửi các sự kiện ngẫu nhiên đến ứng dụng. Công cụ này rất hữu ích trong việc kiểm tra tính ổn định của ứng dụng dưới các điều kiện khác nhau. Ngược lại, DroidBot là một công cụ kiểm thử dựa trên mô hình, cho phép người dùng tạo ra các kịch bản kiểm thử dựa trên cấu trúc của ứng dụng. Việc sử dụng các công cụ này không chỉ giúp phát hiện lỗi mà còn cải thiện hiệu suất và bảo mật của ứng dụng. Theo thống kê, các ứng dụng được kiểm thử bằng DroidBot có tỷ lệ lỗi thấp hơn 25% so với các ứng dụng không được kiểm thử.

3.1. Monkey tool

Monkey tool là một công cụ kiểm thử tự động nổi tiếng trong cộng đồng phát triển ứng dụng Android. Công cụ này hoạt động bằng cách gửi các sự kiện ngẫu nhiên đến ứng dụng, từ đó kiểm tra khả năng xử lý của ứng dụng dưới áp lực. Monkey tool có thể phát hiện các lỗi nghiêm trọng như tràn bộ nhớ và các vấn đề về hiệu suất. Việc sử dụng công cụ này giúp tiết kiệm thời gian cho các nhà phát triển, cho phép họ tập trung vào việc phát triển tính năng mới. Theo một nghiên cứu, các ứng dụng được kiểm thử bằng Monkey tool có tỷ lệ lỗi thấp hơn 30% so với các ứng dụng không được kiểm thử. Điều này cho thấy tầm quan trọng của công cụ này trong việc đảm bảo chất lượng ứng dụng.

IV. Nghiên cứu thực nghiệm

Nghiên cứu thực nghiệm là một phần quan trọng trong việc đánh giá hiệu quả của các phương pháp kiểm thử tự động. Trong nghiên cứu này, hai công cụ Monkey tool và DroidBot đã được sử dụng để kiểm tra một danh sách các ứng dụng Android. Kết quả cho thấy rằng cả hai công cụ đều có khả năng phát hiện lỗi hiệu quả, với Monkey tool phát hiện được 60% lỗi và DroidBot phát hiện được 50% lỗi. Ngoài ra, nghiên cứu cũng chỉ ra rằng việc kết hợp cả hai công cụ này sẽ mang lại hiệu quả cao hơn trong việc phát hiện lỗi. Việc phân tích kết quả thực nghiệm giúp đưa ra những đánh giá chính xác về hiệu quả của các phương pháp kiểm thử tự động, từ đó cải thiện quy trình phát triển ứng dụng.

4.1. Kết quả thực nghiệm

Kết quả thực nghiệm cho thấy rằng việc sử dụng các công cụ kiểm thử tự động như Monkey tool và DroidBot có thể phát hiện lỗi hiệu quả trong các ứng dụng Android. Cụ thể, Monkey tool đã phát hiện được 60% lỗi trong khi DroidBot phát hiện được 50% lỗi. Điều này cho thấy rằng cả hai công cụ đều có giá trị trong việc đảm bảo chất lượng ứng dụng. Hơn nữa, việc kết hợp cả hai công cụ này sẽ mang lại hiệu quả cao hơn trong việc phát hiện lỗi. Kết quả thực nghiệm không chỉ giúp đánh giá hiệu quả của các phương pháp kiểm thử mà còn cung cấp thông tin quý giá cho các nhà phát triển trong việc cải thiện quy trình phát triển ứng dụng.

Nội dung chính

Tổng quan nghiên cứu

Trong bối cảnh phát triển nhanh chóng của công nghệ di động, hệ điều hành Android chiếm lĩnh khoảng 86% thị phần toàn cầu, trở thành nền tảng phổ biến nhất cho các thiết bị thông minh như điện thoại, máy tính bảng, đồng hồ thông minh và các thiết bị IoT. Cửa hàng ứng dụng Google Play hiện có hơn 3.3 triệu ứng dụng với gần 17 tỷ lượt tải xuống chỉ trong quý 2 năm 2017, cho thấy nhu cầu phát triển và kiểm thử ứng dụng Android ngày càng tăng cao. Kiểm thử phần mềm, đặc biệt là kiểm thử tự động, đóng vai trò thiết yếu trong việc đảm bảo chất lượng và bảo mật của các ứng dụng này.

Luận văn tập trung nghiên cứu một số phương pháp sinh đầu vào kiểm thử tự động cho ứng dụng Android, nhằm giải quyết các hạn chế của kiểm thử thủ công như tốn thời gian, chi phí cao và hiệu quả thấp. Mục tiêu cụ thể là phân tích, đánh giá và thực nghiệm hai phương pháp kiểm thử tự động nổi bật: kiểm thử Fuzz (Fuzzing) và kiểm thử dựa trên mô hình (Model-based Testing), đồng thời khảo sát hai công cụ đại diện là Monkey và DroidBot. Nghiên cứu được thực hiện trong phạm vi các ứng dụng Android phổ biến, với dữ liệu thu thập và phân tích trong môi trường thực nghiệm tại Việt Nam năm 2017.

Ý nghĩa của nghiên cứu thể hiện qua việc nâng cao hiệu quả kiểm thử tự động, giảm thiểu lỗi phần mềm, tăng độ bao phủ mã nguồn và cải thiện chất lượng sản phẩm phần mềm Android, góp phần thúc đẩy phát triển công nghệ phần mềm trong nước và quốc tế.

Cơ sở lý thuyết và phương pháp nghiên cứu

Khung lý thuyết áp dụng

Luận văn dựa trên hai lý thuyết và mô hình chính trong kiểm thử phần mềm:

1. Kiểm thử Fuzz (Fuzzing): Là kỹ thuật kiểm thử hộp đen, sử dụng dữ liệu đầu vào ngẫu nhiên hoặc có biến đổi để phát hiện lỗi bảo mật và lỗi phần mềm nghiêm trọng như tràn bộ đệm, XSS, SQL Injection. Fuzzing không yêu cầu truy cập mã nguồn, giúp phát hiện lỗi nhanh chóng và hiệu quả. Các giai đoạn chính gồm xác định hệ thống mục tiêu, xác định đầu vào, sinh dữ liệu fuzz, thực thi, giám sát và đăng lỗi. Phân loại Fuzzing gồm mutation-based (dựa trên đột biến) và generation-based (dựa trên mô hình).

2. Kiểm thử dựa trên mô hình (Model-based Testing - MBT): Sử dụng mô hình hành vi của hệ thống để sinh các ca kiểm thử tự động. Mô hình có thể là máy trạng thái hữu hạn, biểu đồ trạng thái, hoặc ngôn ngữ mô hình hóa thống nhất (UML). MBT giúp kiểm thử toàn diện, phù hợp với kiểm tra chức năng và tính chính xác. Tiêu chí bao phủ trong MBT gồm bao phủ cấu trúc, dữ liệu, lỗi và yêu cầu. Quá trình MBT gồm mô hình hóa, lựa chọn yêu cầu, sinh kiểm thử, cụ thể hóa và thực thi kiểm thử.

Ba khái niệm chuyên ngành quan trọng được sử dụng là: độ bao phủ (coverage), ca kiểm thử (test case), và bộ kiểm thử (test suite).

Phương pháp nghiên cứu

Nghiên cứu sử dụng phương pháp thực nghiệm kết hợp phân tích định tính và định lượng:

• Nguồn dữ liệu: Thu thập từ các ứng dụng Android thực tế, các công cụ kiểm thử tự động Monkey và DroidBot, cùng các báo cáo lỗi và log kiểm thử.

• Phương pháp chọn mẫu: Lựa chọn các ứng dụng Android phổ biến và có tính đại diện cao trên Google Play, đảm bảo đa dạng về loại hình và chức năng.

• Phương pháp phân tích: So sánh hiệu quả kiểm thử dựa trên các chỉ số như số lượng lỗi phát hiện, độ bao phủ mã nguồn, và khả năng khám phá các trạng thái ứng dụng. Sử dụng phân tích thống kê mô tả và so sánh tỷ lệ phần trăm giữa các phương pháp.

• Timeline nghiên cứu: Nghiên cứu được thực hiện trong năm 2017, với các giai đoạn chuẩn bị công cụ, xây dựng ứng dụng kiểm thử, thực hiện kiểm thử, thu thập và phân tích dữ liệu, kết luận và đề xuất.

Kết quả nghiên cứu và thảo luận

Những phát hiện chính

1. Hiệu quả phát hiện lỗi: Công cụ Monkey (kiểm thử Fuzz) phát hiện được khoảng 30% lỗi trong các ứng dụng thử nghiệm, trong khi DroidBot (kiểm thử dựa trên mô hình) phát hiện được khoảng 45%. Điều này cho thấy phương pháp dựa trên mô hình có khả năng phát hiện lỗi sâu hơn và đa dạng hơn.

2. Độ bao phủ mã nguồn: DroidBot đạt độ bao phủ mã nguồn trung bình 65%, cao hơn đáng kể so với Monkey với khoảng 40%. Độ bao phủ cao giúp tăng khả năng phát hiện lỗi và kiểm thử toàn diện hơn.

3. Chiến lược khám phá: DroidBot sử dụng chiến lược thăm dò breadth-first giúp khám phá nhiều trạng thái UI hơn, trong khi Monkey dựa trên sự kiện ngẫu nhiên nên có thể bỏ sót các luồng quan trọng.

4. Tính khả dụng: Monkey dễ sử dụng, tích hợp sẵn trong Android SDK, phù hợp cho kiểm thử nhanh và stress test. DroidBot yêu cầu cấu hình phức tạp hơn nhưng cung cấp kết quả kiểm thử chi tiết và có thể tùy chỉnh thuật toán sinh đầu vào.

Thảo luận kết quả

Nguyên nhân DroidBot vượt trội về độ bao phủ và phát hiện lỗi là do phương pháp kiểm thử dựa trên mô hình cho phép mô hình hóa chính xác các trạng thái và hành vi của ứng dụng, từ đó sinh ra các ca kiểm thử có mục tiêu và hiệu quả hơn. Monkey với kỹ thuật fuzzing ngẫu nhiên tuy đơn giản nhưng dễ bỏ sót các trường hợp kiểm thử quan trọng.

So sánh với các nghiên cứu trong ngành, kết quả phù hợp với báo cáo của các chuyên gia kiểm thử phần mềm khi nhấn mạnh ưu thế của kiểm thử dựa trên mô hình trong việc kiểm thử các ứng dụng phức tạp. Tuy nhiên, Monkey vẫn giữ vai trò quan trọng trong kiểm thử nhanh và phát hiện lỗi bảo mật phổ biến.

Dữ liệu có thể được trình bày qua biểu đồ cột so sánh số lỗi phát hiện và độ bao phủ giữa hai công cụ, cũng như bảng tổng hợp các chỉ số hiệu quả kiểm thử.

Đề xuất và khuyến nghị

1. Áp dụng kết hợp hai phương pháp kiểm thử: Kết hợp kiểm thử Fuzz với kiểm thử dựa trên mô hình để tận dụng ưu điểm của cả hai, tăng khả năng phát hiện lỗi và độ bao phủ. Thời gian thực hiện: 3-6 tháng. Chủ thể: các nhóm phát triển và kiểm thử phần mềm.

2. Phát triển công cụ kiểm thử dựa trên mô hình tùy chỉnh: Tùy chỉnh và mở rộng các thuật toán sinh đầu vào của DroidBot để phù hợp với đặc thù ứng dụng và yêu cầu kiểm thử cụ thể. Thời gian: 6-12 tháng. Chủ thể: nhóm nghiên cứu và phát triển phần mềm.

3. Đào tạo và nâng cao năng lực kiểm thử tự động: Tổ chức các khóa đào tạo về kiểm thử tự động, đặc biệt là kiểm thử dựa trên mô hình cho đội ngũ kiểm thử viên và lập trình viên. Thời gian: liên tục. Chủ thể: các tổ chức đào tạo, doanh nghiệp phần mềm.

4. Xây dựng quy trình kiểm thử tự động chuẩn hóa: Thiết lập quy trình kiểm thử tự động tích hợp trong vòng đời phát triển phần mềm, đảm bảo kiểm thử liên tục và hiệu quả. Thời gian: 6 tháng. Chủ thể: phòng quản lý dự án và phát triển phần mềm.

Đối tượng nên tham khảo luận văn

1. Nhà phát triển phần mềm Android: Nắm bắt các phương pháp kiểm thử tự động để nâng cao chất lượng sản phẩm, giảm thiểu lỗi và tăng độ tin cậy ứng dụng.

2. Kiểm thử viên phần mềm: Áp dụng các kỹ thuật sinh đầu vào kiểm thử tự động, đặc biệt là kiểm thử Fuzz và kiểm thử dựa trên mô hình, để tối ưu hóa quy trình kiểm thử.

3. Nhà nghiên cứu công nghệ phần mềm: Tham khảo các phương pháp và công cụ kiểm thử tự động hiện đại, làm cơ sở phát triển nghiên cứu sâu hơn về kiểm thử phần mềm di động.

4. Doanh nghiệp phát triển ứng dụng di động: Xây dựng chiến lược kiểm thử tự động hiệu quả, giảm chi phí và thời gian kiểm thử, nâng cao năng lực cạnh tranh trên thị trường.

Câu hỏi thường gặp

1. Kiểm thử Fuzz là gì và có ưu điểm gì?
   Kiểm thử Fuzz là kỹ thuật kiểm thử hộp đen sử dụng dữ liệu đầu vào ngẫu nhiên để phát hiện lỗi phần mềm, đặc biệt là lỗi bảo mật nghiêm trọng. Ưu điểm là không cần truy cập mã nguồn, phát hiện lỗi nhanh và hiệu quả.

2. Kiểm thử dựa trên mô hình khác gì so với kiểm thử truyền thống?
   Kiểm thử dựa trên mô hình sử dụng mô hình hành vi của hệ thống để tự động sinh ca kiểm thử, giúp kiểm thử toàn diện và có hệ thống hơn so với kiểm thử thủ công hoặc ngẫu nhiên.

3. Monkey và DroidBot khác nhau như thế nào?
   Monkey là công cụ kiểm thử ngẫu nhiên tích hợp trong Android SDK, dễ sử dụng nhưng độ bao phủ thấp. DroidBot dựa trên mô hình, sinh đầu vào có mục tiêu, độ bao phủ cao hơn nhưng phức tạp hơn khi sử dụng.

4. Làm sao để đánh giá hiệu quả của các công cụ kiểm thử tự động?
   Hiệu quả được đánh giá qua số lượng lỗi phát hiện, độ bao phủ mã nguồn, khả năng khám phá các trạng thái ứng dụng và tính khả dụng trong thực tế.

5. Có thể áp dụng các phương pháp này cho các nền tảng khác ngoài Android không?
   Các nguyên lý kiểm thử Fuzz và dựa trên mô hình có thể áp dụng cho nhiều nền tảng khác, tuy nhiên công cụ và kỹ thuật cụ thể cần được điều chỉnh phù hợp với đặc thù từng nền tảng.

Kết luận

• Nghiên cứu đã phân tích và thực nghiệm hai phương pháp sinh đầu vào kiểm thử tự động cho Android: kiểm thử Fuzz và kiểm thử dựa trên mô hình.
• Kết quả thực nghiệm cho thấy kiểm thử dựa trên mô hình với công cụ DroidBot vượt trội hơn về độ bao phủ và phát hiện lỗi so với kiểm thử Fuzz với Monkey.
• Việc kết hợp hai phương pháp kiểm thử sẽ tối ưu hóa hiệu quả kiểm thử tự động cho ứng dụng Android.
• Đề xuất phát triển công cụ, đào tạo nhân lực và xây dựng quy trình kiểm thử tự động chuẩn hóa nhằm nâng cao chất lượng phần mềm.
• Các bước tiếp theo bao gồm mở rộng nghiên cứu, phát triển thuật toán sinh đầu vào mới và áp dụng thực tế trong các dự án phát triển phần mềm.

Hành động ngay: Các nhà phát triển và kiểm thử phần mềm nên áp dụng kết hợp các phương pháp kiểm thử tự động để nâng cao chất lượng sản phẩm và giảm thiểu rủi ro lỗi phần mềm.

Trích đoạn nội dung tài liệu

Chương 1. Nền tảng Android 1. Giới thiệu chung về Android Android là hệ điều hành mã nguồn mở, dựa trên Linux, được tạo ra cho một loạt các thiết bị và yếu tố hình thức.1 cho biết các thành phần chính của nền tảng Android [2]: - Tầng hạt nhân Linux: nền tảng của hệ điều hành Android là hạt nhân Linux. Tất cả mọi hoạt động của thiết bị đều phải thực thi ở tầng này.

Tầng này bao gồm các tiến trình quản lý bộ nhớ (memory management), giao tiếp với phần cứng (driver model), bảo mật (security), quản lý tiến trình (process). Sử dụng hạt nhân Linux cho phép Android tận dụng các tính năng bảo mật then chốt và cho phép các nhà sản xuất thiết bị phát triển trình điều khiển phần cứng cho hạt nhân nổi tiếng này - Lớp trừu tượng phần cứng (Hardware Abstraction Layer - HAL): cung cấp các giao diện chuẩn để phần cứng thiết bị có thể giao tiếp với các nền tảng Java API ở cấp cao hơn. Lớp trừu tượng phần cứng này bao gồm nhiều mô đun thư viện, mỗi mô đun này lại thực thi một giao diện cho một loại thành phần phần cứng cụ thể, chẳng hạn như là mô đun máy ảnh hoặc mô đun Bluetooth. Khi bộ khung API (API framework) thực hiện cuộc gọi để truy cập phần cứng thiết bị, hệ thống Android sẽ tải mô đun thư viện cho thành phần phần cứng đó.

- Thời gian chạy Android (Android Runtime – ART): đối với các thiết bị chạy Android phiên bản 5.0 (API 21) trở lên, mỗi ứng dụng chạy trong tiến trình của chính nó với thể hiện chính nó của thời gian chạy Android. Thời gian chạy Android được viết để chạy nhiều máy ảo trên các thiết bị có bộ nhớ thấp bằng cách thực thi các tập DEX, một định dạng byte-code được thiết kế đặc biệt cho Android, được tối ưu hóa cho bộ nhớ tối thiểu. Xây dựng các công cụ, chẳng hạn như Jack, biên soạn các nguồn Java vào mã DEX byte-code, có thể chạy trên nền tảng Android. Một số tính năng chính của thời gian chạy Android bao gồm: • Biên dịch trước thời hạn (Ahead-Of-Time - AOT) và trong thời hạn (Just-In- Time - JIT) • Tối ưu hóa thu gom rác (Garbage Collection - GC) 9 z • Hỗ trợ gỡ lỗi tốt hơn, bao gồm một hồ sơ mẫu riêng, các ngoại lệ chuẩn đoán chi tiết, báo cáo sự cố và khả năng thiết lập các điểm quan sát để giám sát các lĩnh vực cụ thể.

Trước phiên bản Android 5.0 (Cấp độ API 21), Dalvik chính là thời gian chạy Android. Nếu ứng dụng người dùng chạy tốt trên ART, thì cũng có thể làm việc trên Dalvik, nhưng ngược lại có thể không đúng. Android cũng bao gồm một tập hợp các thư viện chạy lõi cung cấp hầu hết các chức năng của ngôn ngữ lập trình Java, bao gồm một số tính năng ngôn ngữ Java 8, mà khuôn khổ Java API sử dụng - Tầng thư viện C/C++: nhiều thành phần và dịch vụ cốt lõi của hệ thống, như là HAL và ART, được xây dựng từ mã nguồn cục bộ yêu cầu các thư viện gốc được viết bằng C và C++. Nền tảng Android cung cấp các API của bộ khung Java để phô bày tính năng của một số thư viện gốc này cho các ứng dụng.

Ví dụ, có thể truy cập vào OpenGL ES thông qua các Java OpenGL API của bộ khung Android để thêm hỗ trợ vẽ và thao tác đồ họa 2D và 3D trong ứng dụng. Nếu ứng dụng phát triển yêu cầu mã nguồn C hoặc C ++, ta có thể sử dụng Android NDK để truy cập vào một số thư viện nền tảng gốc trực tiếp từ mã nguồn gốc. - Tầng khung Java API: toàn bộ tập hợp các tính năng của hệ điều hành Android đã có sẵn thông qua các API được viết bằng ngôn ngữ Java. Các API này tạo thành những khối xây dựng sẵn mà chúng ta hoàn toàn có thể lấy ra sử dụng khi muốn xây dựng các ứng dụng Android.

Các API này giúp đơn giản hóa việc tái sử dụng phần lõi Android cũng như là các thành phần và dịch vụ của hệ thống mô đun sau: • View System phong phú và có khả năng mở rô ̣ng, người dùng có thể sử du ̣ng để xây dựng UI của ứng du ̣ng, bao gồm các danh sách, lưới, hô ̣p văn bản, các nút bấ m, và thâ ̣m chí mô ̣t trıǹ h duyê ̣t web nhúng • Trıǹ h quản lý tài nguyên, cung cấp quyền truy cập vào các tài nguyên không mã nguồ n như là chuỗi cu ̣c bộ, đồ họa, các tê ̣p bố cu ̣c. • Trı̀nh quản lý thông báo: cho phép tấ t cả các ứng du ̣ng hiể n thi ̣ cảnh báo tùy ̉ h trong thanh trạng thái chın • Trıǹ h quản lý hoa ̣t đô ̣ng: quản lý vòng đời của ứng du ̣ng và cung cấ p ngăn xế p trở la ̣i chuyể n hướng thông du ̣ng.1: Cấ u trúc ngăn xếp phầ n mềm Android • Trình cung cấ p nô ̣i dung: cho phép ứng du ̣ng truy câ ̣p dữ liê ̣u từ các ứng dụng khác, chẳ ng ha ̣n như ứng du ̣ng danh ba ̣ hoă ̣c để chia sẻ dữ liê ̣u riêng của chúng. Nhà phát triể n có quyền truy câ ̣p đầy đủ vào cùng bộ khung API mà các ứng du ̣ng hê ̣ thống Android sử dụng. - Tầ ng ứng dụng hê ̣ thố ng: Android đi kèm với mô ̣t bô ̣ các ứng du ̣ng cố t lõi như ̣ trıǹ h duyê ̣t internet, danh ba ̣ và hơn thế nữa.

Ứng du ̣ng đi email, tin nhắ n SMS, lich, 1 https://developer.com/guide/platform/index.html 11 z kèm với nề n tảng này không có tra ̣ng thái đă ̣c biê ̣t so với các ứng du ̣ng mà người dùng tự cài đă ̣t. Vı̀ vâ ̣y, ứng du ̣ng của bên thứ ba vẫn có thể trở thành trıǹ h duyê ̣t web mă ̣c đinh, ̣ tin nhắ n SMS mă ̣c đinh, ́ mă ̣c đinh ̣ hoă ̣c thâ ̣m chı́ bàn phım ̣ của người dùng. Các ứng du ̣ng hê ̣ thố ng hoạt đô ̣ng như mô ̣t ứng du ̣ng cho người dùng và đồ ng thời cung cấp các khả cơ bản mà nhà phát triể n có thể truy câ ̣p từ ứng du ̣ng của riêng ho ̣. Ví du ̣, nếu một ứng dụng của người dùng muố n gửi tin nhắ n SMS, người dùng không cầ n phải tự xây dựng chức năng đó, thay vào đó có thể go ̣i ứng du ̣ng SMS nào đó đã đươ ̣c cài đă ̣t để gửi tin nhắ n tới người nhâ ̣n chı̉ đinh.

Bản kê khai ứng dụng AndroidManifest Mọi ứng dụng Android đều phải có một tệp AndroidManifest.xml trong thư mục gốc của mình. Tệp kê khai này trình bày những thông tin thiết yếu về ứng dụng với hệ thống, thông tin mà hệ thống phải có trước khi có thể chạy bất kỳ mã nào của ứng dụng. Các giá trị trong tập tin Manifest bị ràng buộc vào ứng dụng tại thời điểm biên dịch và không thể thay đổi sau đó, trừ khi thực hiện biên dịch lại ứng dụng. Một trong các loại thông tin chính mà tập tin Manifest này chứa là chúng khai báo các thành phần của ứng dụng.

Các thành phần này có thể là một hoặc nhiều trong các loại sau: - Hoạt động (Activity) - Dịch vụ (Service) - Bộ nhận quảng bá (Broadcast Receiver) - Trình cung cấp nội dung (Content Provider) 1. Hoạt động (activity) [3] Khái niệm Hoạt động là thành phần phụ trách giao diện người dùng của ứng dụng. Một hoạt động là một giao diện trực quan mà người dùng có thể thực hiện trên đó mỗi khi được kích hoạt. Một ứng dụng có thể có nhiều hoạt động và chúng có thể gọi đến nhau hoặc chuyển giữa các hoạt động với nhau.

Mỗi hoạt động là một dẫn xuất của lớp android. Mỗi hoạt động có một cửa sổ để vẽ lên. Thông thường cửa sổ này phủ đầy màn hình, ngoài ra nó cũng có thể có thêm các cửa sổ con khác như là hộp thoại. Nội dung 12 z cửa sổ của hoạt động được cung cấp bởi một hệ thống cấp bậc các Khung nhìn (là đối tượng của lớp Views).

Vòng đời của hoạt động Các hoạt động trong hệ thống được quản lý bởi một cấu trúc dữ liệu ngăn xếp. Khi có một hoạt động được khởi tạo, nó được đẩy vào trong ngăn xếp, chuyển sang trạng thái thực thi và hoạt trộng trước đó sẽ chuyển sang trạng thái chờ. Hoạt động này chỉ trở lại trạng thái kích hoạt khi mà hoạt động vừa khởi tạo kết thúc việc thực thi. Một hoạt động có bốn trạng thái chính là: - Hoạt động hoặc đang chạy: khi nó đang hiển thị ở trên màn hình và nhận tương tác người dùng - Tạm dừng: khi hoạt động không còn là trọng tâm trên màn hình nhưng vẫn hiển thị trước người dùng.

- Dừng: Khi một hoạt động hoàn toàn bị che khuất, nó sẽ rơi vào trạng thái Dừng. Tuy nhiên, nó vẫn còn lưu trữ toàn bộ thông tin trạng thái. Và nó thường bị hệ thống đóng lại khi có tình trạng thiếu bộ nhớ. Khi chuyển giữa các trạng thái, ứng dụng sẽ gọi các hàm gọi lại ứng với các bước chuyển: void onCreate(Bundle savedInstanceState) void onStart() void onRestart() void onResume() void onPause() void onStop() void onDestroy() Biểu đồ sau mô tả trạng thái trong vòng đời của một hoạt động.

Hình chữ nhật thể hiện các phương thức gọi lại mà chúng ta có thể khai báo để gọi thực thi một số thao tác khi hoạt động chuyển sang trạng thái khác (phương thức gọi lại là phương thức được gọi lại bởi một phương thức khác khi có một sự kiện xảy ra). Các trạng thái chính của một hoạt động được thể hiện bởi các hình viên thuốc: 13 z 2 Hình 1.2: Vòng đời của một hoạt động (activity) trong ứng dụng Android Vòng đời của một hoạt động được thể hiện trong những quá trình sau: Toàn bộ vòng đời của một hoạt động bắt đầu từ lời gọi đầu tiên tới phương thức onCreate (Bundle) cho tới khi có lời gọi phương thức onDestroy(). Trong quá trình này, một hoạt động sẽ khởi tạo lại tất cả các tài nguyên cần sử dụng trong phương thức onCreate() và giải phóng chúng khi phương thức onDestroy() được thực thi. Vòng đời có thể nhìn thấy của một hoạt động bắt đầu từ lời gọi tới phương thức onStart(), cho tới khi phương thức onStop() của nó được thực thi.

Toàn bộ các tài nguyên đang được sử dụng bởi hoạt động vẫn tiếp tục được lưu giữ, người dùng có thể thấy 2 https://developer.com/reference/android/app/Activity.html 14 z giao diện nhưng không tương tác được với hoạt động do trong quá trình này hoạt động không ở trạng thái chạy tiền cảnh.