Các thay đổi về hành vi của Android 5.0

Cấp độ API: 21

Cùng với các tính năng và khả năng mới, Android 5.0 bao gồm nhiều thay đổi về hệ thống và thay đổi về hành vi của API. Tài liệu này nêu bật một số thay đổi chính mà bạn nên hiểu và lưu ý trong ứng dụng của mình.

Nếu bạn từng phát hành một ứng dụng dành cho Android, hãy lưu ý rằng những thay đổi này trong Android 5.0 có thể ảnh hưởng đến ứng dụng của bạn.

Để có cái nhìn tổng quan về các tính năng mới của nền tảng, thay vào đó, hãy xem những điểm nổi bật của Android Lollipop.

Video

Dev Byte: Tính năng mới trong Android 5.0

Dev Byte: Thông báo

Android Runtime (ART)

Trong Android 5.0, thời gian chạy ART sẽ thay thế Dalvik làm nền tảng mặc định. Môi trường thời gian chạy ART được ra mắt trong Android 4.4 trên cơ sở thử nghiệm.

Để biết thông tin tổng quan về các tính năng mới của ART, hãy xem phần Giới thiệu về ART. Sau đây là một số tính năng chính mới:

• Biên dịch trước khi thực thi (AOT)
• Cải tiến tính năng thu gom rác (GC)
• Hỗ trợ gỡ lỗi được cải thiện

Hầu hết các ứng dụng Android sẽ hoạt động mà không có bất kỳ thay đổi nào theo ART. Tuy nhiên, một số kỹ thuật hoạt động trên Dalvik không hoạt động trên ART. Để biết thông tin về các vấn đề quan trọng nhất, hãy xem phần Xác minh Hành vi của ứng dụng trên Android Runtime (ART). Đặc biệt chú ý nếu:

• Ứng dụng của bạn dùng Giao diện gốc Java (JNI) để chạy mã C/C++.
• Bạn sử dụng các công cụ phát triển có chức năng tạo mã không chuẩn (chẳng hạn như một số trình làm rối mã nguồn).
• Bạn sử dụng các kỹ thuật không tương thích với việc nén chặt việc thu gom rác.

Thông báo

Đảm bảo thông báo của bạn có tính đến những thay đổi này đối với Android 5.0. Để tìm hiểu thêm về cách thiết kế thông báo cho Android 5.0 trở lên, hãy xem hướng dẫn thiết kế thông báo.

Kiểu thiết kế Material Design

Thông báo được vẽ với văn bản tối ở trên cùng màu trắng (hoặc nền rất sáng) để phù hợp với các tiện ích thiết kế Material Design mới. Đảm bảo rằng tất cả các thông báo của bạn đều hiển thị đúng cách với bảng phối màu mới. Nếu thông báo của bạn có hình thức hiển thị không chính xác, hãy khắc phục các vấn đề đó:

• Sử dụng setColor() để đặt màu nhấn trong một vòng tròn phía sau hình ảnh biểu tượng của bạn.
• Cập nhật hoặc xoá những thành phần liên quan đến màu sắc. Hệ thống sẽ bỏ qua tất cả các kênh không phải alpha trong biểu tượng hành động và trong biểu tượng thông báo chính. Bạn nên giả định rằng các biểu tượng này sẽ chỉ có chữ alpha. Hệ thống vẽ các biểu tượng thông báo màu trắng và biểu tượng hành động màu xám đậm.

Âm thanh và rung

Nếu bạn đang thêm âm thanh và chế độ rung vào thông báo bằng cách dùng các lớp Ringtone, MediaPlayer hoặc Vibrator, hãy xoá mã này để hệ thống có thể hiển thị thông báo chính xác ở chế độ ưu tiên. Thay vào đó, hãy dùng các phương thức Notification.Builder để thêm âm thanh và chế độ rung.

Việc đặt thiết bị thành RINGER_MODE_SILENT sẽ khiến thiết bị chuyển sang chế độ ưu tiên mới. Thiết bị sẽ thoát khỏi chế độ ưu tiên nếu bạn đặt thành RINGER_MODE_NORMAL hoặc RINGER_MODE_VIBRATE.

