Android N系列適配---FileProvider
Android 7.0的適配，主要包含方面：
- Android 7.0 主要功能的diff---介紹主要Android7.0功能以及行為變更
- Android 7.0 最重要的一環適配---FileProvider的適配
- Android 7.0 對常規三方的影響---UIL為例
Android 7.0 功能diff---詳細介紹Android7.0擁有的功能
- 多窗口支持：
- 用戶可以一次在屏幕上打開兩個應用，或者處于分屏模式時一個應用位于另一個應用之上。 用戶可以通過拖動兩個應用之間的分隔線來調整應用。
- 在 Android TV 設備上，應用可以將自身置于畫中畫模式，從而讓它們可以在用戶瀏覽或與其他應用交互時繼續顯示內容。
- 可以指定app Activity大小，防止用戶調整到該尺寸以下
- 通知增強功能：
- 模板更新
- 少量代碼調整，即可使用新的通知模版開發
- 消息樣式更新
- MessageStyle 類，可配置消息，會話標題，以及內容視圖
- 捆綁通知
- 系統可以將消息按一定規律給組合，如消息主題，用戶可以適當的進行Dismiss和Archive等操作
- 直接回復
- 即時通訊應用，支持用戶直接在通知界面中快速回復消息
- 自定義視圖
- 兩個新的 API，使用自定義視圖時可以充分利用系統裝飾元素，如通知標題和操作
- 模板更新
- Project Svelte 后臺優化：
- 刪除了三個常用隱式廣播，繼續擴展 JobScheduler 和 GCMNetworkManager
- apk signature scheme V2
- 新的應用簽名方案
- Android Studio 2.2 和 Android Gradle 2.2 插件會使用 APK
- 附上官方鏈接：
https://developer.android.com/about/versions/nougat/android-7.0.html#multi-window_support
行為變更和影響
- 當設備處于低電耗，首先會限制，關閉應用網絡訪問，推遲作業和同步，一定時間后，會對除去PowerManager.WakeLock和Alarmmanager鬧鈴，GPS和WIFI掃描以外的進行低電耗限制
- 后臺優化，刪除了三個隱式廣播，如果app用到了，需要及時的解除關系
- 應用間共享文件的修改
- 無障礙改進，屏幕縮放，設置向導中視覺設置
- 附上官方鏈接：
https://developer.android.com/about/versions/nougat/android-7.0-changes.html
Android 7.0 FileProvider的適配
- 是什么
- 關于安卓7.0的適配，其中變更最大的就是FileProvider，關于FileProvider并不是最新出來的東西，而是以前就已經存在，由于Android的安全機制 ，一個進程默認不能影響另外一個進程的，如讀取私有數據 。 那么對于進程間的文件的共享 ，出于安全考慮，用FileProvider。FileProvider會基于manifest中的定義定義的一個xml文件（xml目錄 下），為所有定義的文件生成content URIs，這樣外部的應用在沒有權限的情況下，可以通過授予臨時權限的content uri，讀取相應的文件。
FileProvider是v4 support中的類 ， 就繼承ContentProvider。也就是說content:// Uri 代替了 file:/// Uri. 在Android7.0時候，為了安全，谷歌把它作為了一個強制使用而已。針對file://URI，需要通過FileProvider來轉換成content://URI進行訪問。
- 關于安卓7.0的適配，其中變更最大的就是FileProvider，關于FileProvider并不是最新出來的東西，而是以前就已經存在，由于Android的安全機制 ，一個進程默認不能影響另外一個進程的，如讀取私有數據 。 那么對于進程間的文件的共享 ，出于安全考慮，用FileProvider。FileProvider會基于manifest中的定義定義的一個xml文件（xml目錄 下），為所有定義的文件生成content URIs，這樣外部的應用在沒有權限的情況下，可以通過授予臨時權限的content uri，讀取相應的文件。
- 限制
- 那么會有人要問，是否所有需要從本地存儲的東西都會被限制呢，其實不然，谷歌做這項規定主要是針對，包含文件 URI 的 Intent 離開你的應用，換句話說，如果你的Intent中用到了Uri，這個時候你就需要提防一下了，比如說，你使用到了圖片裁剪等功能。
- 怎么做
-
第一步：
- 全局找出項目中，需要修改的地方，如下：
- Uri.parse、Uri.fromFile、file://、content://、Context.getFilesDir()、Environment.getExternalStorageDirectory()、getCacheDir()以及最終要的intent.setDataAndType(為什么需要找這個，因為這個會攜帶uri進行傳遞，這個是重頭戲)
-
第二步：
- 找到罪魁禍首之后，需要按照步驟適配了，依次順序是，清單文件的修改，資源文件的修改，以及Java代碼中的修改
-
第三步：
-
清單文件的修改---清單文件中，添加provider標簽即可
<provider android:exported="false" android:grantUriPermissions="true" android:authorities="com.***.fileprovider" android:name="android.support.v4.content.FileProvider"> <meta-data android:name="android.support.FILE_PROVIDER_PATHS" android:resource="@xml/file_paths" ></meta-data> </provider>
-
-
第四步：
-
創建res/xml/filepaths.xml文件
< paths xmlns:android="http://schemas.android.com/apk/res/android"> <external-path path="" name="external-path" /> <files-path path="" name="files_path" /> <cache-path path="" name="cache-path" /> </paths> 在這個文件中，為每個目錄添加一個XML元素指定目錄。paths 可以添加多個子路徑：< files-path> 分享app內部的存儲；< external-path> 分享外部的存儲;< cache-path> 分享內部緩存目錄。
< files-path >
代表目錄為：Context.getFilesDir()<external-path>
代表目錄為:Environment.getExternalStorageDirectory()<cache-path>
代表目錄為：getCacheDir()那么又存在了一個問題，國內由于rom眾多，會產生各種路徑，比如華為的/system/media/，以及外置sdcard,像此類路徑該如何適配呢？
< root-path path="" name="root-path" />
在這里又有人要問了，為什么要加root_path就管用，下面我們就一起再追蹤一下源碼
-
我們打開FileProvider的源碼
public class FileProvider extends ContentProvider -
開篇就能看見幾個變量
private static final String TAG_ROOT_PATH = "root-path"; private static final String TAG_FILES_PATH = "files-path"; private static final String TAG_CACHE_PATH = "cache-path"; private static final String TAG_EXTERNAL = "external-path"; -
里面有個重要方法parsePathStrategy，從xml我們定義臨時授權的路徑file_paths.xml中，解析以及對比路徑
while ((type = in.next()) != END_DOCUMENT) { if (type == START_TAG) { final String tag = in.getName(); final String name = in.getAttributeValue(null, ATTR_NAME); String path = in.getAttributeValue(null, ATTR_PATH); File target = null; if (TAG_ROOT_PATH.equals(tag)) { target = buildPath(DEVICE_ROOT, path); } else if (TAG_FILES_PATH.equals(tag)) { target = buildPath(context.getFilesDir(), path); } else if (TAG_CACHE_PATH.equals(tag)) { target = buildPath(context.getCacheDir(), path); } else if (TAG_EXTERNAL.equals(tag)) { target = buildPath(Environment.getExternalStorageDirectory(), path); } if (target != null) { strat.addRoot(name, target); } } } -
buildPath(DEVICE_ROOT, path)這個方法甚是晃眼
private static final File DEVICE_ROOT = new File("/"); -
到這里，我們應該就明白了，這個root代表的是根路徑，如果還不明白，我們可以進入adb試一下
MacBook-Pro:~ baidu$ adb shell bullhead:/ $ cd / bullhead:/ $ ls -
然后出現的路徑是
acct config dev mnt property_contexts sbin sys cache d etc oem res sdcard system charger data firmware proc root storage vendor 然后我們就看到了熟悉的system 以及sdcard等,到這里我們就徹底明白，root_path是為我們的根路徑進行了臨時授權，如果要訪問系統system以及外置sdcard的話，在這里將得到授權。
那么又有個問題，如果我寫了root_path的話，其他的file_path等是不是就不用寫了呢，答案是可以的，已經試驗，確實可以。不過反過來想，如果每次都對根路徑進行授權，那么這個FileProvider是不是意義就不大了呢，相當于安全性還是沒有防護，所以，谷歌的良苦用心，我們還需要理解，大家授權的時候，還是要把所有的路徑，能詳細的，盡量詳細一下。
附：至于為何path="",這里要寫空，原因是空表示根目錄都可以進行查找，當然如果路徑確定，可以寫成path="images/"，這表示直接適配了images這個文件夾，也就是可以在這個文件夾下查找，而在這個文件夾外，照舊會報錯。后面尾隨的這個name，則可以隨意寫，當FileProvider轉換路徑的時候，就會用此name代替，比如
content://com.***.fileprovider/myimages/default_image.jpg
-
-
第五步：
- 在java代碼中使用
//得到緩存路徑的Uri Uri contentUri = FileProvider.getUriForFile(getActivity(), "com.***.fileprovider", file); //獲取壁紙 Intent intent = WallpaperManager.getInstance(getActivity()).getCropAndSetWallpaperIntent(contentUri); //開啟一個Activity顯示圖片，可以將圖片設置為壁紙。調用的是系統的壁紙管理。 getActivity().startActivityForResult(intent, ViewerActivity.REQUEST_CODE_SET_WALLPAPER);
這樣是否大功告成？？？
-
java中使用，需要的權限，intent攜帶的讀寫權限
intent.addFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION); intent.addFlags(Intent.FLAG_GRANT_WRITE_URI_PERMISSION); 你以為這樣就真的完事兒了？
-
在適配過程中，發現有時候addFlag并不能完全的擁有權限，需要grantUriPermission獲取權限
context.grantUriPermission(packageName, uri, Intent.FLAG_GRANT_WRITE_URI_PERMISSION | Intent.FLAG_GRANT_READ_URI_PERMISSION); -
附上福利工具類
/** * Android N 適配工具類 */ public class NougatTools { /** * 將普通uri轉化成適應7.0的content://形式 針對文件格式 * * @param context 上下文 * @param file 文件路徑 * @param intent intent * @param type 圖片或者文件,0表示圖片,1表示文件 * @param intentType intent.setDataAndType * @return */ public static Intent formatFileProviderIntent( Context context, File file, Intent intent, String intentType) { Uri uri = FileProvider.getUriForFile(context, GlobalDef.nougatFileProvider, file); // 表示文件類型 intent.addFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION); intent.addFlags(Intent.FLAG_GRANT_WRITE_URI_PERMISSION); intent.setDataAndType(uri, intentType); return intent; } /** * 將普通uri轉化成適應7.0的content://形式 針對圖片格式 * * @param context 上下文 * @param file 文件路徑 * @param intent intent * @param intentType intent.setDataAndType * @return */ public static Intent formatFileProviderPicIntent( Context context, File file, Intent intent) { Uri uri = FileProvider.getUriForFile(context, GlobalDef.nougatFileProvider, file); List<ResolveInfo> resInfoList = context.getPackageManager().queryIntentActivities( intent, PackageManager.MATCH_DEFAULT_ONLY); for (ResolveInfo resolveInfo : resInfoList) { String packageName = resolveInfo.activityInfo.packageName; context.grantUriPermission(packageName, uri, Intent.FLAG_GRANT_WRITE_URI_PERMISSION | Intent.FLAG_GRANT_READ_URI_PERMISSION); } // 表示圖片類型 intent.addFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION); return intent; } /** * 將普通uri轉化成適應7.0的content://形式 * * @return */ public static Uri formatFileProviderUri(Context context, File file) { Uri uri = FileProvider.getUriForFile(context, GlobalDef.nougatFileProvider, file); return uri; } }
-
Android 7.0對三方工具的影響
UIL(Universal-Image-Loader)為例
關于imageloader適配，加載了本地圖片，竟然沒有問題
final ImageView imageView = (ImageView) LayoutInflater.from(context).inflate(R.layout.view_banner, null);
String imageUri = "/mnt/sdcard/image.png";
ImageLoader.getInstance().displayImage("file://"+imageUri, imageView);
-
如果想找到為何沒有影響，需要讀imageloader源碼，直接從imageloader中的加載圖片displayImage方法入手
public void displayImage(String uri, ImageAware imageAware, DisplayImageOptions options, ImageLoadingListener listener, ImageLoadingProgressListener progressListener) -
找到bmp != null && !bmp.isRecycled()判斷，如果沒有從本地找到或者被回收掉了的話，直接走LoadAndDisplayImageTask，去加載圖片
Bitmap bmp = configuration.memoryCache.get(memoryCacheKey); if (bmp != null && !bmp.isRecycled()) { L.d(LOG_LOAD_IMAGE_FROM_MEMORY_CACHE, memoryCacheKey); if (options.shouldPostProcess()) { ImageLoadingInfo imageLoadingInfo = new ImageLoadingInfo(uri, imageAware, targetSize, memoryCacheKey, options, listener, progressListener, engine.getLockForUri(uri)); ProcessAndDisplayImageTask displayTask = new ProcessAndDisplayImageTask(engine, bmp, imageLoadingInfo, defineHandler(options)); if (options.isSyncLoading()) { displayTask.run(); } else { engine.submit(displayTask); } } else { options.getDisplayer().display(bmp, imageAware, LoadedFrom.MEMORY_CACHE); listener.onLoadingComplete(uri, imageAware.getWrappedView(), bmp); } } else { if (options.shouldShowImageOnLoading()) { imageAware.setImageDrawable(options.getImageOnLoading(configuration.resources)); } else if (options.isResetViewBeforeLoading()) { imageAware.setImageDrawable(null); } ImageLoadingInfo imageLoadingInfo = new ImageLoadingInfo(uri, imageAware, targetSize, memoryCacheKey, options, listener, progressListener, engine.getLockForUri(uri)); LoadAndDisplayImageTask displayTask = new LoadAndDisplayImageTask(engine, imageLoadingInfo, defineHandler(options)); if (options.isSyncLoading()) { displayTask.run(); } else { engine.submit(displayTask); } } -
在LoadAndDisplayImageTask的run方法中，會判斷是否bitmap為空，這樣的話，就會嘗試load Bitmap
if (bmp == null || bmp.isRecycled()) { bmp = tryLoadBitmap(); -
這里才是加載圖片的關鍵，首先去判斷磁盤是否存在圖片，如果存在，則直接從磁盤加載圖片，如果本地沒有，則取網絡獲取圖片。
private Bitmap tryLoadBitmap() throws TaskCancelledException { Bitmap bitmap = null; try { File imageFile = configuration.diskCache.get(uri); if (imageFile != null && imageFile.exists() && imageFile.length() > 0) { L.d(LOG_LOAD_IMAGE_FROM_DISK_CACHE, memoryCacheKey); loadedFrom = LoadedFrom.DISC_CACHE; checkTaskNotActual(); bitmap = decodeImage(Scheme.FILE.wrap(imageFile.getAbsolutePath())); } if (bitmap == null || bitmap.getWidth() <= 0 || bitmap.getHeight() <= 0) { L.d(LOG_LOAD_IMAGE_FROM_NETWORK, memoryCacheKey); loadedFrom = LoadedFrom.NETWORK; String imageUriForDecoding = uri; if (options.isCacheOnDisk() && tryCacheImageOnDisk()) { imageFile = configuration.diskCache.get(uri); if (imageFile != null) { imageUriForDecoding = Scheme.FILE.wrap(imageFile.getAbsolutePath()); } } checkTaskNotActual(); bitmap = decodeImage(imageUriForDecoding); if (bitmap == null || bitmap.getWidth() <= 0 || bitmap.getHeight() <= 0) { fireFailEvent(FailType.DECODING_ERROR, null); } } } catch (IllegalStateException e) { fireFailEvent(FailType.NETWORK_DENIED, null); } catch (TaskCancelledException e) { throw e; } catch (IOException e) { L.e(e); fireFailEvent(FailType.IO_ERROR, e); } catch (OutOfMemoryError e) { L.e(e); fireFailEvent(FailType.OUT_OF_MEMORY, e); } catch (Throwable e) { L.e(e); fireFailEvent(FailType.UNKNOWN, e); } return bitmap; } -
首次進入肯定是bitmap是空的，找到tryCacheImageOnDisk方法
private boolean tryCacheImageOnDisk() throws TaskCancelledException { L.d(LOG_CACHE_IMAGE_ON_DISK, memoryCacheKey); boolean loaded; try { loaded = downloadImage(); if (loaded) { int width = configuration.maxImageWidthForDiskCache; int height = configuration.maxImageHeightForDiskCache; if (width > 0 || height > 0) { L.d(LOG_RESIZE_CACHED_IMAGE_FILE, memoryCacheKey); resizeAndSaveImage(width, height); // TODO : process boolean result } } } catch (IOException e) { L.e(e); loaded = false; } return loaded; } -
里面清晰的可以看見，有個downloadImage方法
private boolean downloadImage() throws IOException { InputStream is = getDownloader().getStream(uri, options.getExtraForDownloader()); if (is == null) { L.e(ERROR_NO_IMAGE_STREAM, memoryCacheKey); return false; } else { try { return configuration.diskCache.save(uri, is, this); } finally { IoUtils.closeSilently(is); } } } downloadImage方法中，獲取到了一個Downloader，通過uri獲取流
-
看看downloader是啥，有個子類BaseImageDownloader，看里面的getStream方法
public InputStream getStream(String imageUri, Object extra) throws IOException { switch (Scheme.ofUri(imageUri)) { case HTTP: case HTTPS: return getStreamFromNetwork(imageUri, extra); case FILE: return getStreamFromFile(imageUri, extra); case CONTENT: return getStreamFromContent(imageUri, extra); case ASSETS: return getStreamFromAssets(imageUri, extra); case DRAWABLE: return getStreamFromDrawable(imageUri, extra); case UNKNOWN: default: return getStreamFromOtherSource(imageUri, extra); } } -
那么問題就來了，我們傳入的是file：//前綴，會最終到downloader中獲取stream，繼續看看getStreamFromFile
protected InputStream getStreamFromFile(String imageUri, Object extra) throws IOException { String filePath = Scheme.FILE.crop(imageUri); if (isVideoFileUri(imageUri)) { return getVideoThumbnailStream(filePath); } else { BufferedInputStream imageStream = new BufferedInputStream(new FileInputStream(filePath), BUFFER_SIZE); return new ContentLengthInputStream(imageStream, (int) new File(filePath).length()); } } -
顯而易見，crop方法有問題
public String crop(String uri) { if (!belongsTo(uri)) { throw new IllegalArgumentException(String.format("URI [%1$s] doesn't have expected scheme [%2$s]", uri, scheme)); } return uri.substring(uriPrefix.length()); } -
uri.substring，有點意思，從uriPrefix的長度開始截取
Scheme(String scheme) { this.scheme = scheme; uriPrefix = scheme + "://"; } 這樣就很明白了，UIL這個框架，直接從"file:// "往后，把具體的地址截取出來了，而且它直接用后面的地址獲取到了InputStream，這樣就可以避免7.0這個file://需要換成content://的問題，而避免了使用FileProvider。
-
最后附上一個沒問題的例子。
FileInputStream fileInputStream = new FileInputStream("/storage/emulated/0/Download/com.***.apk");
