1. Introduction

1.1. Building a Secure Smartphone Society

This guidebook is a collection of tips concerning the know-how of secure designs and secure coding for Android application developers. Our intent is to have as many Android application developers as possible take advantage of this, and for that reason we are making it public.

In recent years, the smartphone market has witnessed a rapid expansion, and its momentum seems unstoppable. Its accelerated growth is brought on due to the diverse range of applications. An unspecified large number of key functions of mobile phones that were once not accessible due to security restrictions on conventional mobile phones have been made open to smartphone applications. Subsequently, the availability of varied applications that were once closed to conventional mobile phones is what makes smartphones more attractive.

With great power that comes from smartphone applications comes great responsibility from their developers. The default security restrictions on conventional mobile phones had made it possible to maintain a relative level of security even for applications that were developed without security awareness. As it has been aforementioned with regard to smartphones, since the key advantage of a smartphone is that they are open to application developers, if the developers design or code their applications without the knowledge of security issues then this could lead to risks of users’ personal information leakage or exploitation by malware causing financial damage such as from illicit calls to premium-rate numbers.

Due to Android being a very open model allowing access to many functions on the smartphone, it is believed that Android application developers need to take more care about security issues than iOS application developers. In addition, responsibility for application security is almost solely left to the application developers. For example, applications can be released to the public without any screening from a marketplace such as Google Play (former Android Market), though this is not possible for iOS applications.

In conjunction with the rapid growth of the smartphone market, there has been a sudden influx of software engineers from different areas in the smartphone application development market. As a result, there is an urgent call for the sharing knowledge of secure design and consolidation of secure coding know-how for specific security issues related to mobile applications.

Due to these circumstances, Japan’s Smartphone Security Association (JSSEC) has launched the Secure Coding Group, and by collecting the know-how of secure design as well as secure coding of Android applications, it has decided to make all of the information public with this guidebook. It is our intention to raise the security level of many of the Android applications that are released in the market by having many Android application developers become acquainted with the know-how of secure design and coding. As a result, we believe we will be contributing to the creation of a more reliable and safe smartphone society.

1.2. Timely Feedback on a Regular Basis Through the Beta Version

We, the JSSEC Secure Coding Group, will do our best to keep the content contained in the Guidebook as accurate as possible, but we cannot make any guarantees. We believe it is our priority to publicize and share the know-how in a timely fashion. Equally, we will upload and publicize what we consider to be the latest and most accurate correct information at that particular juncture, and will update it with more accurate information once we receive any feedback or corrections. In other words, we are taking the beta version approach on a regular basis. We think this approach would be meaningful for many of the Android application developers who are planning on using the Guidebook.

The latest version of the Guidebook and sample codes can be obtained from the URL below.

The latest Japanese version can be obtained from the URL below.

1.3. Usage Agreement of the Guidebook

We need your consent for the following two precautionary statements when using the Guidebook.

  1. The information contained in the Guidebook may be inaccurate. Please use the information written here by your own discretion.
  2. In case of finding any mistakes contained in the Guidebook, please send us an e-mail to the address listed below. However, we cannot guarantee a reply or any revisions thereof.

Japan Smartphone Security Association

Secure Coding Group Inquiry

E-mail: jssec-securecoding-qa@googlegroups.com

Subject: [Comment] Android Secure Coding Guidebook 20191201EN

Content: Name (optional), Affiliation (optional), E-mail (optional), Comment (required) and Other matters (optional)

1.4. Correction articles of September 1, 2018 edition

This section provides a list of corrections and modifications for the previous edition from the viewpoint of security, as a result of further studies.

In correcting articles, we adopted the outcomes of our studies and the valuable opinions of those who read the former editions of this guidebook.

Especially, taking in readers’ opinions is considered as a key factor in making the document highly practical.

We recommend, for those who use a previous edition of the document as a reference, taking a look at the list below. Note that the list does not include the following kinds of changes and error corrections: fixes of typos, organizational changes, and improvements in expression.