Trước đây, Android sử dụng STREAM_MUSIC làm luồng chính để điều chỉnh âm lượng trên thiết bị máy tính bảng. Trên Android 5.0, luồng âm lượng chính cho cả thiết bị điện thoại và máy tính bảng hiện được hợp nhất và do STREAM_RING hoặc STREAM_NOTIFICATION kiểm soát.

Chế độ hiển thị trên màn hình khoá

Theo mặc định, thông báo giờ đây sẽ xuất hiện trên màn hình khóa của người dùng trong Android 5.0. Người dùng có thể chọn bảo vệ thông tin nhạy cảm khỏi bị tiết lộ, trong trường hợp đó, hệ thống sẽ tự động loại bỏ văn bản mà thông báo hiển thị. Để tuỳ chỉnh thông báo đã bị loại bỏ này, hãy sử dụng setPublicVersion().

Nếu thông báo không chứa thông tin cá nhân, hoặc nếu bạn muốn cho phép điều khiển chế độ phát nội dung nghe nhìn trên thông báo, hãy gọi phương thức setVisibility() và đặt mức hiển thị của thông báo thành VISIBILITY_PUBLIC.

Phát nội dung nghe nhìn

Nếu bạn đang triển khai các thông báo thể hiện trạng thái phát nội dung nghe nhìn hoặc bộ điều khiển truyền tải, hãy cân nhắc sử dụng mẫu Notification.MediaStyle mới thay vì đối tượng RemoteViews.RemoteView tuỳ chỉnh. Dù bạn chọn phương pháp nào, hãy nhớ đặt chế độ hiển thị của thông báo thành VISIBILITY_PUBLIC để có thể truy cập vào các chế độ điều khiển từ màn hình khoá. Xin lưu ý rằng kể từ Android 5.0, hệ thống sẽ không hiển thị các đối tượng RemoteControlClient trên màn hình khoá nữa. Để biết thêm thông tin, hãy xem phần Nếu ứng dụng của bạn sử dụng RemoteControlClient.

Thông báo quan trọng

Giờ đây, thông báo có thể xuất hiện trong một cửa sổ nổi nhỏ (còn gọi là thông báo quan trọng) khi thiết bị đang hoạt động (nghĩa là thiết bị đã mở khoá và màn hình đang bật). Những thông báo này có vẻ giống như hình thức thu gọn của thông báo, ngoại trừ việc thông báo quan trọng cũng hiển thị các nút hành động. Người dùng có thể thao tác hoặc đóng một thông báo quan trọng mà không cần rời khỏi ứng dụng hiện tại.

Sau đây là ví dụ về các tình trạng có thể kích hoạt thông báo quan trọng:

• Hoạt động của người dùng đang ở chế độ toàn màn hình (ứng dụng sử dụng fullScreenIntent)
• Thông báo có mức độ ưu tiên cao và sử dụng nhạc chuông hoặc rung

Nếu ứng dụng của bạn triển khai thông báo trong bất kỳ trường hợp nào nêu trên, hãy đảm bảo rằng thông báo quan trọng được hiển thị chính xác.

Điều khiển nội dung đa phương tiện và RemoteControlClient

Lớp RemoteControlClient hiện không còn được sử dụng. Hãy chuyển sang API MediaSession mới càng sớm càng tốt.

Màn hình khoá trong Android 5.0 không hiển thị các chế độ điều khiển truyền tải cho MediaSession hoặc RemoteControlClient. Thay vào đó, ứng dụng của bạn có thể cung cấp tính năng điều khiển chế độ phát nội dung nghe nhìn từ màn hình khoá thông qua một thông báo. Điều này giúp ứng dụng của bạn có nhiều quyền kiểm soát hơn đối với cách trình bày các nút đa phương tiện, đồng thời mang lại trải nghiệm nhất quán cho người dùng trên các thiết bị đã khoá và đã mở khoá.

