Trang này được dịch bởi Cloud Translation API.

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à chức năng mới, Android 5.0 có nhiều thay đổi về hệ thống 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 cần hiểu và tính đến trong ứng dụng của mình.

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

Để xem thông tin tổng quan về các tính năng mới của nền tảng, hãy xem bài viết Tính năng 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, môi trường thời gian chạy ART thay thế Dalvik làm môi trường mặc định của nền tảng. Môi trường thời gian chạy ART được giới thiệu 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 bài viết Giới thiệu về ART. Sau đây là một số tính năng mới chính:

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

Hầu hết ứng dụng Android sẽ hoạt động mà không cần thay đổi gì trong 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 bài viết Xác minh hành vi của ứng dụng trên Android Runtime (ART). Hãy đặc biệt chú ý nếu:

Ứng dụng của bạn sử 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 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 thu gom rác.

Thông báo

Hãy đảm bảo thông báo của bạn 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 Material Design

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

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ập nhật hoặc xoá những thành phần có liên quan đến màu sắc. Hệ thống bỏ qua tất cả các kênh không phải alpha trong biểu tượng thao tác 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ó alpha. Hệ thống vẽ biểu tượng thông báo màu trắng và biểu tượng thao tác màu xám đậm.

Âm thanh và rung

Nếu bạn đang thêm âm thanh và độ rung vào thông báo bằng cách sử 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 sử 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ẽ rời khỏi chế độ ưu tiên nếu bạn đặt chế độ này 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 khiển âm lượng trên các thiết bị máy tính bảng. Trong 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à được điều khiển bằng STREAM_RING hoặc STREAM_NOTIFICATION.

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

Theo mặc định, thông báo hiện xuất hiện trên màn hình khoá 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 này, hệ thống sẽ tự động loại bỏ văn bản mà thông báo hiển thị. Để tùy chỉnh thông báo đã loại bỏ nội dung 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 cấp độ hiển thị của thông báo thành VISIBILITY_PUBLIC.

Phát lại phương tiện

Nếu bạn đang triển khai thông báo hiển thị trạng thái phát nội dung nghe nhìn hoặc các chế độ đ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 không còn 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 (tức là thiết bị đã mở khoá và màn hình đang bật). Những thông báo này xuất hiện tương tự như dạng thông báo thu gọn, ngoại trừ 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ể thực hiện hành động hoặc đóng 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 điều kiện có thể kích hoạt thông báo quan trọng:

Hoạt động của người dùng hiện ở 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 chế độ rung

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

Điều khiển nội dung nghe nhìn và RemoteControlClient

Lớp RemoteControlClient hiện không dùng nữa. 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 thông báo. Điều này giúp ứng dụng của bạn kiểm soát nhiều hơn việc hiển thị các nút phát nội dung nghe nhì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à chưa khoá.

Android 5.0 giới thiệu một mẫu Notification.MediaStyle mới cho mục đích này. Notification.MediaStyle chuyển đổi các thao tác thông báo mà bạn đã thêm bằng Notification.Builder.addAction() thành các nút thu 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 đến phương thức setSession() để thông báo cho hệ thống rằng thông báo này điều khiển 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 không bảo mật). Để 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ị các nút điều khiển 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 TV hoặc Wear của Android, 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 nội dung nghe nhìn trên thiết bị Android.

getRecentTasks()

Với việc ra mắt tính năng tài liệu và hoạt động đồng thời mới trong Android 5.0 (xem 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 nữa để cải thiện quyền riêng tư của người dùng. Để tương thích ngược, phương thức này vẫn trả về một tập hợp con nhỏ của 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ư Home). 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 riêng ứ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 ra mắt tính năng hỗ trợ cho các hệ thống 64 bit. Tính năng nâng cao 64 bit tăng không gian địa chỉ và cải thiện hiệu suất, đồng thời 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 cho hoạt động mã hoá. Ngoài ra, bản phát hành này còn giới thiệu các API NDK đa phương tiện gốc mới, cũng như hỗ trợ OpenGL ES (GLES) 3.1 gốc.

