The following table lists the Java development guidelines in the book, "Java Coding Guidelines: 75 Recommendations for Reliable and Secure Programs", and states their applicability to the development of Android applications. Applicable means that the guideline can be applied to general Java platforms including Android. Applicable in principle means that the guideline can The top two tables list the Java rules and Java recommendations that are Applicable in principle, meaning that it can be applied to Android but the examples shown in the guideline are not relevant to Android, and in some cases the guideline's full description also needs edits (the latter are provided in the Comments column). Not applicable means that the guideline cannot The third table lists Unknown rules and recommendations, meaning that we have not yet determined if the guideline can be applied to Android platforms.

Contents

...

Table of Contents

Rules/Applicable in Principle to Android

Rule Application Development?	Comments
IDS00-J. Sanitize untrusted data passed across a trust boundaryApplicable in principle	The rule uses MS SQL Server as an example to show a database connection. However, on Android, `DatabaseHelper` from SQLite is used for a database connection. Because Android apps may receive untrusted data via network connections, the rule is applicable.
IDS01-J. Normalize strings before validating them	Applicable in principle	Android apps can receive string data from the outside and normalize it.
IDS02-J. Canonicalize path names before validating them	Applicable in principle	The rule is applicable in principle. Please refer to the Android specific instance of this rule: DRD08-J. Always canonicalize a URL received by a content provider.
IDS03-J. Do not log unsanitized user input	Applicable
IDS04-J. Safely extract files from ZipInputStreamApplicable in principle	Although not directly a violation of this rule, the Android Master Key vulnerability (insecure use of ZipEntry) is related to this rule. Another attack vector found by a Chinese researcher is also related to this rule.
IDS05IDS07-J. Use a subset of ASCII for file and path names	Applicable
IDS06-J. Exclude unsanitized user input from format strings	Applicable
IDS07-J. Do not pass Do not pass untrusted, unsanitized data to the Runtime.exec() method	Applicable in principle	`Runtime.exec()` can be called from Android apps to execute operating system commands.
IDS08-J. Sanitize untrusted data passed to a regex	Applicable
IDS09-J. Do not use locale-dependent methods on locale-dependent data without specifying the appropriate localeApplicable in principle	A developer can specify locale on Android using `java.util.Locale`.
IDS10EXP01-J. Do not split characters between two data structures	Applicable
IDS11-J. Eliminate noncharacter code points before validation	Applicable
IDS12-J. Perform lossless conversion of String data between differing character encodings	Applicable	<this is voided>
IDS13-J. Use compatible encodings on both sides of file or network IO	Applicable
DCL00-J. Prevent class initialization cycles	Applicable
DCL01-J. Do not reuse public identifiers from the Java Standard Library	Applicable
DCL02-J. Declare all enhanced for statement loop variables final	Applicable
EXP00-J. Do not ignore values returned by methods	Applicable
EXP01-J. Never dereference null pointers	Applicable in principle	Android applications are more sensitive to `NullPointerException` due to the constraint of the limited mobile device memory. Static members or members of an Activity may become null when memory runs out.
EXP02-J. Use the two-argument Arrays.equals() method to compare the contents of arrays	Applicable
EXP03-J. Do not use the equality operators when comparing values of boxed primitives	Applicable
EXP04-J. Ensure that autoboxed values have the intended type	Applicable
EXP05-J. Do not write more than once to the same variable within an expression	Applicable
Never dereference null pointers	Android applications are more sensitive to `NullPointerException` due to the constraint of the limited mobile device memory. Static members or members of an Activity may become null when memory runs out.
EXP06-J. Do not use side-effecting expressions in assertions	The `assert` statement is supported on the Dalvik VM but is ignored under the default configuration. Assertions may be enabled by setting the system property "`debug.assert`" via: `adb shell setprop debug.assert 1` or by sending the command line argument "`--enable-assert`" to the Dalvik VM.
NUM00-J. Detect or prevent integer overflow	Mezzofanti for Android contained an integer overflow which prevented the use of a big SD card. Mezzofanti contained an expression: `(int) StatFs.getAvailableBlocks() * (int) StatFs.getBlockSize()` to calculate the available memory in a SD card, which could result in a negative value when the available memory is bigger than `Integer.MAX_VALUE`. Note these methods are deprecated in API level 18 and replaced by `getAvailableBlocksLong()` and `getBlockSizeLong()`.
NUM04-J. Do not use floating-point numbers if precise computation is required	The use of floating-point is not recommended for performance reasons on Android.
NUM06-J. Use the strictfp modifier for floating-point calculation consistency across platforms
NUM11-J. Do not compare or inspect the string representation of floating-point values	Comparing or inspecting the string representation of floating-point values may have unexpected results on Android.
MET01-J. Never use assertions to validate method arguments	EXP06-J. Do not use side-effecting expressions in assertions	Applicable in principle	The `assert` statement is supported on the Dalvik VM but is ignored under the default configuration. Assertions may be enabled by setting the system property "`debug.assert`" via: `adb shell setprop debug.assert 1` or by sending the command line argument "`--enable-assert`" to the Dalvik VM.
NUM00MET02-J. Detect or prevent integer overflow	Applicable in principle	Mezzofanti for Android contained an integer overflow which prevented the use of a big SD card. Mezzofanti contained an expression: `(int) StatFs.getAvailableBlocks() * (int) StatFs.getBlockSize()` to calculate the available memory in a SD card, which could result in a negative value when the available memory is bigger than `Integer.MAX_VALUE`. Note these methods are deprecated in API level 18 and replaced by `getAvailableBlocksLong()` and `getBlockSizeLong()`.
NUM01-J. Do not perform bitwise and arithmetic operations on the same data	Applicable
NUM02-J. Ensure that division and modulo operations do not result in divide-by-zero errors	Applicable
NUM03-J. Use integer types that can fully represent the possible range of unsigned data	Applicable
NUM04-J. Do not use floating-point numbers if precise computation is required	Applicable in principle	The use of floating-point is not recommended for performance reasons on Android.
NUM05-J. Do not use denormalized numbers	Applicable
NUM06-J. Use the strictfp modifier for floating-point calculation consistency across platforms	Applicable in principle
NUM07-J. Do not attempt comparisons with NaN	Applicable
NUM08-J. Check floating-point inputs for exceptional values	Applicable
NUM09-J. Do not use floating-point variables as loop counters	Applicable
NUM10-J. Do not construct BigDecimal objects from floating-point literals	Applicable
NUM11-J. Do not compare or inspect the string representation of floating-point values	Applicable in principle	Comparing or inspecting the string representation of floating-point values may have unexpected results on Android.
NUM12-J. Ensure conversions of numeric types to narrower types do not result in lost or misinterpreted data	Applicable
NUM13-J. Avoid loss of precision when converting primitive integers to floating-point	Applicable
OBJ00-J. Limit extensibility of classes and methods with invariants	Applicable
OBJ01-J. Declare data members as private and provide accessible wrapper methods	Applicable
OBJ02-J. Preserve dependencies in subclasses when changing superclasses	Applicable
OBJ03-J. Do not mix generic with nongeneric raw types in new code	Applicable
OBJ04-J. Provide mutable classes with copy functionality to safely allow passing instances to untrusted code	Applicable
OBJ05-J. Defensively copy private mutable class members before returning their references	Applicable
OBJ06-J. Defensively copy mutable inputs and mutable internal components	Applicable
OBJ07-J. Sensitive classes must not let themselves be copied	Applicable
OBJ08-J. Do not expose private members of an outer class from within a nested class	Applicable
OBJ09-J. Compare classes and not class names	Applicable
OBJ10-J. Do not use public static nonfinal variables	Applicable
OBJ11-J. Be wary of letting constructors throw exceptions	Applicable
MET00-J. Validate method arguments	Applicable
MET01-J. Never use assertions to validate method arguments	Applicable in principle	The `assert` statement is supported on the Dalvik VM but is ignored under the default configuration. Assertions may be enabled by setting the system property "`debug.assert`" via: `adb shell setprop debug.assert 1` or by sending the command line argument "`--enable-assert`" to the Dalvik VM.
MET02-J. Do not use deprecated or obsolete classes or methods	Applicable in principle	The Android SDK also has deprecated or obsolete APIs. Also, there may exist incompatible APIs depending on the SDK version. Therefore, it is recommended that developers refer to the "Android API Difference report" and consider replacing the deprecated APIs.
MET03-J. Methods that perform a security check must be declared private or final	Applicable in principle	On Android, `System.getSecurityManager()` is not used and the use of a Security Manager is not exercised. However, an Android developer can implement security-sensitive methods so the principle may be applicable on Android.
MET04-J. Do not increase the accessibility of overridden or hidden methods	Applicable
MET05-J. Ensure that constructors do not call overridable methods	Applicable
MET06-J. Do not invoke overridable methods in clone()	Applicable
MET07-J. Never declare a class method that hides a method declared in a superclass or superinterface	Applicable
MET08-J. Preserve the equality contract when overriding the equals() method	Applicable
MET09-J. Classes that define an equals() method must also define a hashCode() method	Applicable	<bjw pickup>
MET10-J. Follow the general contract when implementing the compareTo() method	Applicable
MET11-J. Ensure that keys used in comparison operations are immutable	Applicable
MET12-J. Do not use finalizers	Applicable
ERR00-J. Do not suppress or ignore checked exceptions	Applicable
ERR01-J. Do not allow exceptions to expose sensitive information	Applicable
ERR02-J. Prevent exceptions while logging data	Applicable
ERR03-J. Restore prior object state on method failure	Applicable
ERR04-J. Do not complete abruptly from a finally block	Applicable
ERR05-J. Do not let checked exceptions escape from a finally block	Applicable
ERR06-J. Do not throw undeclared checked exceptions	Applicable
ERR07-J. Do not throw RuntimeException, Exception, or Throwable	Applicable
ERR08-J. Do not catch NullPointerException or any of its ancestors	Applicable
ERR09-J. Do not allow untrusted code to terminate the JVM	Applicable in principle	On Android, `System.exit()` should not be used because it will terminate the virtual machine abruptly, ignoring the activity lifecycle which may prevent proper garbage collection.
VNA00-J. Ensure visibility when accessing shared primitive variables	Applicable
VNA01-J. Ensure visibility of shared references to immutable objects	Applicable
VNA02-J. Ensure that compound operations on shared variables are atomic	Applicable
VNA03-J. Do not assume that a group of calls to independently atomic methods is atomic	Applicable
VNA04-J. Ensure that calls to chained methods are atomic	Applicable
VNA05-J. Ensure atomicity when reading and writing 64-bit values	Applicable
LCK00-J. Use private final lock objects to synchronize classes that may interact with untrusted code	Applicable in principle
LCK01-J. Do not synchronize on objects that may be reused	Applicable
LCK02-J. Do not synchronize on the class object returned by getClass()	Applicable
LCK03-J. Do not synchronize on the intrinsic locks of high-level concurrency objects	Applicable
LCK04-J. Do not synchronize on a collection view if the backing collection is accessible	Applicable
LCK05-J. Synchronize access to static fields that can be modified by untrusted code	Applicable in principle
LCK06-J. Do not use an instance lock to protect shared static data	Applicable
LCK07-J. Avoid deadlock by requesting and releasing locks in the same order	Applicable
LCK08-J. Ensure actively held locks are released on exceptional conditions	Applicable
LCK09-J. Do not perform operations that can block while holding a lock	Applicable
LCK10-J. Do not use incorrect forms of the double-checked locking idiom	Applicable
LCK11-J. Avoid client-side locking when using classes that do not commit to their locking strategy	Applicable in principle
THI00-J. Do not invoke Thread.run()	Applicable	Android provides a couple of solutions for threading. The Android Developers Blog's article "Painless threading" discusses those solutions.
THI01-J. Do not invoke ThreadGroup methods	Applicable
THI02-J. Notify all waiting threads rather than a single thread	Applicable in principle
THI03-J. Always invoke wait() and await() methods inside a loop	Applicable in principle
THI04-J. Ensure that threads performing blocking operations can be terminated	Applicable in principle
THI05-J. Do not use Thread.stop() to terminate threads	Applicable	On Android, `Thread.stop()` was deprecated in API level 1.
TPS00-J. Use thread pools to enable graceful degradation of service during traffic bursts	Applicable in principle
TPS01-J. Do not execute interdependent tasks in a bounded thread pool	Applicable in principle
TPS02-J. Ensure that tasks submitted to a thread pool are interruptible	Applicable in principle
TPS03-J. Ensure that tasks executing in a thread pool do not fail silently	Applicable in principle
TPS04-J. Ensure ThreadLocal variables are reinitialized when using thread pools	Applicable in principle
TSM00-J. Do not override thread-safe methods with methods that are not thread-safe	Applicable in principle
TSM01-J. Do not let the this reference escape during object construction	Applicable in principle
TSM02-J. Do not use background threads during class initialization	Applicable in principle
TSM03-J. Do not publish partially initialized objects	Applicable
FIO00-J. Do not operate on files in shared directories	Applicable in principle	On Android, the SD card ( `/sdcard` or `/mnt/sdcard` ) is shared among multiple applications, thus sensitive files should not be stored on the SD card.
FIO01-J. Create files with appropriate access permissions	Applicable in principle	Creating files with weak permissions may allow malicious applications to access the files.
FIO02-J. Detect and handle file-related errors	Applicable
FIO03-J. Remove temporary files before termination	Applicable
FIO04-J. Release resources when they are no longer needed	Applicable in principle	The compliant solution (Java SE 7: `try`-with-resources) is not yet supported at API level 18 (Android 4.3).
FIO05-J. Do not expose buffers created using the wrap() or duplicate() methods to untrusted code	Applicable
FIO06-J. Do not create multiple buffered wrappers on a single InputStream	Applicable in principle
FIO07-J. Do not let external processes block on IO buffers	Applicable
FIO08-J. Use an int to capture the return value of methods that read a character or byte	Applicable
FIO09-J. Do not rely on the write() method to output integers outside the range 0 to 255	Applicable
FIO10-J. Ensure the array is filled when using read() to fill an array	Applicable
FIO11-J. Do not attempt to read raw binary data as character data	Applicable
FIO12-J. Provide methods to read and write little-endian data	Applicable
FIO13-J. Do not log sensitive information outside a trust boundary	Applicable in principle	DRD04-J. Do not log sensitive information is an Android specific instance of this rule.
FIO14-J. Perform proper cleanup at program termination	Applicable in principle	Although most of the code examples are not applicable to the Android platform, the principle is applicable to Android. There are a number of ways to terminate a process on Android: `android.app.Activity.finish()`, and the related `finish...` methods, `android.app.Activity.moveTaskToBack(boolean flag)`, `android.os.Process.killProcess(int pid)`, `System.exit()`.
FIO15-J. Do not operate on untrusted file links	Applicable in principle
SER00-J. Enable serialization compatibility during class evolution	Applicable
SER01-J. Do not deviate from the proper signatures of serialization methods	Applicable
SER02-J. Sign then seal sensitive objects before sending them outside a trust boundary	Applicable
SER03-J. Do not serialize unencrypted, sensitive data	Applicable
SER04-J. Do not allow serialization and deserialization to bypass the security manager	Not applicable	The `java.security` package exists on Android for compatibility purposes only and it should not be used.
SER05-J. Do not serialize instances of inner classes	Applicable
SER06-J. Make defensive copies of private mutable components during deserialization	Applicable
SER07-J. Do not use the default serialized form for classes with implementation-defined invariants	Applicable
SER08-J. Minimize privileges before deserializing from a privileged context	Applicable
SER09-J. Do not invoke overridable methods from the readObject() method	Applicable
SER10-J. Avoid memory and resource leaks during serialization	Applicable
SER11-J. Prevent overwriting of externalizable objects	Applicable
SEC00-J. Do not allow privileged blocks to leak sensitive information across a trust boundary	Not applicable	The `java.security` package exists on Android for compatibility purposes only and it should not be used.
SEC01-J. Do not allow tainted variables in privileged blocks	Applicable in principle	The code examples using the `java.security` package are not applicable to Android but the principle of the rule is applicable to Android apps.
SEC02-J. Do not base security checks on untrusted sources	Applicable in principle	The code examples using the `java.security` package are not applicable to Android but the principle of the rule is applicable to Android apps.
SEC03-J. Do not load trusted classes after allowing untrusted code to load arbitrary classes	Applicable in principle	On Android, the use of `DexClassLoader` or `PathClassLoader` requires caution.
SEC04-J. Protect sensitive operations with security manager checks	Not applicable	The `java.security` package exists on Android for compatibility purposes only and it should not be used.
SEC05-J. Do not use reflection to increase accessibility of classes, methods, or fields	Applicable in principle	Reflection can be used on Android so the rule is applicable. Also the use of reflection may allow a developer to access private Android APIs and so requires caution.
SEC06-J. Do not rely on the default automatic signature verification provided by URLClassLoader and java.util.jar	Not applicable
SEC07-J. Call the superclass's getPermissions() method when writing a custom class loader	Not applicable	The `java.security` package exists on Android for compatibility purposes only and it should not be used.
JNI 00-J. Define wrappers around native methods	Applicable
JNI 02-J. Do not assume object references are constant or unique	Applicable
JNI 03-J. Do not use direct pointers to Java objects in JNI code	Applicable in principle	Applicable to API versions 14 and above, with NDK versions 7 and above.
JNI04-J. Do not assume that Java strings are null-terminated	Applicable
ENV00-J. Do not sign code that performs only unprivileged operations	Not applicable	The Android system uses code signing as a means of identifying the author of an application and establishing trust relationships between applications, not as a means of granting elevated privileges to code.
ENV01-J. Place all security-sensitive code in a single JAR and sign and seal it	Not applicable	`java.security.AccessController` exists on Android for compatibility purposes only and it should not be used.
ENV02-J. Do not trust the values of environment variables	Applicable in principle	On Android, the environment variable `user.name` is not used and is left blank. However, environment variables exist and are used on Android so the rule is applicable.
ENV03-J. Do not grant dangerous combinations of permissions	Not applicable	The `java.security` package exists on Android for compatibility purposes only and it should not be used. Android uses another permission mechanism for security purposes.
ENV04-J. Do not disable bytecode verification	Applicable in principle	Under the default settings, bytecode verification is enabled on the Dalvik VM. To change the settings use the adb shell to set the appropriate system property, for example: `adb shell setprop dalvik.vm.dexopt-flags v=a` or pass `-Xverify:all` as an argument to the Dalvik VM.
ENV05-J. Do not deploy an application that can be remotely monitored	Not applicable	JVMTI is not supported on the Dalvik VM.
MSC00-J. Use SSLSocket rather than Socket for secure data exchange	Applicable
MSC01-J. Do not use an empty infinite loop	Applicable
MSC02-J. Generate strong random numbers	Applicable
MSC03-J. Never hard code sensitive information	Applicable in principle	Hard coded information can be easily obtained on Android by using the `apktool` to decompile an application or by using `dex2jar` to convert a dex file to a jar file.
MSC04-J. Do not leak memory	Applicable
MSC05-J. Do not exhaust heap space	Applicable
MSC06-J. Do not modify the underlying collection when an iteration is in progress	Applicable
MSC07-J. Prevent multiple instantiations of singleton objects	Applicable