Android 5.0 giới thiệu mẫu Notification.MediaStyle mới cho mục đích này. Notification.MediaStyle chuyển đổi các hành động thông báo mà bạn đã thêm bằng Notification.Builder.addAction() thành các nút nhỏ gọn được nhúng trong thông báo phát nội dung nghe nhìn của ứng dụng. Truyền mã thông báo phiên của bạn vào phương thức setSession() để cho hệ thống biết rằng thông báo này kiểm soát một phiên phát nội dung nghe nhìn đang diễn ra.

Hãy nhớ đặt chế độ hiển thị của thông báo thành VISIBILITY_PUBLIC để đánh dấu thông báo là an toàn để hiển thị trên mọi màn hình khoá (bảo mật hoặc tuỳ chọn khác). Để biết thêm thông tin, hãy xem bài viết Thông báo trên màn hình khoá.

Để hiển thị bộ điều khiển chế độ phát nội dung nghe nhìn nếu ứng dụng của bạn đang chạy trên nền tảng Android TV hoặc Wear, hãy triển khai lớp MediaSession. Bạn cũng nên triển khai MediaSession nếu ứng dụng của bạn cần nhận các sự kiện nút đa phương tiện trên thiết bị Android.

getRecentTasks()

Với sự ra mắt của tính năng tác vụ tài liệu và hoạt động đồng thời mới trong Android 5.0 (xem phần Tài liệu và hoạt động đồng thời trên màn hình gần đây ở bên dưới), phương thức ActivityManager.getRecentTasks() hiện không còn được dùng để cải thiện quyền riêng tư của người dùng. Để có khả năng tương thích ngược, phương thức này vẫn trả về một tập nhỏ dữ liệu, bao gồm cả các tác vụ của chính ứng dụng gọi và có thể là một số tác vụ không nhạy cảm khác (chẳng hạn như Màn hình chính). Nếu ứng dụng của bạn đang sử dụng phương thức này để truy xuất các tác vụ của chính ứng dụng, hãy sử dụng getAppTasks() để truy xuất thông tin đó.

Hỗ trợ 64 bit trong Android NDK

Android 5.0 hỗ trợ các hệ thống 64 bit. Tính năng nâng cao 64 bit giúp tăng không gian địa chỉ và cải thiện hiệu suất, trong khi vẫn hỗ trợ đầy đủ các ứng dụng 32 bit hiện có. Tính năng hỗ trợ 64 bit cũng cải thiện hiệu suất của OpenSSL dùng cho quá trình mã hoá. Ngoài ra, bản phát hành này giới thiệu các API phương tiện nghe nhìn gốc mới của NDK, cũng như tính năng hỗ trợ gốc OpenGL ES (GLES) 3.1.

Để sử dụng tính năng hỗ trợ 64 bit có trong Android 5.0, hãy tải xuống và cài đặt NDK Bản sửa đổi 10c trên trang Android NDK. Hãy tham khảo ghi chú phát hành của Bản sửa đổi 10c để biết thêm thông tin về những thay đổi quan trọng và bản sửa lỗi đối với NDK.

Liên kết với một dịch vụ

Phương thức Context.bindService() hiện yêu cầu một Intent rõ ràng và trả về một ngoại lệ nếu có ý định ngầm ẩn. Để đảm bảo ứng dụng của bạn được an toàn, hãy sử dụng ý định tường minh khi bắt đầu hoặc liên kết Service và không khai báo bộ lọc ý định cho dịch vụ.

WebView

Android 5.0 thay đổi hành vi mặc định của ứng dụng.

• Nếu ứng dụng của bạn nhắm đến API cấp 21 trở lên:
  • Theo mặc định, hệ thống sẽ chặn nội dung hỗn hợp và cookie của bên thứ ba. Để cho phép nội dung hỗn hợp và cookie của bên thứ ba, hãy dùng các phương thức setMixedContentMode() và setAcceptThirdPartyCookies() tương ứng.
  • Giờ đây, hệ thống sẽ chọn một cách thông minh các phần của tài liệu HTML để vẽ. Hành vi mặc định mới này giúp giảm mức sử dụng bộ nhớ và tăng hiệu suất. Nếu bạn muốn kết xuất toàn bộ tài liệu cùng một lúc, hãy tắt tính năng tối ưu hoá này bằng cách gọi enableSlowWholeDocumentDraw().