Để sử dụng tính năng hỗ trợ 64 bit được cung cấp trong Android 5.0, hãy tải xuống và cài đặt Bản sửa đổi 10c của NDK từ 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ề các thay đổi quan trọng và bản sửa lỗi cho 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à sẽ gửi một ngoại lệ nếu được cung cấp một ý định ngầm ẩn. Để đảm bảo ứng dụng của bạn an toàn, hãy sử dụng một ý định rõ ràng 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 cho ứng dụng của bạn.

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 sử 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 hiển thị 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, đồng thời 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 duy nhấ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 tiện 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.

Có một số ít trường hợp mà việc xác định quyền tuỳ chỉnh là một phương pháp hợp lệ và an toàn. Tuy nhiên, đôi khi việc tạo quyền tuỳ chỉnh là không cần thiết và thậm chí có thể gây ra rủi ro tiềm ẩn cho ứng dụng, tuỳ thuộc vào mức độ 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ừ khi đượ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 sử dụng quyền tuỳ chỉnh trùng lặp

Mọi ứng dụng đều có thể xác định quyền tuỳ chỉnh bất kỳ mà ứng dụng đó 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 cung cấp một chức năng tương tự, 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 của chúng. Ứng dụng cũng có thể kết hợp các thư viện công khai phổ biến hoặc ví dụ về mã có chứa cùng một định nghĩa quyền tuỳ chỉnh.

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 cài đặt đầu tiên chỉ định.

Kể từ Android 5.0, hệ thống sẽ thực thi một hạn chế về tính duy nhất đối với các quyền tuỳ chỉnh mới cho các ứ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ị mới có thể xác định một quyền tuỳ chỉnh nhất định (do tên ứng dụng xác định), 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 quá trình cài đặt.

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

Trong 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 của riêng mình 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 giới thiệu trong Android 5.0, bạn nên đánh giá kỹ lưỡng những tác động có thể có đối với ứng dụng của mình.

Sau đây là một số điểm cần cân nhắc:

Ứ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ó, liệu các quyền đó 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 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ã ví dụ 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 các cụm từ phổ biến mà các ứng dụng khác có thể dùng chung không?

Số lượt cài đặt và cập nhật mới

Như đã đề cập ở trên, các lượt cài đặt và cập nhật mới của ứng dụng 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 và cập nhật mới trên thiết bị chạy Android 5.0 trở lên, hệ thống sẽ ngăn cài đặt ứng dụng của bạn nếu ứng dụng đó xác định một quyền tuỳ chỉnh đã được xác định bởi một ứng dụng thường trú hiện có.

Các lượt cài đặt hiện có có 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 và 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 các quyền tuỳ chỉnh của ứng dụng. Nếu ứng dụng của bạn xác định một quyền tuỳ chỉnh đã được xác định bởi một ứng dụng khác đã được xác thực và ứng dụng của bạn không được ký bằng cùng một khoá với ứ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, điều chỉnh mọi thứ cần thiết và phát hành phiên bản cập nhật cho người dùng sớm nhất có thể.

Nếu bạn đang sử dụng các quyền tuỳ chỉnh trong ứng dụng, hãy cân nhắc nguồn gốc của các quyền đó và liệu bạn có thực sự cần các quyền đó hay không. Xoá tất cả phần tử <permission> khỏi ứng dụng, trừ phi bạn chắc chắn rằng các phần tử đó là cần thiết để ứng dụng hoạt động đúng cách.
Hãy cân nhắc thay thế các quyền tuỳ chỉnh bằng các quyền mặc định của hệ thống nếu có thể.
Nếu ứng dụng của bạn yêu cầu quyền tuỳ chỉnh, hãy đổi tên quyền tuỳ chỉnh để chỉ ứng dụng của bạn mới có quyền đó, chẳng hạn như bằng cách thêm 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 một(các) quyền tuỳ chỉnh nếu cần thiết – hệ thống cho phép cài đặt các ứng dụng theo cách thông thường.

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

