從Android6.0引入的動態權限控制(Runtime Permissions)到Android7.0的“私有目錄被限制訪問”,“StrictMode API 政策”。隨著Android版本越來越高,Android對隱私的保護力度也越來越大。下面總結一下適配心得。
如果沒有做好兼容在應用市場會出現如下提示
安裝的時候提示不兼容Android7.0
原因:谷歌權限變化,應用加固
一、目錄被限制訪問
一直以來,在目錄及文件的訪問保護方面iOS做的是很到位的,如:iOS的沙箱機制。但,Android在這方面的保護就有些偏弱了,在Android中應用可以讀寫手機存儲中任何一個目錄及文件,這也帶來了很多的安全問題。現在Android也在著力解決這一問題。
Android7.0中為了提高私有文件的安全性,面向 Android N 或更高版本的應用私有目錄將被限制訪問。對于這個權限的更改開發者需要留意一下改變:
私有文件的文件權限不在放權給所有的應用,使用 MODE_WORLD_READABLE 或MODE_WORLD_WRITEABLE 進行的操作將觸發 SecurityException。
應對策略:這項權限的變更將意味著你無法通過File API訪問手機存儲上的數據了,基于File API的一些文件瀏覽器等也將受到很大的影響,看到這大家是不是驚呆了呢,不過迄今為止,這種限制尚不能完全執行。 應用仍可能使用原生 API 或 File API 來修改它們的私有目錄權限。 但是,Android官方強烈反對放寬私有目錄的權限。可以看出收起對私有文件的訪問權限是Android將來發展的趨勢。
(一)、給其他應用傳遞 file
給其他應用傳遞 file:// URI 類型的Uri,可能會導致接受者無法訪問該路徑。 因此,在Android7.0中嘗試傳遞 file:// URI 會觸發 FileUriExposedException。
應對策略:大家可以通過使用FileProvider來解決這一問題。
例子:N 上 安裝Apk時報錯:android.os.FileUriExposedException: file:///storage/emulated/0/Download/appName-2.3.0.apk exposed beyond app through Intent.getData()
(二)、DownloadManager
DownloadManager 不再按文件名分享私人存儲的文件。COLUMN_LOCAL_FILENAME在Android7.0中被標記為deprecated
,舊版應用在訪問 COLUMN_LOCAL_FILENAME時可能出現無法訪問的路徑。 面向 Android N 或更高版本的應用在嘗試訪問 COLUMN_LOCAL_FILENAME 時會觸發 SecurityException。
應對策略:大家可以通過ContentResolver.openFileDescriptor()來訪問由DownloadManager 公開的文件。
(三)、應用間共享文件
在Android7.0系統上,Android 框架強制執行了 StrictMode API 政策禁止向你的應用外公開 file:// URI。 如果一項包含文件 file:// URI類型 的 Intent 離開你的應用,應用失敗,并出現 FileUriExposedException 異常,如調用系統相機拍照,或裁切照片。
應對策略:若要在應用間共享文件,可以發送 content:// URI類型的Uri,并授予 URI 臨時訪問權限。 進行此授權的最簡單方式是使用 FileProvider類。 如需有關權限和共享文件的更多信息,請參閱共享文件。
(四)、在Android7.0上調用系統相機拍照,裁切照片
調用系統相機拍照
在Android7.0之前,如果你想調用系統相機拍照可以通過以下代碼來進行:
File file=new File(Environment.getExternalStorageDirectory(), "/temp/"+System.currentTimeMillis() + ".jpg");
if (!file.getParentFile().exists())file.getParentFile().mkdirs();
Uri imageUri = Uri.fromFile(file);
Intent intent = new Intent();
intent.setAction(MediaStore.ACTION_IMAGE_CAPTURE);//設置Action為拍照
intent.putExtra(MediaStore.EXTRA_OUTPUT, imageUri);//將拍取的照片保存到指定URI
startActivityForResult(intent,1006);
在Android7.0上使用上述方式調用系統相拍照會拋出如下異常:
android.os.FileUriExposedException: file:////storage/emulated/0/temp/1474956193735.jpg exposed beyond app through Intent.getData()
at android.os.StrictMode.onFileUriExposed(StrictMode.java:1799)
at android.net.Uri.checkFileUriExposed(Uri.java:2346)
at android.content.Intent.prepareToLeaveProcess(Intent.java:8933)
at android.content.Intent.prepareToLeaveProcess(Intent.java:8894)
at android.app.Instrumentation.execStartActivity(Instrumentation.java:1517)
at android.app.Activity.startActivityForResult(Activity.java:4223)
...
at android.app.Activity.startActivityForResult(Activity.java:4182)
這是由于Android7.0執行了“StrictMode API 政策禁”的原因,不過小伙伴們不用擔心,上文講到了可以用FileProvider來解決這一問題,現在我們就來一步一步的解決這個問題。
使用FileProvider
使用FileProvider的大致步驟如下:
第一步:在manifest清單文件中注冊provider
<provider
android:name="android.support.v4.content.FileProvider"
// android:authorities="app的包名.fileProvider"
android:authorities="com.jph.takephoto.fileprovider"
android:grantUriPermissions="true"
android:exported="false">
<meta-data
android:name="android.support.FILE_PROVIDER_PATHS"
android:resource="@xml/file_paths" />
</provider>
注意:
authorities:app的包名.fileProvider
exported:要求必須為false,為true則會報安全異常。
grantUriPermissions:必須是true,表示授予 URI 臨時訪問權限。
resource:中的@xml/file_paths是我們接下來要添加的文件
第二步:指定共享的目錄
為了指定共享的目錄我們需要在資源(res)目錄下創建一個xml目錄,然后創建一個名為“file_paths”(名字可以隨便起,只要和在manifest注冊的provider所引用的resource保持一致即可)的資源文件,內容如下:
<?xml version="1.0" encoding="utf-8"?>
<resources>
<paths>
<external-path path="" name="camera_photos" />
</paths>
</resources>
<?xml version="1.0" encoding="utf-8"?>
<paths>
<external-path path="Android/data/app的包名/" name="files_root" />
<external-path path="." name="external_storage_root" />
</paths>
- <files-path/>代表的根目錄: Context.getFilesDir()
- <external-path/>代表的根目錄: Environment.getExternalStorageDirectory()
- <cache-path/>代表的根目錄: getCacheDir()
心得:上述代碼中path="",是有特殊意義的,它代碼根目錄,也就是說你可以向其它的應用共享根目錄及其子目錄下任何一個文件了,如果你將path設為path="pictures",
那么它代表著根目錄下的pictures目錄(eg:/storage/emulated/0/pictures),如果你向其它應用分享pictures目錄范圍之外的文件是不行的。
第三步:使用FileProvider
上述準備工作做完之后,現在我們就可以使用FileProvider了。
還是以調用系統相機拍照為例,我們需要將上述拍照代碼修改為如下:
File file=new File(Environment.getExternalStorageDirectory(), "/temp/"+System.currentTimeMillis() + ".jpg");
if (!file.getParentFile().exists())file.getParentFile().mkdirs();
Uri imageUri = FileProvider.getUriForFile(context, "com.jph.takephoto.fileprovider", file);//通過FileProvider創建一個content類型的Uri
Intent intent = new Intent();
intent.addFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION); //添加這一句表示對目標應用臨時授權該Uri所代表的文件
intent.setAction(MediaStore.ACTION_IMAGE_CAPTURE);//設置Action為拍照
intent.putExtra(MediaStore.EXTRA_OUTPUT, imageUri);//將拍取的照片保存到指定URI
startActivityForResult(intent,1006);
上述代碼中主要有兩處改變:
- 將之前Uri的scheme類型為file的Uri改成了有FileProvider創建一個content類型的Uri。
- 添加了intent.addFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION);來對目標應用臨時授權該Uri所代表的文件。
心得:上述代碼通過FileProvider的Uri getUriForFile (Context context, String authority, File file)
靜態方法來獲取Uri,該方法中authority參數就是清單文件中注冊provider的android:authorities="com.jph.takephoto.fileprovider"。
對Web服務器如tomcat,IIS比較熟悉的小伙伴,都只知道為了網站內容的安全和高效,Web服務器都支持為網站內容設置一個虛擬目錄,其實FileProvider也有異曲同工之處。
將getUriForFile方法獲取的Uri打印出來如下:
content://com.jph.takephoto.fileprovider/camera_photos/temp/1474960080319.jpg`。
其中camera_photos就是file_paths.xml中paths的name。
因為上述指定的path為path="",所以content://com.jph.takephoto.fileprovider/camera_photos/代表的真實路徑就是根目錄,即:/storage/emulated/0/。
content://com.jph.takephoto.fileprovider/camera_photos/temp/1474960080319.jpg代表的真實路徑是:/storage/emulated/0/temp/1474960080319.jpg。
另外,推薦大家使用開源工具庫TakePhoto,TakePhoto是一款在Android設備上獲取照片(拍照或從相冊、文件中選擇)、裁剪圖片、壓縮圖片的開源工具庫。
裁切照片
在Android7.0之前,你可以通過如下方法來裁切照片:
File file=new File(Environment.getExternalStorageDirectory(), "/temp/"+System.currentTimeMillis() + ".jpg");
if (!file.getParentFile().exists())file.getParentFile().mkdirs();
Uri outputUri = Uri.fromFile(file);
Uri imageUri=Uri.fromFile(new File("/storage/emulated/0/temp/1474960080319.jpg"));
Intent intent = new Intent("com.android.camera.action.CROP");
intent.setDataAndType(imageUri, "image/*");
intent.putExtra("crop", "true");
intent.putExtra("aspectX", 1);
intent.putExtra("aspectY", 1);
intent.putExtra("scale", true);
intent.putExtra(MediaStore.EXTRA_OUTPUT, outputUri);
intent.putExtra("outputFormat", Bitmap.CompressFormat.JPEG.toString());
intent.putExtra("noFaceDetection", true); // no face detection
startActivityForResult(intent,1008);
和拍照一樣,上述代碼在Android7.0上同樣會引起android.os.FileUriExposedException
異常,解決辦法就是上文說說的使用FileProvider。
然后,將上述代碼改為如下即可:
File file=new File(Environment.getExternalStorageDirectory(), "/temp/"+System.currentTimeMillis() + ".jpg");
if (!file.getParentFile().exists())file.getParentFile().mkdirs();
Uri outputUri = FileProvider.getUriForFile(context, "com.jph.takephoto.fileprovider",file);
Uri imageUri=FileProvider.getUriForFile(context, "com.jph.takephoto.fileprovider", new File("/storage/emulated/0/temp/1474960080319.jpg");//通過FileProvider創建一個content類型的Uri
Intent intent = new Intent("com.android.camera.action.CROP");
intent.addFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION);
intent.setDataAndType(imageUri, "image/*");
intent.putExtra("crop", "true");
intent.putExtra("aspectX", 1);
intent.putExtra("aspectY", 1);
intent.putExtra("scale", true);
intent.putExtra(MediaStore.EXTRA_OUTPUT, outputUri);
intent.putExtra("outputFormat", Bitmap.CompressFormat.JPEG.toString());
intent.putExtra("noFaceDetection", true); // no face detection
startActivityForResult(intent,1008);
另外,裁切照片推薦大家使用開源工具庫TakePhoto,TakePhoto是一款在Android設備上獲取照片(拍照或從相冊、文件中選擇)、裁剪圖片、壓縮圖片的開源工具庫。
(五)、電池和內存
Android 6.0(API 級別 23)引入了低電耗模式,Android7.0在電池和內存上又做了進一步優化,
來減少Android應用對電量的消耗以及對內存的占用。這些優化所帶來的一些規則的變更可能會影響你的應用訪問系統資源,以及你的系統通過特定隱式 Intent 與其他應用互動的方式。
所以開發人員需要特別注意這些改變。
低電耗模式
在低電耗模式下,當用戶設備未插接電源、處于靜止狀態且屏幕關閉時,該模式會推遲 CPU 和網絡活動,從而延長電池壽命。
Android7.0通過在設備未插接電源且屏幕關閉狀態下、但不一定要處于靜止狀態(例如用戶外出時把手持式設備裝在口袋里)時應用部分 CPU 和網絡限制,進一步增強了低電耗模式。
也就是說,Android7.0會在手機屏幕關閉的狀態下,限時應用對CPU以及網絡的使用。
具體規則如下:
- 當設備處于充電狀態且屏幕已關閉一定時間后,設備會進入低電耗模式并應用第一部分限制: 關閉應用網絡訪問、推遲作業和同步。
- 如果進入低電耗模式后設備處于靜止狀態達到一定時間,系統則會對PowerManager.WakeLock、AlarmManager鬧鈴、GPS 和 Wi-Fi 掃描應用余下的低電耗模式限制。 無論是應用部分還是全部低電耗模式限制,系統都會喚醒設備以提供簡短的維護時間窗口,在此窗口期間,應用程序可以訪問網絡并執行任何被推遲的作業/同步。
后臺優化
小伙伴們都知道在Android中有一些隱式廣播,使用這些隱式廣播可以做一些特定的功能,如,當手機網絡變成WiFi時自動下載更新包等。
但,這些隱式廣播會在后臺頻繁啟動已注冊偵聽這些廣播的應用,從而帶來很大的電量消耗,為緩解這一問題來提升設備性能和用戶體驗,在Android 7.0中刪除了三項隱式廣播,以幫助優化內存使用和電量消耗。
Android 7.0 應用了以下優化措施:
- 在 Android 7.0上 應用不會收到 CONNECTIVITY_ACTION 廣播,即使你在manifest清單文件中設置了請求接受這些事件的通知。 但,在前臺運行的應用如果使用BroadcastReceiver 請求接收通知,則仍可以在主線程中偵聽 CONNECTIVITY_CHANGE。
- 在 Android 7.0上應用無法發送或接收 ACTION_NEW_PICTURE 或ACTION_NEW_VIDEO 類型的廣播。
應對策略:Android 框架提供多個解決方案來緩解對這些隱式廣播的需求。 例如,JobScheduler API提供了一個穩健可靠的機制來安排滿足指定條件(例如連入無限流量網絡)時所執行的網絡操作。 您甚至可以使用 JobScheduler API 來適應內容提供程序變化。
另外,大家如果想了解更多關于后臺的優化可查閱后臺優化。
移動設備會經歷頻繁的連接變更,例如在 Wi-Fi 和移動數據之間切換時。 目前,可以通過在應用清單中注冊一個接收器來偵聽隱式 CONNECTIVITY_ACTION 廣播,
讓應用能夠監控這些變更。 由于很多應用會注冊接收此廣播,因此單次網絡切換即會導致所有應用被喚醒并同時處理此廣播。
另外權限處理框架PermissionsDispatcher的使用
使用這個框架最好先安裝PermissionsDispatcher plugin,方便直接使用
1、引入依賴
添加
compile 'com.github.hotchemi:permissionsdispatcher:3.0.1'
annotationProcessor 'com.github.hotchemi:permissionsdispatcher-processor:3.0.1'
dependencies {
implementation fileTree(dir: 'libs', include: ['*.jar'])
implementation 'com.android.support:appcompat-v7:26.1.0'
implementation 'com.android.support:design:26.1.0'
testImplementation 'junit:junit:4.12'
//這行代碼是編譯后自動生成--start
androidTestImplementation('com.android.support.test.espresso:espresso-core:3.0.1', {
exclude group: 'com.android.support', module: 'support-annotations'
})
//這行代碼是編譯后自動生成--end
compile 'com.github.hotchemi:permissionsdispatcher:3.0.1'
annotationProcessor 'com.github.hotchemi:permissionsdispatcher-processor:3.0.1'
}
這幾行代碼是編譯后自己生成,不用手動寫
androidTestImplementation('com.android.support.test.espresso:espresso-core:3.0.1', {
exclude group: 'com.android.support', module: 'support-annotations'
})
在需要權限校驗用到的地方
MainActivityPermissionsDispatcher.showContactsWithCheck(this);
MainActivityPermissionsDispatcher在編譯后自動生成,編譯方法如下
參考
Android N系列適配---FileProvider
Android7.0適配教程,心得
Android 7.0 開發者版本
android6.0,7.0獲取真實的藍牙地址
Android N(7.0) 被美翻的新特性!
Android 7.0 Nougat正式版刷機教程—nexus5X
http://www.apkbus.com/blog-705730-62835.html