• Nếu ứng dụng của bạn nhắm đến các cấp độ API thấp hơn 21: Hệ thống cho phép nội dung hỗn hợp và cookie của bên thứ ba và luôn hiển thị toàn bộ tài liệu cùng một lúc.

Yêu cầu về tính riêng biệt đối với quyền tuỳ chỉnh

Như đã nêu trong phần tổng quan về Quyền, ứng dụng Android có thể xác định quyền tuỳ chỉnh làm phương thức quản lý quyền truy cập vào các thành phần theo cách độc quyền mà không cần sử dụng các quyền hệ thống được xác định trước của nền tảng. Ứng dụng xác định quyền tuỳ chỉnh trong các phần tử <permission> được khai báo trong tệp kê khai.

Trong một số ít trường hợp, việc xác định quyền tuỳ chỉnh là phương pháp hợp pháp và an toàn trong một số trường hợp. Tuy nhiên, việc tạo quyền tuỳ chỉnh đôi khi là không cần thiết và thậm chí có thể gây rủi ro tiềm ẩn cho ứng dụng, tuỳ thuộc vào cấp độ bảo vệ được chỉ định cho các quyền đó.

Android 5.0 có một thay đổi về hành vi để đảm bảo rằng chỉ một ứng dụng có thể xác định một quyền tuỳ chỉnh nhất định, trừ phi được ký bằng cùng một khoá với các ứng dụng khác xác định quyền đó.

Ứng dụng dùng quyền tuỳ chỉnh trùng lặp

Bất kỳ ứng dụng nào cũng có thể xác định bất kỳ quyền tuỳ chỉnh nào mà nó muốn, vì vậy có thể xảy ra trường hợp nhiều ứng dụng xác định cùng một quyền tuỳ chỉnh. Ví dụ: nếu hai ứng dụng có tính năng tương tự nhau, thì các ứng dụng đó có thể lấy cùng một tên logic cho các quyền tuỳ chỉnh. Ứng dụng cũng có thể kết hợp các thư viện công khai phổ biến hoặc mã ví dụ mà chính chúng chứa các định nghĩa quyền tuỳ chỉnh tương tự.

Trong Android 4.4 trở xuống, người dùng có thể cài đặt nhiều ứng dụng như vậy trên một thiết bị nhất định, mặc dù hệ thống đã chỉ định cấp độ bảo vệ do ứng dụng cài đặt đầu tiên chỉ định.

Kể từ Android 5.0, hệ thống thực thi một hạn chế mới về tính duy nhất đối với các quyền tuỳ chỉnh đối với những ứng dụng được ký bằng các khoá khác nhau. Giờ đây, chỉ một ứng dụng trên thiết bị có thể xác định một quyền tuỳ chỉnh nhất định (như được xác định theo tên), trừ phi ứng dụng khác xác định quyền đó được ký bằng cùng một khoá. Nếu người dùng cố gắng cài đặt một ứng dụng có quyền tuỳ chỉnh trùng lặp và không được ký bằng cùng một khoá với ứng dụng thường trú xác định quyền, thì hệ thống sẽ chặn việc cài đặt.

Những điều cần cân nhắc đối với ứng dụng của bạn

Trên Android 5.0 trở lên, các ứng dụng có thể tiếp tục xác định quyền tuỳ chỉnh riêng như trước đây và để yêu cầu quyền tuỳ chỉnh từ các ứng dụng khác thông qua cơ chế <uses-permission>. Tuy nhiên, với yêu cầu mới được đưa ra trong Android 5.0, bạn nên đánh giá cẩn thận các tác động có thể xảy ra đối với ứng dụng của mình.

Dưới đây là một số điểm cần lưu ý:

• Ứng dụng của bạn có khai báo phần tử <permission> nào trong tệp kê khai không? Nếu có, thì những dữ liệu này có thực sự cần thiết cho chức năng thích hợp của ứng dụng hoặc dịch vụ của bạn không? Hoặc bạn có thể sử dụng quyền mặc định của hệ thống không?
• Nếu bạn có các phần tử <permission> trong ứng dụng, bạn có biết các phần tử đó đến từ đâu không?
• Bạn có thực sự muốn các ứng dụng khác yêu cầu quyền tuỳ chỉnh của bạn thông qua <uses-permission> không?
• Bạn có đang sử dụng mã nguyên mẫu hoặc mã mẫu trong ứng dụng có chứa các phần tử <permission> không? Các phần tử quyền đó có thực sự cần thiết không?
• Các quyền tuỳ chỉnh của bạn có sử dụng tên đơn giản hay dựa trên thuật ngữ phổ biến mà các ứng dụng khác có thể dùng chung không?

Bản cập nhật và lượt cài đặt mới

Như đã đề cập ở trên, các lượt cài đặt mới và bản cập nhật ứng dụng của bạn trên các thiết bị chạy Android 4.4 trở xuống sẽ không bị ảnh hưởng và không có thay đổi nào về hành vi. Đối với các lượt cài đặt mới và bản cập nhật trên thiết bị chạy Android 5.0 trở lên, hệ thống sẽ ngăn chặn việc cài đặt ứng dụng của bạn nếu hệ thống xác định quyền tuỳ chỉnh đã được một ứng dụng cư trú hiện có xác định.

Số lượt cài đặt hiện có nhờ bản cập nhật hệ thống Android 5.0

Nếu ứng dụng của bạn sử dụng các quyền tuỳ chỉnh và được phân phối cũng như cài đặt rộng rãi, thì có khả năng ứng dụng sẽ bị ảnh hưởng khi người dùng cập nhật thiết bị lên Android 5.0. Sau khi cài đặt bản cập nhật hệ thống, hệ thống sẽ xác thực lại các ứng dụng đã cài đặt, bao gồm cả việc kiểm tra quyền tuỳ chỉnh của những ứng dụng đó. Nếu ứng dụng của bạn xác định quyền tuỳ chỉnh đã được một ứng dụng khác đã xác thực xác định và ứng dụng của bạn không được ký bằng cùng một khoá như ứng dụng khác, thì hệ thống sẽ không cài đặt lại ứng dụng của bạn.

Đề xuất

Trên các thiết bị chạy Android 5.0 trở lên, bạn nên kiểm tra ứng dụng ngay lập tức, thực hiện mọi điều chỉnh cần thiết và phát hành phiên bản cập nhật sớm nhất có thể cho người dùng.

• Nếu bạn đang sử dụng quyền tuỳ chỉnh trong ứng dụng, hãy xem xét nguồn gốc của các quyền đó và liệu bạn có thực sự cần đến hay không. Xoá tất cả phần tử <permission> khỏi ứng dụng của bạn, trừ phi bạn chắc chắn rằng các phần tử đó cần phải có để hoạt động bình thường của ứng dụng.
• Nếu có thể, hãy cân nhắc thay thế quyền tuỳ chỉnh của bạn bằng quyền mặc định của hệ thống.
• Nếu ứng dụng của bạn đòi hỏi các quyền tuỳ chỉnh, hãy đổi tên các quyền tuỳ chỉnh sao cho dành riêng cho ứng dụng của bạn, chẳng hạn như bằng cách thêm các quyền đó vào tên gói đầy đủ của ứng dụng.
• Nếu bạn có một bộ ứng dụng được ký bằng các khoá khác nhau và các ứng dụng đó truy cập vào một thành phần dùng chung thông qua quyền tuỳ chỉnh, hãy đảm bảo rằng quyền tuỳ chỉnh đó chỉ được xác định một lần trong thành phần dùng chung. Các ứng dụng sử dụng thành phần dùng chung không nên tự xác định quyền tuỳ chỉnh mà nên yêu cầu quyền truy cập thông qua cơ chế <uses-permission>.
• Nếu bạn có một bộ ứng dụng được ký bằng cùng một khoá, thì mỗi ứng dụng có thể xác định cùng(các) quyền tuỳ chỉnh như cần thiết — hệ thống sẽ cho phép cài đặt các ứng dụng đó theo cách thông thường.