Android 5.0 giới thiệu 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:

Các giao thức TLSv1.2 và TLSv1.1 hiện đã được bật,
Bộ thuật toán mật mã AES-GCM (AEAD) hiện đã được bật,
Bộ thuật toán mật mã MD5, 3DES, xuất và ECDH khoá tĩnh hiện đã bị tắt,
Bạn nên sử dụng 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ể dẫn đến sự cố 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 bảo mật từ Dịch vụ Google Play đã cung cấp các thay đổi này trên các phiên bản nền tảng Android trở về Android 2.3.

Máy chủ không hỗ trợ bất kỳ bộ 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. Giải pháp ưu tiên là cải thiện cấu hình của máy chủ để bật các giao thức và bộ 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, đồng thời bật và ưu tiên sử dụng các bộ thuật toán mật mã Forward Secrecy (ECDHE, DHE).

Một giải pháp thay thế là sửa đổi ứng dụng để sử dụng SSLSocketFactory tuỳ chỉnh nhằm giao tiếp với máy chủ. Nhà máy phải đượ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 đưa ra giả định không chính xác 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 X509TrustManager tuỳ chỉnh bị lỗi vì ứng dụng này dự kiến tham số authType là RSA nhưng gặp phải ECDHE_RSA hoặc DHE_RSA.

Máy chủ không chấp nhận TLSv1.1, TLSv1.2 hoặc các tiện ích TLS mới

Ví dụ: cơ chế bắt tay TLS/SSL với máy chủ bị từ chối do nhầm lẫn hoặc bị treo. Giải pháp ư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ủ đàm phán thành công các giao thức mới hơn này hoặc đàm phán TLSv1 hoặc các giao thức cũ hơn và bỏ qua các tiện ích TLS mà máy chủ không hiểu. Trong một số trường hợp, việc tắt TLSv1.1 và TLSv1.2 trên máy chủ có thể là 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 giải pháp thay thế là sửa đổi ứng dụng để sử dụng SSLSocketFactory tuỳ chỉnh nhằm giao tiếp với máy chủ. Nhà máy phải được thiết kế để tạo các thực thể SSLSocket chỉ bật những giao thức mà máy chủ hỗ trợ chính xác.

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 thuộc quyền sở hữu của quản trị viên, cho phép quản trị viên kiểm soát hồ sơ được quản lý trong khi vẫn để người dùng kiểm soát hồ sơ cá nhân và dung lượng lưu trữ của hồ sơ đó. 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à thường sẽ do ứng dụng đó xử lý và không có trình xử lý phù hợp 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 đ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 mọi ý định trước khi kích hoạt ý định đó. Để kiểm tra trình xử lý hợp lệ, 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 phần Chụp ảnh đơn giản: Chụp ảnh bằng ứng dụng Máy ảnh.

Chia sẻ tệp trên các hồ sơ

Mỗi hồ sơ có bộ nhớ tệp riêng. Vì 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à URI tệp hợp lệ trên một hồ sơ sẽ không hợp lệ trên hồ sơ còn lại. Thông thường, đây không phải là vấn đề đối với ứ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 một tệp vào một ý định, thì bạn không nên đính kèm URI tệp, 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 sẽ xử lý các sự kiện chụp ảnh trên hồ sơ cá nhân. 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 một vị trí mà các ứng dụng của hồ sơ được quản lý có thể đọc được.

Để đảm bảo an toàn, khi cần đính kèm một 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 phần Chia sẻ tệp. Ví dụ: quản trị viên thiết bị có thể cho phép máy ảnh xử lý ACTION_IMAGE_CAPTURE trong hồ sơ cá nhân. EXTRA_OUTPUT của ý định kích hoạt phải chứa một URI nội dung chỉ định vị trí 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 sẽ có thể đọc tệp đó, ngay cả khi ứng dụng đó đang ở hồ sơ khác.

Android 5.0 ngừng hỗ trợ tiện ích trên màn hình khoá; hệ điều hành này vẫn tiếp tục hỗ trợ các tiện ích trên màn hình chính.