text: The code styles below are strict rules for contributing Java code to the Android Open Source Project (AOSP). Contributions to the Android platform that do not adhere to these rules are generally not accepted. We recognize that not all existing code follows these rules, but we expect all new code to be compliant.
  Java language rules
  Android follows standard Java coding conventions with the additional rules described below.
  Don't ignore exceptions
  It can be tempting to write code that completely ignores an exception, such as:
  void setServerPort(String value) { try { serverPort = Integer.parseInt(value); } catch (NumberFormatException e) { } }
  Do not do this. While you may think your code will never encounter this error condition or that it is not important to handle it, ignoring exceptions as above exception
  It can also! }
  Do not do this. In almost all cases it is inappropriate to catch generic Exception or Throwable (preferably not Throwable because it includes Error exceptions). It is very dangerous because it means that Exceptions you never expected (including RuntimeExceptions like ClassCastException) get caught in application-level error handling. It obscures the failure handling properties of your code, meaning if someone adds a new type of Exception in the code you're calling, the compiler won't help you realize you need to handle the error differently. In most cases you shouldn't be handling different types of exception very carefully before doing this, though, and put in comments explaining why it is safe in this place.
  Alternatives to catching generic Exception:
  - Catch each exception separately as part of a multi-catch block, for example:
  try { ... } catch (ClassNotFoundException | NoSuchMethodException e) { ... }
  -!.*;
  Potentially reduces the number of import statements.
  import foo.Bar;
  Makes it obvious what classes are actually do does not currently enforce a specific style for writing Javadoc comments, but you should follow the instructions. By doing so, you increase the readability and maintainability of your code and reduce the likelihood of error. Each variable should be declared in the innermost block that encloses all uses of the variable.
  Local variables should be declared at the cannot, even this case can be avoided));
  Loop variables should be declared in the for statement itself unless there (e.g..
  This style was chosen such that:
  - The imports people want to look at first tend to be at the top (
  android).
  - The imports
  Braces do not go on their own line; they go on the same line as the code before them: (e.g. @Override) can be listed on the same line with the language element. If there are multiple annotations, or parameterized annotations, they should each be listed one-per-line in alphabetical order.
  Android standard practices for the three predefined annotations in Java are:
  @Deprecated: The @Deprecated annotation must be used whenever the use of the annotated element is discouraged. If you use the @Deprecated annotation, you must also have a @deprecated Javadoc tag and it should name an alternate implementation. In addition, remember that a @Deprecated method is still supposed to work. If you see old code that has a @deprecated Javadoc tag, please add the @Deprecated annotation.
   be used only under circumstances where it is impossible to eliminate a warning. If a warning passes this "impossible to eliminate" test, the @SuppressWarnings annotation must be used, so as to ensure that all warnings reflect actual problems in the code.
  When a @SuppressWarnings annotation is necessary, it must be prefixed with a TODO comment that explains the "impossible to eliminate" condition. This will normally identify an offending class that has an awkward interface. For example:
  // TODO: The third-party class com.third.useful.Utility.rotate() needs generics @SuppressWarnings("generic-cast") List<String> blix = Utility.rotate(blax);
  When a @SuppressWarnings annotation is required, the code should be refactored to isolate the software elements where the annotation applies.
  Treat acronyms as words
  Treat acronyms and abbreviations as words in naming variables, methods, and classes to make names more readable:
  As both the JDK and the Android code bases are very inconsistent around acronyms, it is virtually impossible to be consistent with the surrounding code. Therefore, always treat acronyms as words. logging is necessary, it has a significantly negative impact on performance and quickly loses its usefulness if not kept reasonably terse. The logging facilities provides five different levels of logging:
  ERROR: Use when something fatal has happened, i.e. something will have user-visible consequences and won't be recoverable without explicitly deleting some data, uninstalling applications, wiping the data partitions or reflashing the entire device (or worse). This level is always logged. Issues that justify some logging at the ERROR level are typically good candidates to be reported to a statistics-gathering server.
  WARNING: Use when something serious and unexpected happened, i.e. something that will have user-visible consequences but is likely to be recoverable without data loss by performing some explicit action, ranging from waiting or restarting an app all the way to re-downloading a new version of an application or rebooting the device. This level is always logged. Issues that justify some logging at the WARNING level might also be considered for reporting to a statistics-gathering server.
  INFORMATIVE:Use to note that something interesting to most people happened, i.e. when a situation is detected that is likely to have widespread impact, though isn't necessarily an error. Such a condition should only be logged by a module that reasonably believes that it is the most authoritative in that domain (to avoid duplicate logging by non-authoritative components). This level is always logged.
  DEBUG: Use to further note what is happening on the device that could be relevant to investigate and debug unexpected behaviors. You should log only what is needed to gather enough information about what is going on about your component. If your debug logs are dominating the log then you probably should be using verbose logging.
  This level will be logged, even on release builds, and is required to be surrounded by an
  if (LOCAL_LOG)or
  if LOCAL_LOGD)block, where
  LOCAL_LOG[D]is defined in your class or subcomponent, so that there can exist a possibility to disable all such logging. There must therefore be no active logic in an
  if (LOCAL_LOG)block. All the string building for the log also needs to be placed inside the
  if (LOCAL_LOG)block. The logging call should not be re-factored out into a method call if it is going to cause the string building to take place outside of the
  if (LOCAL_LOG)block.
  There is some code that still says
  if (localLOGV). This is considered acceptable as well, although the name is nonstandard.
  VERBOSE: Use for everything else. This level will only be logged on debug builds and should be surrounded by an
  if (LOCAL_LOGV)block (or equivalent) so it can be compiled out by default. Any string building will be stripped out of release builds and needs to appear inside the
  if (LOCAL_LOGV)block.
  Notes
  - Within a given module, other than at the VERBOSE level, level, when a lower-level module detects invalid data coming from a higher-level module, the lower-level module should only log this situation to the DEBUG log, and only if logging provides information that is not otherwise available to the caller. Specifically, there is no need to log situations where an exception is thrown (the exception should contain all the relevant information), or where the only information being logged is contained in an error code. This is especially important in the interaction between the framework and applications, and conditions caused by third-party applications that are properly handled by the framework should not trigger logging higher than the DEBUG level. The only situations that should trigger logging at the INFORMATIVE level or higher is when a module or application, fully expected, and should not be logged gratuitously. A loss of network connectivity that has consequences within an app should be logged at the DEBUG or VERBOSE level (depending on whether the consequences are serious enough and unexpected enough to be logged in a release build).
  - Having a full filesystem on a filesystem that is accessible to or on behalf of third-party applications should not be logged at a level higher than INFORMATIVE.
  - Invalid data coming from any untrusted source (including any file on shared storage, or data coming through just about any network connection) is considered expected and should not trigger any logging at a level higher than DEBUG when it's detected to be invalid (and even then logging should be as limited as possible).
  - Keep in mind that the
  +operator, when used on Strings, implicitly creates a
  StringBuilderwith the default buffer size (16 characters) and potentially other temporary String objects, i.e. that explicitly creating StringBuilders isn't more expensive than relying on the default '+' operator (and can be a lot more efficient in fact). Keep in mind that code that calls
  Log.v()is compiled and executed on release builds, including building the strings, even if the logs aren't being read.
  - Any logging that is meant to be read by other people and to be available in release builds should be terse without being cryptic, and should be reasonably understandable. This includes all logging up to the DEBUG level.
  - When possible, logging should be kept on a single line if it makes sense. Line lengths up to 80 or 100 characters are perfectly acceptable, while lengths longer than about 130 or 160 characters including the length of the tag) should be avoided if possible.
  - Logging that reports successes should never be used at levels higher than VERBOSE.
  - Temporary logging used to diagnose an issue that is hard to reproduce should be kept at the DEBUG or VERBOSE level and should be enclosed by if blocks that allow for disabling it entirely at compile time.
  - Be careful about security leaks through the log. Private information should be avoided. Information about protected content must definitely be avoided. This is especially important when writing framework code as it's not easy to know in advance what will and will not be private information or protected content.
  System.out.println()(or
  printf()for native code) should never be used. System.out and System.err get redirected to /dev/null, so your print statements will have no visible effects. However, all the string building that happens for these calls still gets executed.
  - The golden rule of logging is that your logs may not unnecessarily push other logs out of the buffer, just as others may not push out yours.
  Be consistent
  Our parting thought: the code you add to a file looks drastically different from the existing code around it, it throws readers out of their rhythm when they go to read it. Try to avoid this.
  Javatests style rules
  Follow test method naming conventions and use an underscore to separate what is being tested from the specific case being tested. This style makes it easier to see exactly)) }