The Java development guidelines in the chart below refer to guidelines in the book, "Java Coding Guidelines: 75 Recommendations for Reliable and Secure Programs".
Guideline | Applicable to Android Application Development? | Comments |
| 1. Do not store unencrypted sensitive information on the client side | Applicable | |
| 2. Limit the lifetime of sensitive data | Applicable in principle | 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 (?) |
| 3. Provide sensitive mutable classes with unmodifiable wrappers | Unknown | ? |
| 4. Ensure security-sensitive methods are called with validated arguments | Applicable in principle | On Android, accessControlContext is not available. |
| 5. Prevent arbitrary file upload | Not applicable | |
| 6. Properly encode or escape output | Applicable in principle | |
| 7. Prevent code injection | Applicable in principle | ScriptEngineManager is not included in the Android SDK. |
| 8. Prevent XPath Injection | Applicable | |
| 9. Prevent LDAP injection | Applicable in principle | Applicable in principle for android apps that tries to implement its own LDAP |
| 10. Do not use the clone method to copy untrusted method parameters | Applicable | |
11. Do not use Object.equals() to compare cryptographic keys | Applicable | |
| 12. Do not use insecure or weak cryptographic algorithms | Applicable | |
| 13. Store passwords using a hash function | Applicable | |
14. Ensure SecureRandom is properly seeded | Applicable | |
| 15. Do not rely on overridden methods provided by untrusted code | Applicable | |
| 16. Avoid granting excess privileges | Not applicable | Android does not use AccessController. |
| 17. Minimize privileged code | Not applicable | Android does not use AccessController. |
| 18. Do not expose methods that use reduced-security checks to untrusted code | Not applicable | |
| 19. Define custom security permissions for fine-grained security | Not applicable | |
| 20. Create a secure sandbox using a security manager | Not applicable | |
| 21. Do not let untrusted code misuse privileges of callback methods | Unknown | |
| 22. Minimize the scope of variables | Applicable | |
23. Minimize the scope of the @SuppressWarnings annotation | Applicable | |
| 24. Minimize the accessibility of classes and their members | Applicable | |
| 25. Document thread-safety and use annotations where applicable | Applicable | |
| 26. Always provide feedback about the resulting value of a method | Applicable | |
| 27. Identify files using multiple file attributes | Applicable in principle | On Android, better to use openFileOutput/openFileInput for file I/O. |
| 28. Do not attach significance to the ordinal associated with an enum | Applicable | |
| 29. Be aware of numeric promotion behavior | Applicable | |
| 30. Enable compile-time type checking of variable arity parameter types | Applicable | |
| 31. Do not apply public final to constants whose value might change in later releases | Applicable | |
| 32. Avoid cyclic dependencies between packages | Applicable | |
| 33. Prefer user-defined exceptions over more general exception types | Applicable | |
| 34. Try to gracefully recover from system errors | Applicable | |
| 35. Carefully design interfaces before releasing them | Applicable | |
| 36. Write garbage-collection-friendly code | Applicable | |
| 37. Do not shadow or obscure identifiers in subscopes | Applicable | |
| 38. Do not declare more than one variable per declaration | Applicable | |
| 39. Use meaningful symbolic constants to represent literal values in program logic | Applicable | |
| 40. Properly encode relationships in constant definitions | Applicable | |
| 41. Return an empty array or collection instead of a null value for methods that return an array or collection | Applicable | |
| 42. Use exceptions only for exceptional conditions | Applicable | |
43. Use a try-with-resources statement to safely handle closeable resources | Not applicable | The current Android SDK does not support Java7, thus try-with-resource is not available |
| 44. Do not use assertions to verify the absence of runtime errors | Applicable in principle | On Android, assert() is ignored by default. |
| 45. Use the same type for the second and third operands in conditional expressions | Applicable | |
| 46. Do not serialize direct handles to system resources | Applicable | |
| 47. Prefer using iterators over enumerations | Applicable | |
| 48. Do not use direct buffers for short-lived, infrequently used objects | Applicable | |
| 49. Remove short-lived objects from long-lived container objects | Applicable | |
| 50. Be careful using visually misleading identifiers and literals | Applicable | |
| 51. Avoid ambiguous overloading of variable arity methods | Applicable | |
| 52. Avoid in-band error indicators | Applicable | |
| 53. Do not perform assignments in conditional expressions | Applicable | |
| 54. Use braces for the body of an if, for, or while statement | Applicable | |
| 55. Do not place a semicolon immediately following an if, for, or while condition | Applicable | |
| 56. Finish every set of statements associated with a case label with a break statement | Applicable | |
| 57. Avoid inadvertent wrapping of loop counters | Applicable | |
| 58. Use parentheses for precedence of operation | Applicable | |
| 59. Do not make assumptions about file creation | Applicable in principle | On Android, java.nio.file is not available. |
| 60. Convert integers to floating-point for floating-point operations | Applicable | |
61. Ensure that the clone() method calls super.clone() | Applicable | |
| 62. Use comments consistently and in a readable fashion | Applicable | |
| 63. Detect and remove superfluous code and values | Applicable | |
| 64. Strive for logical completeness | Applicable | |
| 65. Do not assume that declaring a reference volatile guarantees safe publication of the members of the referenced object | Applicable | |
66. Do not assume that the sleep(), yield(), or getState() methods provide synchronization semantics | Applicable | |
| 67. Do not assume that the remainder operator always returns a nonnegative result for integral operands | Applicable | |
| 68. Do not confuse abstract object equality with reference equality | Applicable | |
| 69. Understand the differences between bitwise and logical operators | Applicable | |
| 70. Understand how escape characters are interpreted when strings are loaded | Applicable | |
| 71. Avoid ambiguous or confusing uses of overloading | Applicable | |
| 72. Do not use overloaded methods to differentiate between runtime typse | Applicable | |
| 73. Never confuse the immutability of a reference with that of the referenced object | Applicable | |
74. Use the serialization methods writeUnshared() and readUnshared() with care | Applicable | |
75. Do not attempt to help the garbage collector by setting local reference variables to null | Applicable |
Bibliography
| [Long 2013] | Java Coding Guidelines: 75 Recommendations for Reliable and Secure Programs |
ENV05-J. Do not deploy an application that can be remotely monitored The CERT Oracle Secure Coding Standard for Java MSC00-J. Use SSLSocket rather than Socket for secure data exchange