app upgrades are standard for every Android app, and most apps have an upgrade alert and apk download installation (if the system allows silent installation estimates there is no reminder).
The previous upgrade was to write the http download yourself or download it via the system-provided Downloadmanager. Inadvertently found that bugly provides download update service and free (and later provided a hot update), on the cheerfully access to the SDK, after all, is a giant thing, trustworthy. Start using the time is very stable (it is estimated that the handset manufacturers are not useless on the nougat), and then someone responded to the update failed, has been prompted to install, began to some do not believe that directly let the user unloading load (fortunately the user is the company's own people, is an outsider's words that there is no installation of uninstall).
Check the problem also looked at the bugly Access Guide, joined the android7.0 adaptation. I started to think that 7.0 of the users were less and that my build version was 5.0 and did not fit. When users who recently updated the response update failed, they looked at the problem a little bit. Also looked at the Goose Factory Engineer's blog (http://blog.csdn.net/wwj_748/article/details/52664647). This was due to the fact that Android7.0 implemented the "Strictmode API policy ban". "Strictmode API policy" means that the file://URI is prohibited from being exposed to your app. If a Intent that contains the file file://URI type leaves your app, the app fails with an fileuriexposedexception exception.
Previously updated by implicitly invoking the system Setup program
Intent i = new Intent (Intent.action_view); I.setdataandtype (uri.fromfile (file), "application/vnd.android.package-archive"); I.addflags (Intent.flag_activity_new_task); Context.startactivity (i);
This code sets the data and type through intent and then launches the install APK program through the context in the new task.
We see intent setting the data, pass a URI, this in api<24 is no problem, but in Android N has forbidden you to publicly file://URI. So the problem with our SDK is from the Uri.fromfile (file) The time to get the URI.
Android N has given a definitive solution, and if your program needs to share files between apps, you should send an Content://uri and grant the URI temporary access permissions. The simplest way to make this authorization is to use the Fileprovider class.
First register in Androidmanifest Fileprovider
code example:
<provider android:name= "Android.support.v4.content.FileProvider" android:authorities= " Com.bugly.upgrade.demo.fileProvider " Android:exported= "false" android: Granturipermissions= "true" > < meta-data android:name= "Android.support.FILE_PROVIDER_PATHS" android:resource= "@xml/provider_paths"/> </provider>
We can see the need to configure the corresponding meta-data in provider, this is the path to the shared file, create a new XML folder under the Res directory and create a new XML file (such as the following provider_paths), as follows:
<?xml version= "1.0" encoding= "Utf-8"?> <paths xmlns:android= "Http://schemas.android.com/apk/res/android" > <!-- /storage/emulated/0/Download/--> <external-path name= "beta_external_apk" path= "Download/ "/> <!--/storage/emulated/0/android/data/-- > <external-path name= "Beta_external_ Apk2 " path=" android/data//"/>&NBSP;&NBSP;&NBSP;&NBSP;&NBSP;</PATHS>
name represents a URI path segment, and path represents a subdirectory that specifies the path to share. This allows the system installer to access the downloaded APK file.
Because there is no 7.0 of the equipment in the excellent measurement on the rental equipment (fortunately there is a one-hour trial) test, the perfect solution. Google system upgrade is not backwards compatible, this is a pit.
The programming road is really a pit. May the world never bug, Amen.
Goose Factory bugly Application upgrade cannot be installed (new changes in Android7.0)