Android 5.x Application-Security-related updates


I just copied and summarized the security-related changed in Android 4.4, 5.0 and 5.1. Enjoy guys!


Custom permission

Android 5.0 prevents the installation of apps if they define a custom permission that is already defined by an existing resident app.


Web view

The WebView default behavior was changed to block mixed content. Please do not use: setMixedContentMode..


SSL default configuration

Android 5.0 introduces changes to the default TLS/SSL configuration used by apps for HTTPS and other TLS/SSL traffic:

  • TLSv1.2 and TLSv1.1 protocols are now enabled
  • AES-GCM (AEAD) cipher suites are now enabled
  • MD5, 3DES, export, and static key ECDH cipher suites are now disabled
  • Forward Secrecy cipher suites (ECDHE and DHE) are preferred


HTTP classes

The org.apache.http classes and the AndroidHttpClient class have been deprecated in Android 5.1.



The ActivityManager.getRecentTasks() method is now deprecated to improve user privacy. You have getAppTasks to retrieve your own tasks.


Managed profile

Device administrators can add a managed profile to a device. This profile is owned by the administrator, giving the administrator control over the managed profile while leaving the user’s personal profile and its storage space, under the user’s control. This change can affect the behavior of your existing app in the following ways:


Sharing files across profiles

Each profile has its own file storage. Since a file URI refers to a specific location in the file storage, this means that a file URI that is valid on one profile is not valid on the other one. This is not ordinarily a problem for an app, which usually just accesses the files it creates. However, if an app attaches a file to an intent, it is not safe to attach a file URI, since in some circumstances, the intent might be handled on the other profile. For example, a device administrator might specify that image capture events should be handled by the camera app on the personal profile. If the intent is fired by an app on the managed profile, the camera needs to be able to write the image to a location where the managed profile’s apps can read it.

To be safe, when you need to attach a file to an intent that might cross from one profile to the other, you should create and use a content URI for the file. For more information about sharing files with content URIs, see Sharing Files. For example, the device administrator might whitelist ACTION_IMAGE_CAPTURE to be handled by the camera in the personal profile. The firing intent’s EXTRA_OUTPUT should contain a content URI specifying where the photo should be stored. The camera app can write the image to the location specified by that URI, and the app that fired the intent would be able to read that file, even if the app is on the other profile.

Read more:, java.lang.String,


Android 4.4 security-related news:

The new method getExternalFilesDirs() works the same as the existing getExternalFilesDir() method, except it returns an array of File objects.

Other methods for accessing your app-specific cache directory and OBB directory also now have corresponding versions that provide access to secondary storage devices: getExternalCacheDirs() and getObbDirs(), respectively.

Note: Beginning with Android 4.4, the platform no longer requires that your app acquire the WRITE_EXTERNAL_STORAGE or READ_EXTERNAL_STORAGE when you need to access only your app-specific regions of the external storage using the methods above. However, the permissions are required if you want to access the shareable regions of the external storage, provided by getExternalStoragePublicDirectory().




0 replies

Leave a Reply

Want to join the discussion?
Feel free to contribute!

Leave a Reply

Your email address will not be published. Required fields are marked *