Đã đăng vào thg 5 25, 2017 7:49 SA 30 phút đọc

599

Giới thiệu một số tính năng mới trong Android O (Phần II)

Bài đăng này đã không được cập nhật trong 6 năm

Tiếp theo phần I (https://viblo.asia/vu.viet.anh/posts/XL6lAY7rlek). Bài viết này nêu bật những tính năng mới cho các nhà phát triển trên android O.

Tự động hoá TextView

Android O cho phép bạn đặt kích thước văn bản mở rộng hoặc hợp đồng tự động dựa trên kích thước của TextView. Điều này có nghĩa là sẽ dễ dàng hơn để tối ưu hóa kích thước văn bản trên các màn hình khác nhau hoặc với nội dung động. Để biết thêm thông tin, về tự động hoá TextView trong Android O, hãy xem Autosizing TextView.

Gán các phím tắt và tiện ích con

Android O giới thiệu việc ghim nhanh các phím tắt và tiện ích con trong ứng dụng. Trong ứng dụng của bạn, bạn có thể tạo các lối tắt và các widget đã được ghim cho các trình khởi chạy được hỗ trợ, tùy thuộc sự cho phép của người dùng.

Để biết thêm thông tin, hãy xem hướng dẫn Phím tắt.

Tỷ lệ co màn hình tối đa

Các ứng dụng với target version Android 7.1 (API 25) trở xuống có tỷ lệ khung hình màn hình tối đa mặc định là 1,86. Các ứng dụng hướng tới Android O trở lên không có tỷ lệ khung hình tối đa mặc định. Nếu ứng dụng của bạn cần đặt tỷ lệ khung hình tối đa, hãy sử dụng thuộc tính maxAspectRatio trong manifest Activity của bạn.

Hỗ trợ đa hiển thị

Bắt đầu với Android O, nền tảng này cung cấp hỗ trợ nâng cao cho nhiều màn hình. Nếu một Activity hỗ trợ chế độ đa cửa sổ và đang chạy trên thiết bị có nhiều màn hình, người dùng có thể di chuyển Activity từ màn hình này sang màn hình khác. Khi ứng dụng khởi chạy một Activity, ứng dụng có thể chỉ định hiển thị Activity nào sẽ chạy.

Lưu ý: Nếu Activity hỗ trợ chế độ đa cửa sổ, Android O sẽ tự động bật hỗ trợ đa hiển thị cho Activity đó. Bạn nên thử nghiệm ứng dụng của mình để đảm bảo ứng dụng hoạt động tốt trong môi trường đa hiển thị.

Chỉ một Activity tại một thời điểm có thể ở trạng thái đã được resume, ngay cả khi ứng dụng có nhiều màn hình. Activity được focus sẽ ở trạng thái resume; Tất cả các Activity khác có thể nhìn thấy sẽ ở trạng thái pause, nhưng không phải là stop. Để biết thêm thông tin về vòng đời hoạt động khi một số Activity có thể nhìn thấy được, hãy xem Multi-Window Lifecycle.

Khi người dùng di chuyển một Activity từ màn hình này sang màn hình khác, hệ thống sẽ thay đổi kích thước Activity và đưa ra những thay đổi khi cần thiết. Activity của bạn có thể tự quản lý thay đổi cấu hình hoặc nó có thể cho phép hệ thống destroy Activity của bạn và recreate nó với các kích thước mới. Để biết thêm thông tin, xem Xử lý Thay đổi Cấu hình.

ActivityOptions cung cấp hai phương thức mới để hỗ trợ nhiều màn hình:

setLaunchDisplayId() Chỉ định hiển thị Activity khi nó được khởi chạy. getLaunchDisplayId() Trả lại hiển thị khởi chạy hiện tại của Activity. Adb shell được mở rộng để hỗ trợ nhiều màn hình. Lệnh shell start bây giờ có thể được sử dụng để khởi động một Activity, và để xác định đối tượng hiển thị của Activity:


 Adb shell start <activity_name> --display <display_id>

Margin và padding bố trí hợp lý

Android O giúp bạn dễ dàng hơn trong việc chỉ định các tình huống mà các mặt đối diện của một phần tử View sử dụng cùng margin hoặc padding. Cụ thể, bây giờ bạn có thể sử dụng các thuộc tính sau trong XML layout của bạn:

[layout_marginVertical](https://developer.android.com/reference/android/R.attr.html?hl=vi#layout_marginVertical), trong đó xác định *layoutmarginTop* và *layoutmarginBottom* cùng một lúc.
[layout_marginHorizontal](https://developer.android.com/reference/android/R.attr.html?hl=vi#layout_marginHorizontal), trong đó xác định *layoutmarginLeft* và *layoutmarginRight* cùng một lúc.
[paddingVertical](https://developer.android.com/reference/android/R.attr.html?hl=vi#paddingVertical), xác định *paddingTop* và *paddingBottom* cùng một lúc.
[paddingHorizontal](https://developer.android.com/reference/android/R.attr.html?hl=vi#paddingHorizontal), xác định *paddingLeft* và *paddingRight* cùng một lúc.

Lưu ý: Nếu bạn tùy chỉnh logic của ứng dụng để hỗ trợ các ngôn ngữ và nền văn hoá khác nhau , bao gồm cả hướng văn bản, hãy lưu ý rằng các thuộc tính này không ảnh hưởng đến các giá trị của layoutmarginStart , layoutmarginEnd , paddingStart , hoặc paddingEnd . Bạn có thể đặt các giá trị này cho mình, ngoài các thuộc tính bố trí theo chiều dọc và chiều ngang mới, để tạo hành vi bố trí phụ thuộc vào hướng văn bản.

Pointer capture

Một số ứng dụng, chẳng hạn như trò chơi, remote desktop và máy ảo hóa, có nhiều lợi ích từ việc kiểm soát con trỏ chuột. Pointer capture là một tính năng mới trong Android O cung cấp sự kiểm soát như vậy bằng cách phân phối tất cả sự kiện chuột đến View đang được focus trong ứng dụng của bạn.

Bắt đầu trong Android O, View trong ứng dụng của bạn có thể yêu cầu Pointer capture và xác định listener để xử lý các sự kiện con trỏ đã nắm bắt. Con trỏ chuột được ẩn trong chế độ này. View có thể giải phóng Pointer capture khi nó không cần thông tin chuột nữa. Hệ thống cũng có thể giải phóng Pointer capture khi View mất focus, ví dụ như khi người dùng mở một ứng dụng khác.

Để biết thông tin về cách sử dụng tính năng này trong ứng dụng của bạn, hãy xem Pointer capture.

Danh mục ứng dụng

Android O cho phép mỗi ứng dụng khai báo một danh mục phù hợp với nó, khi có liên quan. Các danh mục này được sử dụng để nhóm lại các ứng dụng có cùng mục đích hoặc chức năng khi hiển thị cho người dùng, chẳng hạn như Cách sử dụng dữ liệu, Sử dụng pin hoặc Sử dụng bộ nhớ. Bạn có thể xác định danh mục cho ứng dụng của mình bằng cách đặt thuộc tính android:appCategory trong <application> của bạn.

Trình chạy Android TV

Android O cung cấp trải nghiệm màn hình chính Android mới dành cho nội dung dành cho Android TV và hình ảnh thiết bị Nexus Player dành cho Android O. Màn hình chính mới tổ chức nội dung video theo hàng tương ứng với các kênh, mỗi kênh đều được populated bằng một ứng dụng trên hệ thống. Ứng dụng có thể xuất bản trên nhiều kênh và người dùng có thể định cấu hình các kênh mà họ muốn xem trên màn hình chính. Màn hình chủ của Android TV cũng bao gồm hàng Watch Next, được populated với các chương trình từ ứng dụng, dựa trên thói quen xem của người dùng. Ứng dụng cũng có thể cung cấp chế độ xem trước bằng video, và sẽ được phát tự động khi người dùng focus vào một chương trình. Các API dành cho việc populate các kênh và chương trình là một phần của các API TvProvider, được phân phối dưới dạng module của Android Support Library.

AnimatorSet

Bắt đầu trong Android O, API AnimatorSet hỗ trợ seeking và đảo ngược. Seeking cho phép bạn đặt vị trí của animation tại một thời điểm cụ thể. Đảo ngược sẽ rất hữu ích nếu ứng dụng của bạn bao gồm animation có thể hoàn tác. Thay vì xác định hai animation riêng biệt, bạn có thể dùng một animation và đảo ngược lại.

StrictMode Detector mới

Android O thêm StrictMode Detector mới để giúp xác định các lỗi tiềm ẩn trong ứng dụng của bạn:

detectUnbufferedIo() sẽ phát hiện khi ứng dụng của bạn đọc hoặc ghi dữ liệu mà không có bộ đệm, có thể ảnh hưởng mạnh đến hiệu suất.
detectContentUriWithoutPermission() sẽ phát hiện khi ứng dụng của bạn vô tình quên cấp quyền cho một ứng dụng khác khi bắt đầu Activity bên ngoài ứng dụng của bạn.
detectUntaggedSockets() sẽ phát hiện khi ứng dụng của bạn thực hiện lưu lượng truy cập mạng mà không sử dụng setThreadStatsTag(int) để gắn thẻ lưu lượng truy cập của bạn cho các mục đích gỡ lỗi.

Dữ liệu đã lưu trong bộ nhớ cache

Android O cung cấp hướng dẫn và hành vi tốt hơn xung quanh dữ liệu lưu trữ. Mỗi ứng dụng bây giờ được cấp một hạn ngạch không gian đĩa cho dữ liệu lưu trữ, được trả về bởi getCacheQuotaBytes(UUID).

Khi hệ thống cần giải phóng không gian đĩa, nó sẽ bắt đầu bằng cách xóa các tệp lưu trữ trong bộ nhớ cache khỏi các ứng dụng sử dụng quá hạn ngạch được phân bổ nhiều nhất. Do đó, nếu bạn giữ dữ liệu được lưu trữ theo hạn ngạch được phân bổ của bạn, tệp lưu trữ của bạn sẽ là một trong số cuối cùng của hệ thống sẽ bị xóa khi cần thiết. Khi hệ thống quyết định những tệp nào đã lưu trong bộ nhớ cache bên trong ứng dụng của bạn, nó sẽ xem xét các tệp tin cũ nhất trước tiên (được xác định bằng thời gian đã sửa đổi).

Ngoài ra còn có hai hành vi mới mà bạn có thể kích hoạt trên cơ sở mỗi thư mục để kiểm soát cách hệ thống giải phóng dữ liệu lưu trữ của bạn:

StorageManager.setCacheBehaviorAtomic() có thể được sử dụng để chỉ ra rằng một thư mục và tất cả các nội dung của nó phải được xóa như một đơn vị nguyên tử.
setCacheBehaviorTombstone(File, boolean) có thể được sử dụng để chỉ ra rằng thay vì xóa các tập tin trong một thư mục, chúng nên được cắt ngắn là 0 byte chiều dài, để lại các tập tin rỗng. Cuối cùng, khi bạn cần phân bổ không gian đĩa cho các tệp lớn, hãy cân nhắc sử dụng hàm allocateBytes(FileDescriptor, long, int) mới, sẽ tự động xóa các tệp được lưu trong bộ nhớ cache thuộc các ứng dụng khác (nếu cần) để đáp ứng yêu cầu của bạn. Khi quyết định nếu thiết bị có đủ không gian đĩa để giữ dữ liệu mới của bạn, hãy gọi getAllocatableBytes(UUID, int) thay vì sử dụng getUsableSpace(), vì hàm cũ (getUsableSpace()) sẽ xem xét bất kỳ dữ liệu lưu trữ nào mà hệ thống sẵn sàng để clear thay cho bạn.

Content provider paging

Google đã cập nhật Content provider để hỗ trợ để tải một tập dữ liệu lớn một trang một lần. Ví dụ: một ứng dụng ảnh có hàng ngàn hình ảnh có thể truy vấn một tập con của dữ liệu để hiện diện trong một trang. Mỗi trang kết quả trả về bởi một Content provider được đại diện bởi một đối tượng Cursor đơn. Cả client và provider đều phải thực hiện phân trang để sử dụng tính năng này.

Để biết thông tin chi tiết về các thay đổi, xem ContentProvider và ContentProviderClient .

Content refresh requests

Các ContentProvider và ContentResolver bây giờ đều bao gồm phương thức refresh(), giúp client dễ dàng biết được liệu thông tin họ yêu cầu có được cập nhật hay không.

Bạn có thể thêm logic làm mới nội dung tùy chỉnh bằng cách extends ContentProvider. Đảm bảo rằng bạn ghi đè phương thức refresh() để r true , cho biết các khách hàng của nhà cung cấp của bạn rằng bạn đã cố gắng tự làm mới dữ liệu.

Ứng dụng client của bạn có thể yêu cầu nội dung được refresh bằng cách gọi một phương thức khác, cũng gọi là refresh() . Khi gọi phương pháp này, hãy truyền vào URI của dữ liệu để làm mới.

Lưu ý: Bởi vì bạn có thể yêu cầu dữ liệu qua mạng nên bạn nên gọi refresh() từ phía client chỉ khi có dấu hiệu rằng nội dung đã cũ. Lý do phổ biến nhất để thực hiện loại làm mới nội dung này là đáp ứng với swipe-to-refresh, yêu cầu giao diện hiện tại hiển thị nội dung đã được cập nhật.

Cải tiến JobScheduler

Android O giới thiệu một số cải tiến cho JobScheduler . Những cải tiến này làm cho ứng dụng của bạn tuân thủ các giới hạn chạy nền mới đơn giản hơn vì bạn có thể sử dụng các công việc được lên lịch để thay thế cho các background service hiện bị giới hạn hoặc broadcast receiver.

Cập nhật cho JobScheduler bao gồm:

Bây giờ bạn có thể liên kết một hàng đợi công việc với một công việc theo lịch trình. Để thêm một mục công việc vào hàng đợi của công việc, hãy gọi JobScheduler.enqueue() . Khi công việc đang chạy, nó có thể kéo công việc đang chờ giải quyết ra khỏi hàng đợi và xử lý nó. Chức năng này xử lý nhiều trường hợp sử dụng mà trước đây thường dùng một background service, đặc biệt là service IntentService .
Bây giờ bạn có thể gọi JobInfo.Builder.setClipData() để kết hợp một ClipData với một công việc. Tuỳ chọn này cho phép bạn liên kết URI cấp permission với một công việc, tương tự như cách các quyền này có thể được chuyển sang Context.startService() . Bạn cũng có thể sử dụng URI cấp permission với Intent trên các hàng đợi công việc.
Các công việc theo lịch trình giờ đây hỗ trợ nhiều constraint mới:

JobInfo.isRequireStorageNotLow() Job không chạy nếu bộ nhớ có sẵn của thiết bị là thấp.

JobInfo.isRequireBatteryNotLow() Job không chạy nếu mức pin bằng hoặc thấp hơn ngưỡng giới hạn; Đây là mức mà thiết bị hiển thị hộp thoại hệ thống cảnh báo pin thấp .

NETWORK_TYPE_METERED Job yêu cầu một kết nối mạng lưới, giống như hầu hết các kế hoạch dữ liệu di động.

Lưu trữ dữ liệu tùy chỉnh

Android O cho phép bạn cung cấp lưu trữ dữ liệu tùy chỉnh cho tùy chọn của bạn, có thể hữu ích nếu ứng dụng của bạn lưu trữ các tùy chọn trong một cơ sở dữ liệu đám mây hoặc cơ sở dữ liệu cục bộ hoặc nếu sở thích là dành riêng cho thiết bị. Để biết thêm thông tin về việc triển khai kho dữ liệu, hãy tham khảo Custom Data Store.

Thay đổi chữ ký findViewById ()

Tất cả các thể hiện của phương thức findViewById() bây giờ return <T extends View> T thay vì View . Sự thay đổi này có các hàm ý sau:

Điều này có thể dẫn đến code hiện tại có kiểu trả về mơ hồ, ví dụ nếu cả hai phương thức someMethod(View) và someMethod(TextView) lấy kết quả của một cuộc gọi đến findViewById() .
Khi sử dụng ngôn ngữ nguồn Java 8, điều này đòi hỏi một casting rõ ràng cho View khi kiểu trả về là không bị giới hạn (ví dụ, assertNotNull(findViewById(...)).someViewMethod()) .
Ghi đè các phương thức không phải là final của findViewById() (ví dụ: Activity.findViewById() ) sẽ cần cập nhật kiểu trả về của chúng.

Cải tiến Media

VolumeShaper

Có một lớp VolumeShaper mới. Bạn có thể sử dụng nó để thực hiện quá trình chuyển đổi âm lượng tự động ngắn như mờ dần, mờ nhạt, và biến mất qua.

Nâng cao focus Âm thanh

Các ứng dụng âm thanh chia sẻ đầu ra âm thanh trên thiết bị bằng cách yêu cầu và bỏ focus âm thanh. Một ứng dụng xử lý sự thay đổi focus bằng cách bắt đầu hoặc dừng phát lại hoặc giảm âm lượng của nó. Có một lớp AudioFocusRequest mới. Với lớp này, ứng dụng có khả năng mới khi xử lý các thay đổi trong focus âm thanh: tự động giảm và tăng độ trì hoãn focus.

Media metrics

Một phương thức getMetrics() mới trả về một đối tượng PersistableBundle có chứa thông tin về cấu hình và hiệu năng, thể hiện dưới dạng một map thuộc tính và giá trị. Phương thức getMetrics() được định nghĩa cho các lớp media này:

MediaPlayer.getMetrics()
MediaRecorder.getMetrics()
MediaCodec.getMetrics()
MediaExtractor.getMetrics()

Các chỉ số được thu thập riêng rẽ cho từng trường hợp và tồn tại suốt đời của thực thể. Nếu không có số liệu có sẵn phương thức trả về null. Các chỉ số thực tế trả lại phụ thuộc vào lớp.

Media Player

Android O bổ sung thêm một số phương thức mới cho lớp MediaPlayer. Các phương thức này có thể cải thiện xử lý playback media của ứng dụng bằng nhiều cách:

Fine-grained khi seeking frame.
Khả năng chơi media được bảo vệ bởi DRM.

MediaRecorder

MediaRecorder hiện hỗ trợ định dạng MPEG2_TS hữu ích cho việc phát trực tuyến:

MMediaRecorder.setOutputFormat (MediaRecorder.OutputFormat.MPEG_2_TS);

Xem thêm MediaRecorder.OutputFormat

MediaMuxer bây giờ có thể xử lý bất kỳ số lượng dòng âm thanh và video. Bạn không còn bị giới hạn ở một bản âm thanh và / hoặc một video. Sử dụng addTrack() để trộn nhiều bài hát theo ý muốn.
MediaMuxer cũng có thể thêm một hoặc nhiều metadata chứa thông tin mỗi frame do người dùng định nghĩa. Định dạng của metadata được định nghĩa bởi ứng dụng của bạn. Tuyến metadata chỉ được hỗ trợ cho các vùng chứa MP4. Metadata có thể hữu ích cho việc xử lý ngoại tuyến. Ví dụ, tín hiệu con quay hồi chuyển từ cảm biến có thể được sử dụng để thực hiện ổn định video.

Khi thêm metadata, định dạng mime của metadata phải bắt đầu bằng tiền tố "application /". Ghi metadata cũng giống như ghi dữ liệu video / âm thanh ngoại trừ dữ liệu không đến từ một MediaCodec . Thay vào đó, ứng dụng truyền một ByteBuffer với mốc thời gian vào phương thức writeSampleData(). Mốc thời gian phải ở cùng một khoảng thời gian với các bài hát video và âm thanh.

Tệp MP4 được tạo ra sử dụng TextMetaDataSampleEntry được định nghĩa trong phần 12.3.3.2 của ISOBMFF để báo hiệu định dạng mime của metadata. Khi sử dụng MediaExtractor để giải nén tệp tin với metadata, định dạng mime của metadata sẽ được trích xuất vào MediaFormat .

Kiểm soát phát lại âm thanh

Android O cho phép bạn truy vấn và yêu cầu thiết bị xuất âm thanh như thế nào. Các khía cạnh sau về kiểm soát phát lại âm thanh làm cho dịch vụ của bạn dễ dàng hơn để sản xuất âm thanh chỉ trong điều kiện thiết bị thuận lợi.

Loại sử dụng âm thanh mới cho Google Assistant Lớp AudioAttributes chứa một loại âm thanh mới, USAGE_ASSISTANT , tương ứng với các câu trả lời mà Google Assistant nói trên thiết bị.

Thay đổi thiết bị phát lại âm thanh Nếu bạn muốn service của mình bắt đầu xuất âm thanh chỉ khi cấu hình âm thanh thiết bị cụ thể đang hoạt động, bạn có thể sử dụng lớp AudioManager để đăng ký một thực thể của AudioManager.AudioPlaybackCallback , phương thức onPlaybackConfigChanged() giúp bạn xác định tập hợp các thuộc tính âm thanh hiện đang hoạt động .

Yêu cầu rõ ràng về focus âm thanh Service của bạn có thể gửi một yêu cầu tinh vi hơn để nhận focus âm thanh toàn bộ thiết bị bằng cách sử dụng phương thức requestAudioFocus() . Truyền vào một đối tượng AudioFocusRequest , mà bạn tạo ra bằng AudioFocusRequest.Builder . Trong lớp này, bạn có thể chỉ định các tuỳ chọn sau:

Loại focus bạn muốn đạt được, chẳng hạn như AUDIOFOCUS_GAIN_TRANSIENT hoặc AUDIOFOCUS_GAIN_TRANSIENT_MAY_DUCK .
Service của bạn nên tiếp tục phát với âm lượng nhỏ hơn hoặc tạm dừng hoàn toàn khi Service âm thanh khác lấy focus âm thanh.
Service của bạn có thể chờ đợi để lấy focus cho đến khi thiết bị đã sẵn sàng. Lưu ý: Khi xây dựng trường hợp của AudioFocusRequest , nếu bạn cho biết rằng Service của bạn có thể chờ đợi để tạo ra âm thanh bằng cách gọi setAcceptsDelayedFocusGain() , bạn cũng phải gọi setOnAudioFocusChangeListener() để Service của bạn biết khi nào nó có thể bắt đầu xuất âm thanh.

Cải thiện truy cập media file

Storage Access Framework (SAF) cho phép ứng dụng expose một DocumentsProvider tùy chỉnh, mà có thể cung cấp quyền truy cập vào các tệp trong nguồn dữ liệu cho các ứng dụng khác. Trên thực tế, một documents provider thậm chí có thể cung cấp quyền truy cập vào các tệp tin lưu trữ trên mạng hoặc sử dụng một giao thức như Giao thức truyền dữ liệu (MTP) .

Tuy nhiên, việc truy cập các tệp media lớn từ nguồn dữ liệu từ xa đưa đến một số thách thức:

MediaPlayer cần truy cập có thể tìm kiếm vào tệp từ documents provider. Trong trường hợp tệp media lớn nằm trên nguồn dữ liệu từ xa, documents provider phải lấy tất cả dữ liệu trước và tạo snapshot cho tệp. Trình phát media không thể phát tệp mà không có trình mô tả tập tin, do đó không thể bắt đầu play cho đến khi documents provider hoàn tất tải xuống tệp.
Media collection managers, chẳng hạn như ứng dụng ảnh, phải truy cập một loạt các URI để tiếp cận các file media được lưu trữ trên thẻ SD bên ngoài thông qua các thư mục scoped. Cách truy cập này làm cho các xử lý trên media như move, copy và delete - khá chậm.
Media collection managers không thể xác định vị trí của document với URI. Điều này làm cho các loại ứng dụng này gặp khó khăn trong việc cho phép người dùng chọn nơi lưu tệp media. Android O giải quyết từng sự cố bằng cách cải tiến Storage Access Framework

Document providers tùy chỉnh Bắt đầu trong Android O, Storage Access Framework cho phép các Document providers tùy chỉnh tạo các trình mô tả tập tin tìm kiếm cho các tệp nằm trong nguồn dữ liệu từ xa. SAF có thể mở một tệp để có được một trình mô tả tập tin có thể tìm kiếm được. SAF sau đó cung cấp các yêu cầu bytes rời rạc đến Document providers. Tính năng này cho phép Document providers trả lại đúng dãy byte mà ứng dụng trình phát media đã yêu cầu thay vì lưu trữ toàn bộ tệp tin trước.

Để sử dụng tính năng này, bạn cần phải gọi phương thức StorageManager.openProxyFileDescriptor() . Phương thức openProxyFileDescriptor() chấp nhận một đối tượng ProxyFileDescriptorCallback như một callback. SAF gọi đến callback bất cứ lúc nào ứng dụng client thực hiện các thao tác tập tin trên bộ mô tả tập tin được trả lại từ nhà cung cấp Document providers.

Truy cập document trực tiếp Đối với Android O, bạn có thể sử dụng phương thức getDocumentUri() để lấy một URI tham chiếu đến cùng một document với mediaUri đã cho. Tuy nhiên, vì URI đã trả lại được hỗ trợ bởi một DocumentsProvider , các Document providers có thể truy cập tài liệu trực tiếp, mà không cần phải đi qua các cây của các thư mục có phạm vi. Kết quả là, các Document providers có thể thực hiện các hoạt động tập tin trên tài liệu nhanh hơn đáng kể.

Chú ý: Phương thức getDocumentUri() chỉ định vị các tệp media; Nó không cấp phép cho ứng dụng để truy cập các tập tin đó. Để tìm hiểu thêm về làm thế nào để có được quyền truy cập vào các tập tin media, hãy xem tài liệu tham khảo.

Đường dẫn tới document Khi sử dụng SAF trong Android O, bạn có thể sử dụng phương thức findDocumentPath() sẵn trong cả hai lớp DocumentsContract và DocumentsProvider để xác định đường dẫn từ gốc của hệ thống tệp tin được cung cấp ID của document. Phương thức trả về đường dẫn này trong một đối tượng DocumentsContract.Path. Trong trường hợp hệ thống tệp tin có nhiều đường dẫn xác định đến cùng một document, phương thức trả về đường dẫn được sử dụng thường xuyên nhất để tiếp cận document với ID nhất định.

Chức năng này đặc biệt hữu ích trong các tình huống sau:

Ứng dụng của bạn sử dụng hộp thoại "Save as" hiển thị vị trí của một document cụ thể.
Ứng dụng của bạn hiển thị các thư mục trong chế độ xem kết quả tìm kiếm và phải tải các document con nằm trong một thư mục cụ thể nếu người dùng chọn thư mục đó. Lưu ý: Nếu ứng dụng của bạn có quyền truy cập chỉ một số tài liệu trong đường dẫn, giá trị trả về findDocumentPath() chỉ bao gồm các thư mục và tài liệu mà ứng dụng của bạn có thể truy cập.

(Còn tiếp) (Lược dịch từ https://developer.android.com/preview/api-overview.html?hl=vi)