Recommendations

Do not use deprecated or obsolete classes or methods	The Android SDK also has deprecated or obsolete APIs. Also, there may exist incompatible APIs depending on the SDK version. Therefore, it is recommended that developers refer to the "Android API Difference report" and consider replacing the deprecated APIs.
MET03-J. Methods that perform a security check must be declared private or final	On Android, `System.getSecurityManager()` is not used and the use of a Security Manager is not exercised. However, an Android developer can implement security-sensitive methods so the principle may be applicable on Android.
ERR09-J. Do not allow untrusted code to terminate the JVM	On Android, `System.exit()` should not be used because it will terminate the virtual machine abruptly, ignoring the activity lifecycle which may prevent proper garbage collection.
LCK00-J. Use private final lock objects to synchronize classes that may interact with untrusted code
LCK05-J. Synchronize access to static fields that can be modified by untrusted code
LCK11-J. Avoid client-side locking when using classes that do not commit to their locking strategy
THI00-J. Do not invoke Thread.run()	Android provides a couple of solutions for threading. The Android Developers Blog's article "Painless threading" discusses those solutions.
THI02-J. Notify all waiting threads rather than a single thread
THI03-J. Always invoke wait() and await() methods inside a loop
THI04-J. Ensure that threads performing blocking operations can be terminated
THI05-J. Do not use Thread.stop() to terminate threads	On Android, `Thread.stop()` was deprecated in API level 1.
TPS00-J. Use thread pools to enable graceful degradation of service during traffic bursts
TPS01-J. Do not execute interdependent tasks in a bounded thread pool
TPS02-J. Ensure that tasks submitted to a thread pool are interruptible
TPS03-J. Ensure that tasks executing in a thread pool do not fail silently
TPS04-J. Ensure ThreadLocal variables are reinitialized when using thread pools
TSM00-J. Do not override thread-safe methods with methods that are not thread-safe
TSM01-J. Do not let the this reference escape during object construction
TSM02-J. Do not use background threads during class initialization
FIO00-J. Do not operate on files in shared directories	On Android, the SD card ( `/` `sdcard` or `/mnt/ sdcard` ) is shared among multiple applications, thus sensitive files should not be stored on the SD card.
FIO01-J. Create files with appropriate access permissions	Creating files with weak permissions may allow malicious applications to access the files.
FIO04-J. Release resources when they are no longer needed	The compliant solution (Java SE 7: `try`-with-resources) is not yet supported at API level 18 (Android 4.3).
FIO06-J. Do not create multiple buffered wrappers on a single InputStream
FIO13-J. Do not log sensitive information outside a trust boundary	DRD04-J. Do not log sensitive information is an Android specific instance of this rule.
FIO14-J. Perform proper cleanup at program termination	Although most of the code examples are not applicable to the Android platform, the principle is applicable to Android. There are a number of ways to terminate a process on Android: `android.app.Activity.finish()`, and the related `finish...` methods, `android.app.Activity.moveTaskToBack(boolean flag)`, `android.os.Process.killProcess(int pid)`, `System.exit()`.
FIO15-J. Do not operate on untrusted file links
SEC01-J. Do not allow tainted variables in privileged blocks	The code examples using the `java.security` package are not applicable to Android but the principle of the rule is applicable to Android apps.
SEC02-J. Do not base security checks on untrusted sources	The code examples using the `java.security` package are not applicable to Android but the principle of the rule is applicable to Android apps.
SEC03-J. Do not load trusted classes after allowing untrusted code to load arbitrary classes	On Android, the use of `DexClassLoader` or `PathClassLoader` requires caution.
SEC05-J. Do not use reflection to increase accessibility of classes, methods, or fields	Reflection can be used on Android so the rule is applicable. Also the use of reflection may allow a developer to access private Android APIs and so requires caution.
JNI 03-J. Do not use direct pointers to Java objects in JNI code	Applicable to API versions 14 and above, with NDK versions 7 and above.
ENV02-J. Do not trust the values of environment variables	On Android, the environment variable `user.name` is not used and is left blank. However, environment variables exist and are used on Android so the rule is applicable.
ENV04-J. Do not disable bytecode verification	Under the default settings, bytecode verification is enabled on the Dalvik VM. To change the settings use the adb shell to set the appropriate system property, for example: `adb shell setprop dalvik.vm.dexopt-flags v=a` or pass `-Xverify:all` as an argument to the Dalvik VM.
MSC03-J. Never hard code sensitive information	Hard coded information can be easily obtained on Android by using the `apktool` to decompile an application or by using `dex2jar` to convert a dex file to a jar file.