Any comments, opinions or suggestions on this guidebook are greatly appreciated.

Table 1.4.1 List of revisions
Section revised in 9/1/2018 version Section revised in this version Revision
4.1.3.1. Combining Exported Attributes and Intent Filter Settings (For Activities) 4.1.3.1. Combining Exported Attributes and Intent Filter Settings (For Activities) Added a note about the behavior when sending an implicit Intent that was changed in Android 8.0 (API Level 26).
4.4.1.2. Creating/Using Public Services4.4.3.1. Combination of Exported Attribute and Intent-filter Setting (In the Case of Service) 4.4.1.2. Creating/Using Public Services4.4.3.1. Combination of Exported Attribute and Intent-filter Setting (In the Case of Service) The Intent-filter definition in Public Service was changed to “(Do not Use)”.
4.6.1.4. Using Eternal Memory (Read Write Public) Files 4.6.1.4. Using Eternal Memory (Read Write Public) Files Added an explanation on the requestLegacyExternalStorage manifest attribute setting that temporarily opts out from the scoped storage function in Android 10.
4.6.3.5. Revised specifications in Android 7.0 (API Level 24) for accessing specific directories on external storage media 4.6.3.5. Revised specifications in Android 7.0 (API Level 24) for accessing specific directories on external storage media Added an explanation that the StorageVolume#createAccessIntent method was deprecated as of Android 10.
(not applicable) 4.6.3.6. About specifications related to access to external storage in Android 10 (API Level 29) Added an explanation on the specifications for accessing external storage that were changed in Android 10 (API level 29).
5.2.3.6. Modifications to the Permission model specifications in Android versions 6.0 and later 5.2.3.6. Modifications to the Permission model specifications in Android versions 6.0 and later Added an explanation on display of a warning when an old app was executed in an Android 10 device.
5.4. Communicating via HTTPS5.4.1.1. Communicating via HTTP5.4.1.2. Communicating via HTTPS 5.4. Communicating via HTTPS5.4.1.1. Communicating via HTTP5.4.1.2. Communicating via HTTPS Changed to a sample code where the Google Image Search API, whose service has been discontinued, is not used. The content of the article was also updated to reflect this change.
5.4.3.8.(Column): Transitioning to TLS1.2 for secure connections 5.4.3.8. (Column): Transitioning to TLS1.2/TLS1.3 for secure connections The content of the article was updated to take into account support of TLS 1.3 starting from Android 10.
5.5.1.2. Broad consent is granted: Applications that incorporate application privacy policy 5.5.1.2. Broad consent is granted: Applications that incorporate application privacy policy In the example, the IMEI was acquired and used, but because unprivileged apps can no longer acquire IMEI in the Android 10 specifications, the data used was changed to UUID.
(not applicable) 5.5.3.4. Restriction on obtaining non-resettable device identifiers on Android 10 An article was added to reflect the change in permissions required for obtaining device identifier information in Android 10.
5.6.2.2. Use Strong Algorithms (Specifically, Algorithms that Meet the Relevant Criteria) (Required) 5.6.2.2. Use Strong Algorithms (Specifically, Algorithms that Meet the Relevant Criteria) (Required) The tables for NIST and ECRYPT II were revised for consistency with the updated source data.
5.6.3.2. Generation of random numbers5.6.3.3. Measures to Protect against Vulnerabilities in Random-Number Generators 5.6.3.2. Generation of random numbers5.6.3.3. Measures to Protect against Vulnerabilities in Random-Number Generators The article was revised to take into account that Crypto Provider was deprecated/removed.
5.7. Using fingerprint authentication features 5.7. Using biometric authentication features Because FingerprintManager was deprecated, the chapter title was revised to “Biometric Authentication”, and the content was also updated. Also, the sample code was changed so that BiometricPrompt only is used.