Các thay đổi về cấu hình mặc định của TLS/SSL

Android 5.0 ra mắt các thay đổi về cấu hình TLS/SSL mặc định mà các ứng dụng sử dụng cho HTTPS và lưu lượng truy cập TLS/SSL khác:

• TLS phiên bản 1.2 và giao thức TLS phiên bản 1.1 hiện đã được bật,
• Bộ thuật toán mật mã AES-GCM (AEAD) hiện đã bật,
• Bộ thuật toán mật mã MD5, 3DES, Xuất và khoá tĩnh ECDH hiện đã bị vô hiệu hoá,
• Bạn nên ưu tiên bộ thuật toán mật mã Bảo mật chuyển tiếp (ECDHE và DHE).

Những thay đổi này có thể làm hỏng kết nối HTTPS hoặc TLS/SSL trong một số ít trường hợp được liệt kê bên dưới.

Xin lưu ý rằng ProviderInstaller trong các Dịch vụ Google Play cung cấp những thay đổi này từ phiên bản Android 2.3 trở về trước trên các phiên bản nền tảng Android.

Máy chủ không hỗ trợ bất kỳ bộ thuật toán mật mã nào đã bật

Ví dụ: một máy chủ có thể chỉ hỗ trợ bộ thuật toán mật mã 3DES hoặc MD5. Cách khắc phục ưu tiên là cải thiện cấu hình của máy chủ để kích hoạt các giao thức và bộ thuật toán mật mã mạnh mẽ và hiện đại hơn. Tốt nhất là bạn nên bật TLSv1.2 và AES-GCM và nên bật và ưu tiên bộ thuật toán mật mã Chuyển tiếp bảo mật (ECDHE, DHE).

Một cách khác là sửa đổi ứng dụng để dùng một SSLSocketFactory tuỳ chỉnh nhằm giao tiếp với máy chủ. Nhà máy nên được thiết kế để tạo các thực thể SSLSocket có một số bộ thuật toán mật mã mà máy chủ yêu cầu ngoài các bộ thuật toán mật mã mặc định.

Ứng dụng đang đưa ra giả định sai về bộ thuật toán mật mã dùng để kết nối với máy chủ

Ví dụ: một số ứng dụng chứa một X509TrustManager tuỳ chỉnh bị lỗi vì ứng dụng này mong muốn tham số authType là RSA nhưng gặp ECDHE_RSA hoặc DHE_RSA.

Máy chủ không thích ứng với TLS phiên bản 1.1, TLS phiên bản 1.2 hoặc tiện ích TLS mới

Ví dụ: việc bắt tay TLS/SSL với một máy chủ bị từ chối hoặc bị ngừng do nhầm lẫn. Cách khắc phục ưu tiên là nâng cấp máy chủ để tuân thủ giao thức TLS/SSL. Điều này sẽ giúp máy chủ thương lượng thành công các giao thức mới hơn này hoặc thương lượng được TLS phiên bản 1 hoặc các giao thức cũ hơn và bỏ qua những tiện ích TLS mà máy chủ không hiểu. Trong một số trường hợp, việc vô hiệu hoá TLS phiên bản 1.1 và TLS phiên bản 1.2 trên máy chủ có thể là một biện pháp tạm thời cho đến khi phần mềm máy chủ được nâng cấp.

Một cách khác là sửa đổi ứng dụng để dùng một SSLSocketFactory tuỳ chỉnh nhằm giao tiếp với máy chủ. Nhà máy nên được thiết kế để tạo các thực thể SSLSocket chỉ bật những giao thức được máy chủ hỗ trợ đúng cách.

Hỗ trợ Hồ sơ được quản lý