Recommendations/Applicable in Principle to Android

Guideline	Comments
MSC59-J. Limit the lifetime of sensitive data	The non-compliant code example is probably not problematic on Dalvik because each app has its own Dalvik VM and string objects would not be accessible from other apps (?)
SEC55-J. Ensure security-sensitive methods are called with validated arguments	On Android, `accessControlContext` is not available.
IDS56-J. Prevent arbitrary file upload
IDS51-J. Properly encode or escape output
IDS52-J. Prevent code injection	`ScriptEngineManager` is not included in the Android SDK.
IDS54-J. Prevent LDAP injection	Applicable in principle for android apps that tries to implement its own LDAP
SEC50-J. Avoid granting excess privileges	The brief phrase for the guideline applies to Android. However, the current extended-text description for the guideline in the hardcopy book does not apply to Android, because Android does not use `AccessController`. The following text supplements that section, to make it applicable to Android.: An application should use as few "`<uses-permission>`"s in AndroidManifest.xml as possible. App developers should also avoid signature/system/dangerous permissions, and having a shared system UID. System API calls are code running as system, and apps which make system API calls require standard permissions the app must specify in the application manifest with "`<uses-permission>`". http://developer.android.com/guide/topics/manifest/uses-permission-element.html
SEC51-J. Minimize privileged code	The brief phrase for the guideline applies to Android. However, the current extended-text description for the guideline in the hardcopy book does not apply to Android, because Android does not use `AccessController`. The following text supplements that section, to make it applicable to Android.: Minimize the code running as system, with permissions defined in another app’s manifest, or in shared user ID applications. System API calls are code running as system, and apps which make system API calls require standard permissions the app must specify in the application manifest with "`<uses-permission>`". Only applications which are signed with the same signature and also request the same `sharedUserID` are granted a shared user ID. Data/files stored by apps which share a user ID are accessible to all those apps. http://developer.android.com/guide/topics/security/permissions.html http://developer.android.com/guide/topics/manifest/uses-permission-element.html
SEC53-J. Define custom security permissions for fine-grained security	The brief phrase for the guideline applies to Android. However, the current extended-text description for the guideline in the hardcopy book does not apply to Android. The following text supplements that section, to make it applicable to Android.: Applications are able to define their own new permissions, to restrict access to their components by other applications. Applications indicate the procedure the system should follow when determining whether to grant another app the permission, depending on `protectionLevel` – e.g., setting `protectionLevel` to “`signature`” so it is automatically granted to other applications requesting the permission which are signed with the same key. In addition to defining their own new permissions, applications can declare the requirement for (self-defined, other-app-defined, or system-defined) permissions, to restrict access to their components by other applications.
FIO51-J. Identify files using multiple file attributes	On Android, better to use `openFileOutput`/`openFileInput` for file I/O.
MSC60-J. Do not use assertions to verify the absence of runtime errors	On Android, `assert()` is ignored by default.
FIO50-J. Do not make assumptions about file creation	On Android, `java.nio.file` is not available.