Quản trị viên thiết bị có thể thêm hồ sơ được quản lý vào thiết bị. Hồ sơ này do quản trị viên sở hữu, trao cho quản trị viên quyền kiểm soát hồ sơ được quản lý trong khi vẫn để hồ sơ cá nhân và không gian lưu trữ của người dùng kiểm soát. Thay đổi này có thể ảnh hưởng đến hành vi của ứng dụng hiện có theo những cách sau.

Xử lý ý định

Quản trị viên thiết bị có thể hạn chế quyền truy cập vào các ứng dụng hệ thống từ hồ sơ được quản lý. Trong trường hợp này, nếu một ứng dụng kích hoạt một ý định từ hồ sơ được quản lý mà ứng dụng đó thường xử lý và không có trình xử lý phù hợp nào cho ý định trên hồ sơ được quản lý, thì ý định đó sẽ gây ra ngoại lệ. Ví dụ: quản trị viên thiết bị có thể hạn chế các ứng dụng trên hồ sơ được quản lý truy cập vào ứng dụng máy ảnh của hệ thống. Nếu ứng dụng của bạn đang chạy trên hồ sơ được quản lý và gọi startActivityForResult() cho MediaStore.ACTION_IMAGE_CAPTURE, đồng thời không có ứng dụng nào trên hồ sơ được quản lý có thể xử lý ý định, thì điều này sẽ dẫn đến ActivityNotFoundException.

Bạn có thể ngăn chặn điều này bằng cách kiểm tra để đảm bảo rằng có ít nhất một trình xử lý cho bất kỳ ý định nào trước khi kích hoạt ý định đó. Để kiểm tra xem có trình xử lý hợp lệ hay không, hãy gọi Intent.resolveActivity(). Bạn có thể xem ví dụ về cách thực hiện việc này trong bài viết Chụp ảnh đơn giản: Chụp ảnh bằng ứng dụng máy ảnh.

Chia sẻ tệp giữa các hồ sơ

Mỗi hồ sơ có bộ nhớ tệp riêng. Vì một URI tệp tham chiếu đến một vị trí cụ thể trong bộ nhớ tệp, nên điều này có nghĩa là một URI tệp hợp lệ trên một hồ sơ thì không hợp lệ trên hồ sơ còn lại. Đây không phải là vấn đề thường thấy đối với một ứng dụng, vì ứng dụng thường chỉ truy cập vào các tệp mà ứng dụng tạo ra. Tuy nhiên, nếu một ứng dụng đính kèm tệp vào một ý định, thì việc đính kèm URI tệp sẽ không an toàn vì trong một số trường hợp, ý định đó có thể được xử lý trên hồ sơ khác. Ví dụ: quản trị viên thiết bị có thể chỉ định rằng ứng dụng máy ảnh trên hồ sơ cá nhân sẽ xử lý các sự kiện chụp ảnh. Nếu ý định được một ứng dụng trên hồ sơ được quản lý kích hoạt, thì máy ảnh cần có khả năng ghi hình ảnh vào vị trí mà các ứng dụng trong hồ sơ được quản lý có thể đọc hình ảnh đó.

Để an toàn, khi cần đính kèm tệp vào một ý định có thể chuyển từ hồ sơ này sang hồ sơ khác, bạn nên tạo và sử dụng URI nội dung cho tệp. Để biết thêm thông tin về cách chia sẻ tệp bằng URI nội dung, hãy xem bài viết Chia sẻ tệp. Ví dụ: quản trị viên thiết bị có thể cho phép máy ảnh trong hồ sơ cá nhân xử lý ACTION_IMAGE_CAPTURE. EXTRA_OUTPUT của ý định kích hoạt phải chứa URI nội dung chỉ định nơi lưu trữ ảnh. Ứng dụng máy ảnh có thể ghi hình ảnh vào vị trí do URI đó chỉ định và ứng dụng kích hoạt ý định có thể đọc tệp đó, ngay cả khi ứng dụng nằm trên hồ sơ khác.

Đã ngừng hỗ trợ tiện ích trên màn hình khoá

Android 5.0 sẽ loại bỏ tính năng hỗ trợ các tiện ích trên màn hình khoá nhưng vẫn tiếp tục hỗ trợ các tiện ích trên màn hình chính.