Guideline

Applicable to Android Application Development?

Comments

MSC59-J. Limit the lifetime of sensitive dataApplicable in principleThe non-compliant code example is probably not problematic on Dalvik because each app has its own Dalvik VM and string objects would not be accessible from other apps (?)FIO52-J. Do not store unencrypted sensitive information on the client sideApplicable OBJ56-J. Provide sensitive mutable classes with unmodifiable wrappersUnknown?SEC55-J. Ensure security-sensitive methods are called with validated argumentsApplicable in principleOn Android, accessControlContext is not available.IDS56-J. Prevent arbitrary file uploadApplicable in principle IDS51-J. Properly encode or escape outputApplicable in principle IDS52-J. Prevent code injectionApplicable in principleScriptEngineManager is not included in the Android SDK.IDS53-J. Prevent XPath InjectionApplicable IDS54-J. Prevent LDAP injectionApplicable in principleApplicable in principle for android apps that tries to implement its own LDAPMET52-J. Do not use the clone method to copy untrusted method parametersApplicable MET56-J. Do not use Object.equals() to compare cryptographic keysApplicable MSC61-J. Do not use insecure or weak cryptographic algorithmsApplicable MSC62-J. Store passwords using a hash functionApplicable MSC63-J. Ensure SecureRandom is properly seededApplicable OBJ57-J. Do not rely on overridden methods provided by untrusted codeApplicable SEC50-J. Avoid granting excess privilegesApplicable in principleThe brief phrase for the guideline applies to Android. However, the current extended-text description for the guideline in the hardcopy book does not apply to Android, because Android does not use AccessController. The following text supplements that section, to make it applicable to Android.: An application should use as few "<uses-permission>"s in AndroidManifest.xml as possible. App developers should also avoid signature/system/dangerous permissions, and having a shared system UID. System API calls are code running as system, and apps which make system API calls require standard permissions the app must specify in the application manifest with "<uses-permission>". http://developer.android.com/guide/topics/manifest/uses-permission-element.html SEC51-J. Minimize privileged codeApplicable in principleThe brief phrase for the guideline applies to Android. However, the current extended-text description for the guideline in the hardcopy book does not apply to Android, because Android does not use AccessController. The following text supplements that section, to make it applicable to Android.: Minimize the code running as system, with permissions defined in another app’s manifest, or in shared user ID applications. System API calls are code running as system, and apps which make system API calls require standard permissions the app must specify in the application manifest with "<uses-permission>". Only applications which are signed with the same signature and also request the same sharedUserID are granted a shared user ID. Data/files stored by apps which share a user ID are accessible to all those apps.

http://developer.android.com/guide/topics/security/permissions.html

http://developer.android.com/guide/topics/manifest/uses-permission-element.html

SEC52-J. Do not expose methods that use reduced-security checks to untrusted codeNot applicable SEC53-J. Define custom security permissions for fine-grained securityApplicable in principleThe brief phrase for the guideline applies to Android. However, the current extended-text description for the guideline in the hardcopy book does not apply to Android. The following text supplements that section, to make it applicable to Android.: Applications are able to define their own new permissions, to restrict access to their components by other applications. Applications indicate the procedure the system should follow when determining whether to grant another app the permission, depending on protectionLevel – e.g., setting protectionLevel to “signature” so it is automatically granted to other applications requesting the permission which are signed with the same key. In addition to defining their own new permissions, applications can declare the requirement for (self-defined, other-app-defined, or system-defined) permissions, to restrict access to their components by other applications.SEC54-J. Create a secure sandbox using a security managerNot applicable SEC57-J. Do not let untrusted code misuse privileges of callback methodsUnknown DCL53-J. Minimize the scope of variablesApplicable MSC50-J. Minimize the scope of the @SuppressWarnings annotationApplicable OBJ51-J. Minimize the accessibility of classes and their membersApplicable CON52-J. Document thread-safety and use annotations where applicableApplicable MET54-J. Always provide feedback about the resulting value of a methodApplicable FIO51-J. Identify files using multiple file attributesApplicable in principleOn Android, better to use openFileOutput/openFileInput for file I/O.DCL56-J. Do not attach significance to the ordinal associated with an enumApplicable NUM52-J. Be aware of numeric promotion behaviorApplicable DCL58-J. Enable compile-time type checking of variable arity parameter typesApplicable DCL59-J. Do not apply public final to constants whose value might change in later releasesApplicable DCL60-J. Avoid cyclic dependencies between packagesApplicable ERR51-J. Prefer user-defined exceptions over more general exception typesApplicable ERR53-J. Try to gracefully recover from system errorsApplicable MSC53-J. Carefully design interfaces before releasing themApplicable OBJ52-J. Write garbage-collection-friendly codeApplicable DCL51-J. Do not shadow or obscure identifiers in subscopesApplicable DCL52-J. Do not declare more than one variable per declarationApplicable DCL54-J. Use meaningful symbolic constants to represent literal values in program logicApplicable DCL55-J. Properly encode relationships in constant definitionsApplicable MET55-J. Return an empty array or collection instead of a null value for methods that return an array or collectionApplicable ERR50-J. Use exceptions only for exceptional conditionsApplicable ERR54-J. Use a try-with-resources statement to safely handle closeable resourcesNot applicableThe current Android SDK does not support Java7, thus try-with-resource is not availableMSC60-J. Do not use assertions to verify the absence of runtime errorsApplicable in principleOn Android, assert() is ignored by default.EXP55-J. Use the same type for the second and third operands in conditional expressionsApplicable SEC56-J. Do not serialize direct handles to system resourcesApplicable MSC58-J. Prefer using iterators over enumerationsApplicable OBJ53-J. Do not use direct buffers for short-lived, infrequently used objectsApplicable OBJ55-J. Remove short-lived objects from long-lived container objectsApplicable DCL50-J. Be careful using visually misleading identifiers and literalsApplicable DCL57-J. Avoid ambiguous overloading of variable arity methodsApplicable ERR52-J. Avoid in-band error indicatorsApplicable EXP51-J. Do not perform assignments in conditional expressionsApplicable EXP52-J. Use braces for the body of an if, for, or while statementApplicable MSC51-J. Do not place a semicolon immediately following an if, for, or while conditionApplicable MSC52-J. Finish every set of statements associated with a case label with a break statementApplicable MSC54-J. Avoid inadvertent wrapping of loop countersApplicable EXP53-J. Use parentheses for precedence of operationApplicable FIO50-J. Do not make assumptions about file creationApplicable in principleOn Android, java.nio.file is not available.NUM50-J. Convert integers to floating-point for floating-point operationsApplicable MET53-J. Ensure that the clone() method calls super.clone()Applicable MSC55-J. Use comments consistently and in a readable fashionApplicable MSC56-J. Detect and remove superfluous code and valuesApplicable MSC57-J. Strive for logical completenessApplicable CON50-J. Do not assume that declaring a reference volatile guarantees safe publication of the members of the referenced objectApplicable CON51-J. Do not assume that the sleep(), yield(), or getState() methods provide synchronization semanticsApplicable NUM51-J. Do not assume that the remainder operator always returns a nonnegative result for integral operandsApplicable EXP50-J. Do not confuse abstract object equality with reference equalityApplicable EXP54-J. Understand the differences between bitwise and logical operatorsApplicable IDS55-J. Understand how escape characters are interpreted when strings are loadedApplicable MET50-J. Avoid ambiguous or confusing uses of overloadingApplicable MET51-J. Do not use overloaded methods to differentiate between runtime typesApplicable OBJ50-J. Never confuse the immutability of a reference with that of the referenced objectApplicable FIO53-J. Use the serialization methods writeUnshared() and readUnshared() with careApplicable OBJ54-J. Do not attempt to help the garbage collector by setting local reference variables to nullApplicable

Bibliography

[Long 2013]

Java Coding Guidelines: 75 Recommendations for Reliable and Secure Programs

Image Added Image Modified CERT Oracle Coding Standard for Java Image Removed Image Added

Space shortcuts

Page tree

Versions Compared

Old Version 19

New Version Current

Key

Rules/Applicable in Principle to Android

Recommendations

Recommendations/Applicable in Principle to Android

Guideline

Applicable to Android Application Development?

Comments

Bibliography

Space shortcuts

Page tree

Page History

Versions Compared

Old Version 19

New Version Current

Key

Rules/Applicable in Principle to Android

Recommendations

Recommendations/Applicable in Principle to Android

Guideline

Applicable to Android Application Development?

Comments

Bibliography