This document is intended to be a general guide for developers to use to adhere to the general principles that the API Council enforces in API reviews.
In addition to understanding and following these guidelines when writing APIs, developers should run the API Lint tool, which encodes many of these rules in checks that it runs against APIs.
Think of this as the guide to the rules that are obeyed by that Lint tool, plus guidelines and general advice on rules that cannot be easily codified into that tool.
API Lint is integrated into the Metalava static analysis tool and runs as part of the platform build. You can run it manually from an AOSP checkout with:
# Run lint on public API $ make api-stubs-docs-api-lint # Run lint on system API $ make system-api-stubs-docs-api-lint
One of the difficulties in concrete rules is applying them to a platform that was developed without strict guidelines from the beginning, so some of the existing APIs may not adhere. In some cases, the right choice might be to go with what is consistent with APIs in the same general area of the code, rather than in the ideal rules laid out herein.
The rules are a work in progress and will be added to in the future as other patterns emerge from future API reviews.
This category pertains to the general coding style that developers should use, especially in the public API.
There are Android coding conventions posted for external contributors here:
https://source.android.com/source/code-style.html
Overall, we tend to follow standard Java coding conventions.
Please also review the Kotlin-Java interop guide for best practices related to writing Kotlin-friendly APIs in Java. Some of these guidelines are reflected in the recommendations on this site; however, the link may contain slightly newer information that has not yet been propagated.
For example: method name should be runCtsTests and not runCTSTests.
ImplThis exposes implementation details, avoid that.
These are rules about classes, interfaces, and inheritance.
Inheritance exposes API in your subclass which may not be appropriate. For example, a new public subclass of FrameLayout will look like a FrameLayout (plus the new functionality/API). If that inherited API is not appropriate for your use case, inherit from something further up the tree (for example, ViewGroup or even View, instead of FrameLayout).
If you are tempted to override methods from the base class to throw @UnsupportedOperationException, reconsider which base class you are using.
Whether taking a collection as an argument or returning it as a value, always prefer the base class over the specific implementation (e.g. return List<Foo> rather than ArrayList<Foo>).
Use a base class that expresses appropriate constraints for the API. For example, an API whose collection must be ordered should use List and an API whose collection must consist of unique elements should use Set.
In Kotlin, prefer immutable collections. See Collection mutability for more details.
Java 8 adds support for default interface methods, which allows API designers to add methods to interfaces while maintaining binary compatibility. Platform code and all Jetpack libraries should target Java 8 or later.
In cases where the default implementation is stateless, API designers should prefer interfaces over abstract classes -- that is, default interface methods can be implemented as calls to other interface methods.
In cases where a constructor or internal state is required by the default implementation, abstract classes must be used.
In both cases, API designers may choose to leave a single method abstract to simplify usage as a lambda.
public interface AnimationEndCallback { // Always called, must be implemented. public void onFinished(Animation anim); // Optional callbacks. public default void onStopped(Animation anim) { } public default void onCanceled(Animation anim) { } }
For example, classes which extend Service should be named FooService for clarity.
public class IntentHelper extends Service {}
public class IntentService extends Service {}
Helper, Util, etc.)Avoid using generic class name suffixes like Helper and Util for collections of utility methods. Instead, put the methods directly in the associated classes or into Kotlin extension functions.
In cases where methods are bridging multiple classes, give the containing class a meaningful name that explains what it does.
In very limited cases, using the Helper suffix may be appropriate:
ViewFor example, if backporting tooltips requires persisting state associated with a View and calling several methods on the View to install the backport, TooltipHelper would be an acceptable class name.
CompletableFuture or Futurejava.util.concurrent.CompletableFuture has a large API surface that permits arbitrary mutation of the future's value and has error-prone defaults .
Conversely, java.util.concurrent.Future is missing non-blocking listening, making it hard to use with asynchronous code.
In platform code, prefer a combination of a completion callback, Executor, and if the API supports cancellation CancellationSignal.
public interface LoadFooCallback { void onSuccess(Foo result); void onFailure(Throwable t); } public void asyncLoadFoo(android.os.CancellationSignal cancellationSignal, Executor callbackExecutor, LoadFooCallback callback);
In libraries and apps, prefer Guava's ListenableFuture.
public com.google.common.util.concurrent.ListenableFuture<Foo> asyncLoadFoo();
If you are targeting Kotlin, prefer suspend functions.
suspend fun asyncLoadFoo(): Foo
OptionalWhile Optional can have advantages in some API surfaces it is inconsistent with the existing Android API surface area. @Nullable and @NonNull provide tooling assistance for null safety and Kotlin enforces nullability contracts at the compiler level, making Optional unnecessary API cruft.
Classes that can only be created by Builders, classes containing only constants or static methods, or otherwise non-instantiable classes should include at least one private constructor to prevent instantiation via the default no-arg constructor.
public final class Log { // Not instantiable. private Log() { } }
getInstance() methodSingleton classes must have private constructors and only be acquired through static getInstance() methods.
AutoCloseableClasses that release resources through close, release, destroy or similar methods should implement java.lang.AutoCloseable to allow developers to automatically clean up these resources when using a try-with-resources block.
These rules are about public fields on classes.
Java classes should not expose fields directly. Fields should be private and accessible only via public getters and setters regardless of whether these fields are final or non-final.
Rare exceptions include simple data structures where there will never be a need to enhance the functionality of specifying or retrieving a field. In such cases, the fields should be named using standard variable naming conventions, ex. Point.x and Point.y.
Kotlin classes may expose properties.
Raw fields are strongly discouraged (@see Do not expose raw fields). But in the rare situation where a field is exposed as a public field, mark that field final.
Do not reference internal field names in public API.
public int mFlags;
public instead of protected@see Use public instead of protected
These are rules about public constants.
int or long values“Flags” implies bits that can be combined into some union value. If this is not the case, do not call the variable/constant flag.
public static final int FLAG_SOMETHING = 2; public static final int FLAG_SOMETHING = 3;
public static final int FLAG_PRIVATE = 1 << 2; public static final int FLAG_PRESENTATION = 1 << 3;
See @IntDef for bitmask flags for more information on defining public flag constants.
static final constants should use all-cap, underscore-separated naming conventionAll words in the constant should be capitalized and multiple words should be separated by _. For example:
public static final int fooThing = 5
public static final int FOO_THING = 5
Many of the constants used in Android are for standard things, such as flags, keys, and actions. These constants should have standard prefixes to make them more identifiable as these things.
For example, intent extras should start with EXTRA_. Intent actions should start with ACTION_. Constants used with Context.bindService() should start with BIND_.
String constants values should be consistent with the constant name itself, and should generally be scoped to the package or domain. For example:
public static final String FOO_THING = “foo”
is neither named consistently nor appropriately scoped. Instead, consider:
public static final String FOO_THING = “android.fooservice.FOO_THING”
Prefixes of android in scoped string constants are reserved for the Android Open Source Project.
Intent actions and extras should be namespaced using the package name they are defined within.
package android.foo.bar { public static final String ACTION_BAZ = “android.foo.bar.action.BAZ” public static final String EXTRA_BAZ = “android.foo.bar.extra.BAZ” }
public instead of protected@see Use public instead of protected
Related constants should all start with the same prefix. For example, for a set of constants to use with flag values:
public static final int SOME_VALUE = 0x01; public static final int SOME_OTHER_VALUE = 0x10; public static final int SOME_THIRD_VALUE = 0x100;
public static final int FLAG_SOME_VALUE = 0x01; public static final int FLAG_SOME_OTHER_VALUE = 0x10; public static final int FLAG_SOME_THIRD_VALUE = 0x100;
@see Use standard prefixes for constants
Public identifiers, attributes, and values must be named using the camelCase naming convention, e.g. @id/accessibilityActionPageUp or @attr/textAppearance, similar to public fields in Java.
In some cases, a public identifier or attribute may include a common prefix separated by an underscore:
@string/config_recentsComponentName in config.xml@attr/layout_marginStart in attrs.xmlPublic themes and styles must follow the hierarchical PascalCase naming convention, e.g. @style/Theme.Material.Light.DarkActionBar or @style/Widget.Material.SearchView.ActionBar, similar to nested classes in Java.
Layout and drawable resources should not be exposed as public APIs. If they must be exposed, however, then public layouts and drawables must be named using the under_score naming convention, e.g. layout/simple_list_item_1.xml or drawable/title_bar_tall.xml.
If a MIN_FOO or MAX_FOO constant could change in the future, consider making them dynamic methods instead.
CameraManager.MAX_CAMERAS
CameraManager.getMaxCameras()
Constants defined in future API versions are not known to apps that target older APIs. For this reason, constants delivered to apps should take into consideration that app’s target API version and map newer constants to a consistent value. Consider the following scenario:
Hypothetical SDK source:
// Added in API level 22 public static final int STATUS_SUCCESS = 1; public static final int STATUS_FAILURE = 2; // Added in API level 23 public static final int STATUS_FAILURE_RETRY = 3; // Added in API level 26 public static final int STATUS_FAILURE_ABORT = 4;
Hypothetical app with targetSdkVersion="22":
if (result == STATUS_FAILURE) { // Oh no! } else { // Success! }
In this case, the app was designed within the constraints of API level 22 and made a (somewhat) reasonable assumption that there were only two possible states. If the app receives the newly-added STATUS_FAILURE_RETRY, however, it will interpret this as success.
Methods that return constants can safely handle cases like this by constraining their output to match the API level targeted by the app:
private int mapResultForTargetSdk(Context context, int result) { int targetSdkVersion = context.getApplicationInfo().targetSdkVersion; if (targetSdkVersion < 26) { if (result == STATUS_FAILURE_ABORT) { return STATUS_FAILURE; } if (targetSdkVersion < 23) { if (result == STATUS_FAILURE_RETRY) { return STATUS_FAILURE; } } } return result; }
It’s unreasonable to expect developers and their published applications to be clairvoyant. If you define an API with an UNKNOWN or UNSPECIFIED constant that looks like a catch-all, developers will assume that the published constants when they wrote their app are exhaustive. If you’re unwilling to set this expectation, reconsider whether a catch-all constant is a good idea for your API.
Consider also that libraries cannot specify their own targetSdkVersion separate from the app, and that handling targetSdkVersion behavior changes from library code is exceedingly complicated and error-prone.
String constant?Use integer constants if the namespace for values is not extensible outside of your package. Use string constants if the namespace is shared or can be extended by code outside of your package.
These are rules about various specifics in methods, around parameters, method names, return types, and access specifiers.
java.time.* types where possiblejava.time.Duration, java.time.Instant and many other java.time.* types are available on all platform versions through desugaring and should be preferred when expressing time in API parameters or return values.
Libraries targeting SDK < 26 must not use java.time.* until the AAR format supports advertising core library desugaring requirements (see b/203113147).
Prefer exposing only variants of an API that accept or return java.time.Duration or java.time.Instant and omit primitive variants with the same functionality unless the API domain is one where object allocation in intended usage patterns would have a prohibitive performance impact.
If a time value expresses the duration of time involved, name the parameter “duration”, not “time”.
ValueAnimator.setTime(java.time.Duration);
ValueAnimator.setDuration(java.time.Duration);
Exceptions:
“timeout” is appropriate when the duration specifically applies to a timeout value.
“time” with a type of java.time.Instant is appropriate when referring to a specific point in time, not a duration.
longMethods accepting or returning durations as a primitive should suffix the method name with the associated time units (e.g. Millis, Nanos, Seconds) to reserve the undecorated name for use with java.time.Duration. See Time.
Methods should also be annotated apporiately with their unit and time base:
@CurrentTimeMillisLong: Value is a non-negative timestamp measured as the number of milliseconds since 1970-01-01T00:00:00Z.@CurrentTimeSecondsLong: Value is a non-negative timestamp measured as the number of seconds since 1970-01-01T00:00:00Z.@DurationMillisLong: Value is a non-negative duration in milliseconds.@ElapsedRealtimeLong: Value is a non-negative timestamp in the SystemClock.elapsedRealtime() time base.@UptimeMillisLong: Value is a non-negative timestamp in theSystemClock.uptimeMillis() time base.Primitive time parameters or return values should use long, not int.
ValueAnimator.setDuration(@DurationMillisLong long);
ValueAnimator.setDurationNanos(long);
public void setIntervalNs(long intervalNs); public void setTimeoutUs(long timeoutUs);
public void setIntervalNanos(long intervalNanos); public void setTimeoutMicros(long timeoutMicros);
long time argumentsThe platform includes several annotations to provide stronger typing for long-type time units:
@CurrentTimeMillisLong: Value is a non-negative timestamp measured as the number of milliseconds since 1970-01-01T00:00:00Z, e.g. in the System.currentTimeMillis() time base.@CurrentTimeSecondsLong: Value is a non-negative timestamp measured as the number of seconds since 1970-01-01T00:00:00Z.@DurationMillisLong: Value is a non-negative duration in milliseconds.@ElapsedRealtimeLong: Value is a non-negative timestamp in the SystemClock#elapsedRealtime() time base.@UptimeMillisLong: Value is a non-negative timestamp in the SystemClock#uptimeMillis() time base.For all methods expressing a unit of measurement other than time, prefer CamelCased SI unit prefixes.
public long[] getFrequenciesKhz(); public float getStreamVolumeDb();
If you have overloads of a method with optional parameters, keep those parameters at the end and keep consistent ordering with the other parameters:
public int doFoo(boolean flag); public int doFoo(int id, boolean flag);
public int doFoo(boolean flag); public int doFoo(boolean flag, int id);
When adding overloads for optional arguments, the behavior of the simpler methods should behave in exactly the same way as if default arguments had been provided to the more elaborate methods.
Corollary: Don’t overload methods other than to add optional arguments or to accept different types of arguments if the method is polymorphic. If the overloaded method does something fundamentally different, then give it a new name.
Note: The guideline on placement of single abstract method parameters (ex. Runnable, listeners) overrides this guideline. In cases where a developer could reasonably expected to write the body of a SAM class as a lambda, the SAM class parameter should be placed last.
If a method has shipped with a parameter with a default value, removal of the default value is a source incompatible change.
If you have a method with multiple parameters, put the most relevant ones first. Parameters that specify flags and other options are less important than those that describe the object that is being acted upon. If there is a completion callback, put it last.
public void openFile(int flags, String name); public void openFileAsync(OnFileOpenedListener listener, String name, int flags); public void setFlags(int mask, int flags);
public void openFile(String name, int flags); public void openFileAsync(String name, int flags, OnFileOpenedListener listener); public void setFlags(int flags, int mask);
@see Put optional parameters at end in overloads
The Builder pattern is recommended for creating complex Java objects, and is commonly used in Android for cases where:
In most cases, Kotlin classes should prefer constructors with default arguments over Builders.
Builder classes must enable method chaining by returning the Builder object (e.g. this) from every method except build(). Additional built objects should be passed as arguments -- do not return a different object’s builder. For example:
public static class Builder { public void setDuration(long); public void setFrequency(int); public DtmfConfigBuilder addDtmfConfig(); public Tone build(); }
public class Tone { public static class Builder { public Builder setDuration(long); public Builder setFrequency(int); public Builder addDtmfConfig(DtmfConfig); public Tone build(); } }
To ensure consistent Builder creation through Android API surface, all the builders must be created through a constructor and not a static creator method.
public class Tone { public static Builder builder(); public static class Builder { } }
public class Tone { public static class Builder { public Builder(); } }
@NonNull)Optional, e.g. @Nullable, arguments should be moved to setter methods. The Builder constructor should throw an NullPointerException (consider using Objects.requireNonNull) if any required arguments are not specified.
For the sake of logical organization within a package, builder classes should typically be exposed as final inner classes of their built types, ex. Tone.Builder rather than ToneBuilder.
Builders may include a copy constructor to create a new builder instance from an existing builder or built object. They should not provide alternative methods for creating builder instances from existing builders or build objects.
public class Tone { public static class Builder { public Builder clone(); } public Builder toBuilder(); }
public class Tone { public static class Builder { public Builder(Builder original); public Builder(Tone original); } }
@Nullable arguments if the builder has copy constructorResetting is essential if a new instance of a builder may be created from an existing instance. If no copy constructor is available, then the builder may have either @Nullable or @NonNullable arguments.
public static class Builder { public Builder(Builder original); public Builder setObjectValue(@Nullable Object value); }
If your class has mutable properties and needs a Builder class, first ask yourself whether your class should actually have mutable properties.
Next, if you're certain that you need mutable properties, decide which of the following scenarios works better for your expected use case:
The built object should be immediately usable, thus setters should be provided for all relevant properties whether mutable or immutable.
map.put(key, new Value.Builder(requiredValue) .setImmutableProperty(immutableValue) .setUsefulMutableProperty(usefulValue) .build());
Some additional calls may need to be made before the built object can be useful, thus setters should not be provided for mutable properties.
Value v = new Value.Builder(requiredValue) .setImmutableProperty(immutableValue) .build(); v.setUsefulMutableProperty(usefulValue) Result r = v.performSomeAction(); Key k = callSomeMethod(r); map.put(k, v);
Don't mix the two scenarios.
Value v = new Value.Builder(requiredValue) .setImmutableProperty(immutableValue) .setUsefulMutableProperty(usefulValue) .build(); Result r = v.performSomeAction(); Key k = callSomeMethod(r); map.put(k, v);
Getter should be on the built object, not the builder.
public class Tone { public static class Builder { public Builder setDuration(long); public Builder setFrequency(int); public Builder addDtmfConfig(DtmfConfig); public Tone build(); } }
public class Tone { public static class Builder { public Builder setDuration(long); public Builder setFrequency(int); public Builder addDtmfConfig(DtmfConfig); public Tone build(); } public long getDuration(); public int getFrequency(); public @NonNull List<DtmfConfig> getDtmfConfigs(); }
Builder methods names should use setFoo() / addFoo() / clearFoo() style.
Methods in the public API should not use the synchronized keyword. This keyword causes your object/class to be used as the lock, and since it’s exposed to others, you may encounter unexpected side effects if other code outside your class starts using it for locking purposes.
Instead, perform any required locking against an internal, private object.
public synchronized void doThing() { ... }
private Object mThingLock = new Object(); public void doThing() { synchronized (mThingLock) { ... } }
is prefix for boolean accessor methodsThis is the standard naming convention for boolean methods and fields in Java. Generally, boolean method and variable names should be written as questions that are answered by the return value.
Java boolean accessor methods should follow a set/is naming scheme and fields should prefer is, as in:
// Visibility is a direct property. The object "is" visible: void setVisible(boolean visible); boolean isVisible(); // Factory reset protection is an indirect property. void setFactoryResetProtectionEnabled(boolean enabled); boolean isFactoryResetProtectionEnabled(); final boolean isAvailable;
Using set/is for Java accessor methods or is for Java fields will allow them to be used as properties from Kotlin:
obj.isVisible = true obj.isFactoryResetProtectionEnabled = false if (!obj.isAvailable) return
Properties and accessor methods should generally use positive naming, e.g. Enabled rather than Disabled. Using negative terminology inverts the meaning of true and false and makes it more difficult to reason about behavior.
// Passing false here is a double-negative. void setFactoryResetProtectionDisabled(boolean disabled);
In cases where the boolean describes inclusion or ownership of a property, you may use has rather than is; however, this will not work with Kotlin property syntax:
// Transient state is an indirect property used to track state // related to the object. The object is not transient; rather, // the object "has" transient state associated with it: void setHasTransientState(boolean hasTransientState); boolean hasTransientState();
Some alternative prefixes that may be more suitable include can and should:
// "Can" describes a behavior that the object may provide, // and here is more concise than setRecordingEnabled or // setRecordingAllowed. The object "can" record: void setCanRecord(boolean canRecord); boolean canRecord(); // "Should" describes a hint or property that is not strictly // enforced, and here is more explicit than setFitWidthEnabled. // The object "should" fit width: void setShouldFitWidth(boolean shouldFitWidth); boolean shouldFitWidth();
Methods that toggle behaviors or features may use the is prefix and Enabled suffix:
// "Enabled" describes the availability of a property, and is // more appropriate here than "can use" or "should use" the // property: void setWiFiRoamingSettingEnabled(boolean enabled) boolean isWiFiRoamingSettingEnabled()
Generally, method names should be written as questions that are answered by the return value.
For a class property var foo: Foo Kotlin will autogenerate get/set methods using a simple rule: prepend get and uppercase the first character for the getter, and prepend set and uppercase the first character for the setter. The above declaration will produce methods named public Foo getFoo() and public void setFoo(Foo foo), respectively.
If the property is of type Boolean an additional rule applies in name generation: if the property name begins with is, then get is not prepended for the getter method name, the property name itself is used as the getter. Therefore, prefer naming Boolean properties with an is prefix in order to follow the naming guideline above:
var isVisible: Boolean
If your property is one of the aforementioned exceptions and begins with an appropriate prefix, use the @get:JvmName annotation on the property to manually specify the appropriate name:
@get:JvmName("hasTransientState") var hasTransientState: Boolean @get:JvmName("canRecord") var canRecord: Boolean @get:JvmName("shouldFitWidth") var shouldFitWidth: Boolean
See Use @IntDef for bitmask flags for API guidelines regarding defining bitmask flags.
Two setter methods should be provided: one that takes a full bitstring and overwrites all existing flags and another that takes a custom bitmask to allow more flexibility.
/** * Sets the state of all scroll indicators. * <p> * See {@link #setScrollIndicators(int, int)} for usage information. * * @param indicators a bitmask of indicators that should be enabled, or * {@code 0} to disable all indicators * @see #setScrollIndicators(int, int) * @see #getScrollIndicators() */ public void setScrollIndicators(@ScrollIndicators int indicators); /** * Sets the state of the scroll indicators specified by the mask. To change * all scroll indicators at once, see {@link #setScrollIndicators(int)}. * <p> * When a scroll indicator is enabled, it will be displayed if the view * can scroll in the direction of the indicator. * <p> * Multiple indicator types may be enabled or disabled by passing the * logical OR of the desired types. If multiple types are specified, they * will all be set to the same enabled state. * <p> * For example, to enable the top scroll indicator: * {@code setScrollIndicators(SCROLL_INDICATOR_TOP, SCROLL_INDICATOR_TOP)} * <p> * To disable the top scroll indicator: * {@code setScrollIndicators(0, SCROLL_INDICATOR_TOP)} * * @param indicators a bitmask of values to set; may be a single flag, * the logical OR of multiple flags, or 0 to clear * @param mask a bitmask indicating which indicator flags to modify * @see #setScrollIndicators(int) * @see #getScrollIndicators() */ public void setScrollIndicators(@ScrollIndicators int indicators, @ScrollIndicators int mask);
One getter should be provided to obtain the full bitmask.
/**
* Returns a bitmask representing the enabled scroll indicators.
* <p>
* For example, if the top and left scroll indicators are enabled and all
* other indicators are disabled, the return value will be
* {@code View.SCROLL_INDICATOR_TOP | View.SCROLL_INDICATOR_LEFT}.
* <p>
* To check whether the bottom scroll indicator is enabled, use the value
* of {@code (getScrollIndicators() & View.SCROLL_INDICATOR_BOTTOM) != 0}.
*
* @return a bitmask representing the enabled scroll indicators
*/
@ScrollIndicators
public int getScrollIndicators();
public instead of protectedAlways prefer public to protected in public API. Protected access ends up being painful in the long run, because implementers have to override to implement the functionality in cases where external access would have been just as good.
Remember that protected visibility does not prevent developers from calling an API -- it only makes it slightly more obnoxious.
equals() and hashCode()If you override one, you must override the other.
toString() for data classesData classes are encouraged to override toString(), to help developers debug their code.
Decide whether you want program behavior to rely on your implementation or not. For example, UUID.toString() and File.toString() document their specific format for programs to use. If you are exposing information for debugging only, like Intent, simply inherit docs from the superclass.
All the information available from toString() should also be available through the public API of the object. Otherwise, you are encouraging developers to parse and rely on your toString() output, which will prevent future changes. A good practice is to implement toString() using only the object's public API.
While it's impossible to prevent developers from depending on debug output, including the System.identityHashCode of your object in its toString() output will make it very unlikely that two different objects will have equal toString() output.
@Override public String toString() { return getClass().getSimpleName() + "@" + Integer.toHexString(System.identityHashCode(this)) + " {mFoo=" + mFoo + "}"; }
This can effectively discourage developers from writing test assertions like assertThat(a.toString()).isEqualTo(b.toString()) on your objects.
createFoo when returning newly created objectsUse the prefix create, not get or new, for methods that will create return values, e.g. by constructing new objects.
When the method will create an object to return, make that clear in the method name.
public FooThing getFooThing() { return new FooThing(); }
public FooThing createFooThing() { return new FooThing(); }
File objects should also accept streamsData storage locations on Android are not always files on disk. For example, content passed across user boundaries is represented as content:// Uris. To enable processing of various data sources, APIs which accept File objects should also accept InputStream and/or OutputStream.
public void setDataSource(File file) public void setDataSource(InputStream stream)
If you need to communicate missing or null values, consider using -1, Integer.MAX_VALUE, or Integer.MIN_VALUE.
public java.lang.Integer getLength() public void setLength(java.lang.Integer)
public int getLength() public void setLength(int value)
Avoiding class equivalents of primitive types avoids the memory overhead of these classes, method access to values, and, more importantly, autoboxing that comes from casting between primitive and object types. Avoiding these behaviors saves on memory and on temporary allocations that can lead to expensive and more frequent garbage collections.
Developer annotations were added to help clarify allowable values in various situations. This makes it easier for tools to help developers when they supply incorrect values (for example, passing an arbitrary int when the framework requires one of a specific set of constant values). Use any and all of the following annotations when appropriate:
Explicit nullabilty annotations are required for Java APIs, but the concept of nullability is part of the Kotlin language and nullability annotations should never be used in Kotlin APIs.
@Nullable: Indicates that a given return value, parameter, or field can be null:
@Nullable public String getName() public void setName(@Nullable String name)
@NonNull: Indicates that a given return value, parameter, or field cannot be null. Marking things as @Nullable is relatively new to Android, so most of Android's API methods are not consistently documented. Therefore we have a tri-state of “unknown, @Nullable, @NonNull” which is why @NonNull is part of the API guidelines.:
@NonNull public String getName() public void setName(@NonNull String name)
Existing “not really nullable” methods: Existing methods in the API without a declared @Nullable annotation may be annotated @Nullable if the method can return null under specific, obvious circumstances (e.g. findViewById()). Companion @NotNull requireFoo() methods that throw IllegalArgumentException should be added for developers who do not want to null check.
Resource identifiers: Integer parameters that denote ids for specific resources should be annotated with the appropriate resource-type definition. There is an annotation for every type of resource, such as @StringRes, @ColorRes, and @AnimRes, in addition to the catch-all @AnyRes. For example:
public void setTitle(@StringRes int resId)
@IntDef for constant setsMagic constants: String and int parameters that are meant to receive one of a finite set of possible values denoted by public constants should be annotated appropriately with @StringDef or @IntDef. These annotations allow you to create a new annotation that you can use that works like a typedef for allowable parameters. For example:
/** @hide */ @IntDef(prefix = {“NAVIGATION_MODE_”}, value = { NAVIGATION_MODE_STANDARD, NAVIGATION_MODE_LIST, NAVIGATION_MODE_TABS }) @Retention(RetentionPolicy.SOURCE) public @interface NavigationMode {} public static final int NAVIGATION_MODE_STANDARD = 0; public static final int NAVIGATION_MODE_LIST = 1; public static final int NAVIGATION_MODE_TABS = 2; @NavigationMode public int getNavigationMode(); public void setNavigationMode(@NavigationMode int mode);
Notice that the constants must be defined in the class that will use them, not in a subclass or interface.
@IntDef for bitmask flagsThe annotation can also specify that the constants are flags, and can be combined with & and I:
/** @hide */ @IntDef(flag = true, prefix = { “FLAG_” }, value = { FLAG_USE_LOGO, FLAG_SHOW_HOME, FLAG_HOME_AS_UP, }); @Retention(RetentionPolicy.SOURCE) public @interface DisplayOptions {}
@StringDef for string constant setsThere is also the @StringDef annotation, which is exactly like @IntDef above, but for String constants. You can include multiple “prefix” values which are used to automatically emit documentation for all values.
@see Support Annotations (Ignore the “support” part of this document, and don’t use it in the includes; the framework has internal annotations that you should use directly. The article is intended for external developers that would be using the support library version of annotations instead).
@SdkConstant for SDK constants@SdkConstant Annotate public fields when they are one of these SdkConstant values: ACTIVITY_INTENT_ACTION, BROADCAST_INTENT_ACTION, SERVICE_ACTION, INTENT_CATEGORY, FEATURE.
@SdkConstant(SdkConstantType.ACTIVITY_INTENT_ACTION) public static final String ACTION_CALL = "android.intent.action.CALL";
Java APIs that do not have default nullability states interact poorly with Kotlin and static analysis tooling, unless explicitly annotated with @NonNull or @Nullable.
Additionally, annotating your method parameters will automatically generate documentation in the form “This value may be null.” unless “null” is explicitly used elsewhere in the parameter doc.
Methods are recommended to perform input validation for @NonNull parameters via Objects.requireNonNull() and throw a NullPointerException when the parameters are null.
To ensure API compatibility, the nullability of overrides should be compatible with the current nullability of the parent. The table below represents the compatibility expectations. Plainly, overrides should only be as restrictive or more restrictive than the element they override.
| type | parent | child |
|---|---|---|
| return type | unannotated | unannotated | non-null |
| return type | nullable | nullable | non-null |
| return type | non-null | non-null |
| fun argument | unannotated | unannotated | nullable |
| fun argument | nullable | nullable |
| fun argument | non-null | nullable | non-null |
@NonNull) arguments where possibleWhen methods are overloaded, prefer that all arguments are non-null.
public void startActivity(@NonNull Component component) { ... } public void startActivity(@NonNull Component component, @NonNull Bundle options) { ... }
This rule applies to overloaded property setters as well. The primary argument should be non-null and clearing the property should be implemented as a separate method. This prevents “nonsense” calls where the developer must set trailing parameters even though they are not required.
public void setTitleItem(@Nullable IconCompat icon, @ImageMode mode) public void setTitleItem(@Nullable IconCompat icon, @ImageMode mode, boolean isLoading) // Nonsense call to clear property setTitleItem(null, MODE_RAW, false);
public void setTitleItem(@NonNull IconCompat icon, @ImageMode mode) public void setTitleItem(@NonNull IconCompat icon, @ImageMode mode, boolean isLoading) public void clearTitleItem()
Nullable (e.g. @NonNull) return types for containersFor container types -- Bundles, Collections, etc. -- return an empty (and immutable, where applicable) container. In cases where null would be used to distinguish availability of a container, consider providing a separate boolean method.
@NonNull public Bundle getExtras() { ... }
Note: Intent.getExtras() returns a @Nullable Bundle and specifies a case where it returns null, but this was a mistake that should be avoided in future APIs.
get/set pairs must agreeGet/set method pairs for a single logical property should always agree in their nullability annotations. Failing to follow this guideline will defeat Kotlin's property syntax, and adding disagreeing nullability annotations to existing property methods is therefore a source-breaking change for Kotlin users.
@NonNull public Bundle getExtras() { ... } public void setExtras(@NonNull Bundle bundle) { ... }
All APIs should permit applications to react to errors. Returning false, -1, null, or other catch-all values of “something went wrong” do not tell a developer enough about the failure to set user expectations or accurately track reliability of their app in the field. When designing an API, imagine that you are building an application. If you encounter an error, does the API give you enough information to surface it to the user or react appropriately?
@IntDef, that means including an OTHER or UNKNOWN value - when returning a new code, you can check the caller‘s targetSdkVersion to avoid returning an error code the application doesn’t know about. For exceptions, have a common superclass that your exceptions implement, so that any code that handles that type will also catch and handle subtypes.@CheckResult.Prefer throwing a ? extends RuntimeException when a failure or error condition is reached due to something that the developer did wrong, for example ignoring constraints on input parameters or failing to check observable state.
Setter or action (ex. perform) methods may return an integer status code if the action may fail as a result of asynchronously-updated state or conditions outside the developer’s control.
Status codes should be defined on the containing class as public static final fields, prefixed with ERROR_, and enumerated in an @hide @IntDef annotation.
The name of the method should always begin with the verb (e.g. get, create, reload, etc.), not the object you’re acting on.
public void tableReload() { mTable.reload(); }
public void reloadTable() { mTable.reload(); }
Collection<T> types over arrays as return or parameter typeGenerically-typed collection interfaces provide several advantages over arrays, including stronger API guarantees around uniqueness and ordering, support for generics, and a number of developer-friendly convenience methods.
If the elements are primitives, do prefer arrays instead, in order to avoid the cost of auto-boxing. See Take and return raw primitives instead of boxed versions
Kotlin arrays are invariant and the Kotlin language provides ample utility APIs around arrays, so arrays are on-par with List and Collection for Kotlin APIs intended to be accessed from Kotlin.
@NonNull collectionsAlways prefer @NonNull for collection objects. When returning an empty collection, use the appropriate Collections.empty method to return a low-cost, correctly-typed, and immutable collection object.
Where type annotations are supported, always prefer @NonNull for collection elements.
Kotlin APIs should prefer immutable (e.g. not Mutable) return types for collections by default unless the API contract specifically requires a mutable return type.
Java APIs, however, should prefer mutable return types by default since the Android platform‘s implementation of Java APIs does not yet provide a convenient implementation of immutable collections. The exception to this rule is Collections.empty return types, which are immutable. In cases where mutability could be exploited by clients -- on purpose or by mistake -- to break the API’s intended usage pattern, Java APIs should return a shallow copy of the collection.
@Nullable public PermissionInfo[] getGrantedPermissions() { return mPermissions; }
@NonNull public Set<PermissionInfo> getGrantedPermissions() { if (mPermissions == null) { return Collections.emptySet(); } return new ArraySet<>(mPermissions); }
APIs that return collections should ideally not modify the returned collection object after returning. If the returned collection must change or be reused in some way, for example, an adapted view of a mutable data set, the precise behavior of when the contents of a previously returned collection can change must be documented and/or appeal to an appropriate established convention. For example:
/** * Returns a view of this object as a list of [Item]s. */ fun MyObject.asList(): List<Item> = MyObjectListWrapper(this)
The Kotlin .asFoo() convention is described below and permits the collection returned by .asList() to change if the original collection changes.
vararg parameter typeBoth Kotlin and Java APIs are encouraged to use vararg in cases where the developer would be likely to create an array at the call site for the sole purpose of passing multiple, related parameters of the same type.
public void setFeatures(Feature[] features) { ... } // Developer code setFeatures(new Feature[]{Features.A, Features.B, Features.C});
public void setFeatures(Feature... features) { ... } // Developer code setFeatures(Features.A, Features.B, Features.C);
Both Java and Kotlin implementations of vararg parameters compile to the same array-backed bytecode and as a result may be called from Java code with a mutable array. API designers are strongly encouraged to create a defensive shallow copy of the array parameter in cases where it will be persisted to a field or anonymous inner class.
public void setValues(SomeObject... values) { this.values = Arrays.copyOf(values, values.length); }
Note that creating a defensive copy does not provide any protection against concurrent modification between the initial method call and the creation of the copy, not does it protect aginst mutation of the objects contained in the array.
List<Foo> is default option, but consider other types to provide additional meaning:
Use Set<Foo>, if your API is indifferent to the order of elements and it doesn’t allow duplicates or duplicates are meaningless.
Collection<Foo>, if your API is indifferent to the order and allows duplicates.
Note: Remember that Java Collections are mutable by default, so consider defensive copying for your return and parameter types. Another option for the return type is Collection.unmodifiable*.
Kotlin frequently uses .toFoo() and .asFoo() to obtain an object of a different type from an existing object where Foo is the name of the conversion's return type. This is consistent with the familiar JDK Object.toString(). Kotlin takes this further by using it for primitive conversions such as 25.toFloat().
The distinction between conversions named .toFoo() and .asFoo() is significant:
.toFoo() when creating a new, independent object {.numbered}Like .toString(), a “to” conversion returns a new, independent object. If the original object is modified later, the new object will not reflect those changes. Similarly, if the new object is modified later, the old object will not reflect those changes.
fun Foo.toBundle(): Bundle = Bundle().apply { putInt(FOO_VALUE_KEY, value) }
.asFoo() when creating a dependent wrapper, decorated object, or cast {.numbered}Casting in Kotlin is performed using the as keyword. It reflects a change in interface but not a change in identity. When used as a prefix in an extension function, .asFoo() decorates the receiver. A mutation in the original receiver object will be reflected in the object returned by asFoo(). A mutation in the new Foo object may be reflected in the original object.
fun <T> Flow<T>.asLiveData(): LiveData<T> = liveData { collect { emit(it) } }
Writing conversion functions outside of both the receiver and the result class definitions reduces coupling between types. An ideal conversion needs only public API access to the original object. This proves by example that a developer can write analogous conversions to their own preferred types as well.
Methods must not throw generic exceptions such as java.lang.Exception or java.lang.Throwable, instead an approriate specific exception has to be used like java.lang.NullPointerException to allow developers to handle exceptions without being overly broad.
Methods that take no parameters should throw java.lang.IllegalStateException instead of java.lang.IllegalArgumentException or java.lang.NullPointerException.
These are the rules around the classes and methods used for listener/callback mechanisms.
Use MyObjectCallback instead of MyObjectCallbacks.
on<Something>onFooEvent signifies that FooEvent is happening and that the callback should act in response.
Callback methods regarding events should be named to indicate whether the event has already happened or is in the process of happening.
For example, if the method is called after a click action has been performed:
public void onClicked()
However, if the method is responsible for performing the click action:
public boolean onClick()
When a listener or callback can be added or removed from an object, the associated methods should be named add/remove OR register/unregister. Be consistent with the existing convention used by the class or by other classes in the same package. When no such precedent exists, prefer add/remove.
Methods involving registering or unregistering callbacks should specify the whole name of the callback type.
public void addFooCallback(@NonNull FooCallback callback); public void removeFooCallback(@NonNull FooCallback callback);
public void registerFooCallback(@NonNull FooCallback callback); public void unregisterFooCallback(@NonNull FooCallback callback);
Do not add getFooCallback() methods. This is a tempting escape hatch for cases where developers may want to chain an existing callback together with their own replacement, but it is brittle and makes the current state difficult to reason about for component developers. For example,
setFooCallback(a)setFooCallback(new B(getFooCallback()))a and has no way to do so without knowledge of B’s type, and B having been built to allow such modifications of its wrapped callback.When registering callbacks that have no explicit threading expectations (pretty much anywhere outside the UI toolkit), it is strongly encouraged to include an Executor parameter as part of registration to allow the developer to specify the thread upon which the callbacks will be invoked.
public void registerFooCallback( @NonNull @CallbackExecutor Executor executor, @NonNull FooCallback callback)
Note: Developers must provide a valid Executor. The new @CallbackExecutor annotation will add automatic documentation to tell developers about common default options. Also note that the callback argument is required to be last to enable idiomatic usage from Kotlin.
As an exception to our usual guidelines about optional parameters, it is ok to provide an overload omitting the Executor even though it is not the final argument in the parameter list. If the Executor is not provided, the callback should be invoked on the main thread using Looper.getMainLooper() and this should be documented on the associated overloaded method.
/** * ... * Note that the callback will be executed on the main thread using * {@link Looper.getMainLooper()}. To specify the execution thread, use * {@link registerFooCallback(Executor, FooCallback)}. * ... */ public void registerFooCallback( @NonNull FooCallback callback) public void registerFooCallback( @NonNull @CallbackExecutor Executor executor, @NonNull FooCallback callback)
Executor implementation gotchas: Note that the following is a valid executor!
public class SynchronousExecutor implements Executor { @Override public void execute(Runnable r) { r.run(); } }
This means that when implementing APIs that take this form, your incoming binder object implementation on the app process side must call Binder.clearCallingIdentity() before invoking the app’s callback on the app-supplied Executor. This way any application code that uses Binder identity (e.g. Binder.getCallingUid()) for permission checks correctly attributes the code running to the application and not to the system process calling into the app. If users of your API want the UID / PID information of the caller then this should be an explicit part of your API surface, rather than implicit based on where the Executor they supplied ran.
The above should be supported by your API. In performance-critical cases apps may need to run code either immediately or synchronously with feedback from your API. Accepting an Executor permits this. Defensively creating an additional HandlerThread or similar to trampoline from defeats this desirable use case.
If an app is going to run expensive code somewhere in their own process, let them. The workarounds that app developers will find to overcome your restrictions will be much harder to support in the long term.
Exception for single callback: when the nature of the events being reported calls for only supporting a single callback instance, use the following style:
public void setFooCallback( @NonNull @CallbackExecutor Executor executor, @NonNull FooCallback callback) public void clearFooCallback()
If there is a way to add or register something, there should also be a way to remove/unregister it. The method
registerThing(Thing)
should have a matching
unregisterThing(Thing)
Now that all the APIs can assume Java 8‘s default interface methods, multiple-method callbacks can always be an interface. (Previously, this guideline asked to use abstract class instead in situations where jave 8 wasn’t supported.)
public interface MostlyOptionalCallback { void onImportantAction(); default void onOptionalInformation() { // Empty stub, this method is optional. } }
API level 24 added the java.util.function.* (reference docs) types, which offer generic SAM interfaces such as Consumer<T> that are suitable for use as callback lambdas. In many cases, creating new SAM interfaces provides little value in terms of type safety or communicating intent while unnecessarily expanding the Android API surface area.
See an example of platform-defined functional interfaces -- Runnable, Supplier, and Consumer -- in the CTS theme test’s ConditionCheck class and associated usage.
Consider using these generic interfaces, rather than creating new ones:
Runnable (nilary function to void)Supplier<R> (nilary function to R)Consumer<T> (unary function T to void)Function<T,R> (unary function from T to R)Predicate<T> (unary function T to boolean)SAM parameters should be placed last to enable idiomatic usage from Kotlin, even if the method is being overloaded with additional parameters.
public void schedule(Runnable runnable) public void schedule(int delay, Runnable runnable)
These are rules about the public docs (JavaDocs) for APIs.
All public APIs must have sufficient javadocs to explaining how a developer would use the API. Assume the developer found it via auto-complete or while browsing through API reference docs and has a minimal amount of context from the adjacent API surface (ex. on the same class).
Method parameters and return values must be documented using @param and @return docs annotations, respectively. The javadoc body should be formatted as though it is preceded by “This method...”.
In cases where a method takes no parameters, has no special considerations, and simply returns what the method name says it does, the @return may be omitted and docs may be written similar to:
/** * Returns the priority of the thread. */ @IntRange(from = 1, to = 10) public int getPriority() { ... }
Docs should link to other docs for related constants, methods, etc. Use Javadoc tags (e.g., @see and {@link foo}), not just plain-text words.
For:
public static final int FOO = 0; public static final int BAR = 1;
Follow:
/** * Sets value to one of FOO or <code>BAR</code>. * * @param value the value being set, one of FOO or BAR */ public void setValue(int value) { ... }
/** * Sets value to one of {@link #FOO} or {@link #BAR}. * * @param value the value being set */ public void setValue(@ValueType int value) { ... }
Note that using an IntDef annotation such as @ValueType on a parameter will automatically generate documentation specifying the allowed types. See the guidance on annotations for more information on IntDef.
This rule is particularly important when adding @link or @see tags, and make sure the output looks as expected. It is common to see ERROR output in JavaDocs from bad links. Either the update-api or docs Make target will perform this check, but the docs target might be quicker if you are simply changing javadocs and do not otherwise need to run the update-api target.
{@code foo} to distinguish Java valuesJava values like true, false, and null should be wrapped with {@code ...} to distinguish them from documentation text.
@param and @return summaries should be a single sentence fragmentParameter and return value summaries should start with a lowercase character and contain only a single sentence fragment. If you have additional information that extends beyond a single sentence, move it to the method javadoc body.
/** * @param e The element to be appended to the list. This must not be * null. If the list contains no entries, this element will * be added at the beginning. * @return This method returns true on success. */
/** * @param e element to be appended to this list, must be non-{@code null} * @return {@code true} on success, {@code false} otherwise */
Annotations @hide and @removed should include documentation as to why they are hidden from public API. Use of @deprecated annotation must include instructions on how to replace usages of the deprecated API.
@throws to document exceptionsIf a method throws an exception indicating a preventable error, for example IllegalArgumentException or IllegalStateException, the exception must be documented with an explanation of why the exception is thrown. The thrown exception should also indicate why it was thrown.
/** * ... * @throws IllegalArgumentException if the template requests a value that * was not provided, or if more than 9 values are provided */ public static CharSequence expandTemplate(CharSequence template, CharSequence... values) { if (values.length > 9) { throw new IllegalArgumentException("max of 9 values are supported"); } ...
If the method invokes asynchronous code that may throw exceptions, please consider how the developer will find out about and respond to such exceptions. Typically this involves forwarding the exception to a callback and documenting the exceptions thrown on the method that receives them. Asynchronous exceptions should not be documented with @throws unless they are actually re-thrown from the annotated method.
The doclava tool parses docs simplistically, ending the synopsis doc (the first sentence, used in the quick description at the top of the class docs) as soon as it sees a period (.) followed by a space. There are two problems that this causes:
TEXT_ALIGNMENT_CENTER in View.java. Note that Metalava will automatically correct this error by inserting a non-breaking space after the period; however, please don’t make this mistake in the first place.Javadocs will be rendered in HTML, so format them accordingly:
Line breaks should use an explicit <p> tag. Do not add a closing </p> tag.
Do not use ASCII to render lists or tables.
Lists should use <ul> or <ol> for unordered and ordered, respectively. Each item should begin with a <li> tag, but does not need a closing </li> tag. A closing </ul> or </ol> tag is required after the last item.
Tables should use <table>, <tr> for rows, <th> for headers, and <td> for cells. All table tags require matching closing tags. You may use class="deprecated" on any tag to denote deprecation.
To create inline code font, use {@code foo}.
To create code blocks, use <pre>.
All text inside a <pre> block is parsed by the browser, so be careful with brackets <>. You can escape them with < and > HTML entities.
Alternatively, you can leave raw brackets <> in your code snippet if you wrap the offending sections in {@code foo}. For example:
<pre>{@code <manifest>}</pre>
To ensure consistency in the style for class summaries, method descriptions, parameter descriptions, etc., follow the recommendations in the official Java language guidelines at How to Write Doc Comments for the Javadoc Tool.
These rules are about APIs, patterns, and data structures that are specific to APIs and functionality built into the Android framework (Bundles, Parcelables, etc.).
create*Intent() patternCreators for intents should use methods named createFooIntent().
Bundles instead of creating new general-purpose data structuresInstead of creating a new type/class to hold various args or various types, consider simply using a Bundle instead.
CREATOR fieldParcelable inflation is exposed through CREATOR, not raw constructors. If a class implements Parcelable, then its CREATOR field must also public API and the class constructor taking a Parcel argument must be private.
CharSequence for UI stringsWhen a string will be presented in a user interface, use CharSequence to allow for Spannables.
If it’s just a key or some other non-user-visible label or value, String is fine.
IntDefs must be used over enums in all platform APIs, and should be strongly considered in unbundled, library APIs. Only use enums when you are certain new values will not be added.
Benefits of IntDef
when statements can fail at runtime if they become no-longer-exhaustive due to an added enum value in platform.Benefits of Enum
when statement usagewhen statement in kotlin that returns a valueThe android.* package hierarchy has an implicit ordering, where lower-level packages cannot depend on higher-level packages.
The Android platform is an open-source project and aims to be vendor neutral. The API should be generic and equally usable by system integrators or applications with the requisite permissions.
finalParcelable classes defined by the platform are always loaded from framework.jar, so it’s invalid for an app to try overriding a Parcelable implementation.
If the sending app extends a Parcelable, the receiving app won’t have the sender’s custom implementation to unpack with. Note about backward compatibility: if your class historically wasn’t final, but didn’t have a publicly available constructor, you still can mark it final.
RemoteException as RuntimeExceptionRemoteException is typically thrown by internal AIDL, and indicates that the system process has died, or the app is trying to send too much data. In both cases, public API should rethrow as a RuntimeException to ensure that apps don’t accidentally persist security or policy decisions.
If you know the other side of a Binder call is the system process, this simple boilerplate code is the best-practice:
try { ... } catch (RemoteException e) { throw e.rethrowFromSystemServer(); }
Use of the Java clone() method is strongly discouraged due to the lack of API guarantees provided by the Object class and difficulties inherent in extending classes that use clone(). Instead, use a copy constructor that takes an object of the same type.
/** * Constructs a shallow copy of {@code other}. */ public Foo(Foo other)
Classes that rely on a Builder for construction should consider adding a Builder copy constructor to allow modifications to the copy.
public class Foo { public static final class Builder { /** * Constructs a Foo builder using data from {@code other}. */ public Builder(Foo other)
ParcelFileDescriptor over FileDescriptor.The java.io.FileDescriptor object has a poor definition of ownership, which can result in obscure use-after-close bugs. Instead, APIs should return or accept ParcelFileDescriptor instances. Legacy code can convert between PFD and FD if needed using dup() or getFileDescriptor().
Avoid using short or byte values directly, since they often limit how you might be able to evolve the API in the future.
java.util.BitSet is great for implementation but not for public API. It's mutable, requires an allocation for high-frequency method calls, and does not provide semantic meaning for what each bit represents.
For high-performance scenarios, use an int or long with @IntDef. For low-performance scenarios, consider a Set<EnumType>. For raw binary data, use byte[].
android.net.Uri.android.net.Uri is the preferred encapsulation for URIs in Android APIs.
Avoid java.net.URI, because it is overly strict in parsing URIs, and never use java.net.URL, because its definition of equality is severely broken.
@IntDef, @LongDef or @StringDefAnnotations marked as @IntDef, @LongDef or @StringDef denote a set of valid constants that can be passed to an API. However, when they are exported as APIs themselves, the compiler inlines the constants and only the (now useless) values remain in the annotation's API stub (for the platform) or JAR (for libraries).
As such, usages of these annotations must be marked @hide in the platform or @hide and RestrictTo.Scope.LIBRARY) in libraries. They must be marked @Retention(RetentionPolicy.SOURCE) in both cases to ensure they do not appear in API stubs or JARs.
/** @hide */ @RestrictTo(RestrictTo.Scope.LIBRARY) @Retention(RetentionPolicy.SOURCE) @IntDef({ STREAM_TYPE_FULL_IMAGE_DATA, STREAM_TYPE_EXIF_DATA_ONLY, }) public @interface ExifStreamType {}
When building the platform SDK and library AARs, a tool extracts the annotations and bundles them separately from the compiled sources. Android Studio reads this bundled format and enforces the type definitions.
This guideline is enforced by Metalava in both the platform and AndroidX builds.
Keep AIDL interfaces as implementation details. Generated AIDL classes do not generally meet the API style guide requirements to begin with (for example, they cannot use overloading), and additionally this significantly constrains future implementation improvements. This applies to both generated interfaces and generated parcelable data classes.
Instead, add a public API layer on top of the AIDL interface, even if it initially is just a shallow wrapper.
If the Binder interface is an implementation detail, it can be changed freely in the future, with the public layer allowing for the required backward compatibility to be maintained. For example, you may find you need to add new arguments to the internal calls, or optimize IPC traffic via batching/streaming, using shared memory, or similar. None of these can easily be done if your AIDL interface is also the public API.
For example, instead of exposing FooService as a public API directly:
// BAD: Public API generated from IFooService.aidl public class IFooService { public void doFoo(String foo); }
instead wrap the Binder interface inside a manager or other class:
/** * @hide */ public class IFooService { public void doFoo(String foo); } public IFooManager { public void doFoo(String foo) { mFooService.doFoo(foo); } }
and if later a new argument is needed for this call, the internal interface can be kept simple and convenient overloads added to the public API. And the wrapping layer can be used to handle other backwards-compatibility concerns as the implementation evolves, as well:
/** * @hide */ public class IFooService { public void doFoo(String foo, int flags); } public IFooManager { public void doFoo(String foo) { if (mAppTargetSdkLevel < 26) { useOldFooLogic(); // Apps targeting API before 26 are broken otherwise mFooService.doFoo(foo, FLAG_THAT_ONE_WEIRD_HACK); } else { mFooService.doFoo(foo, 0); } } public void doFoo(String foo, int flags) { mFooService.doFoo(foo, flags); } }
For Binder interfaces that are not part of the Android platform (for example, a service interface exported by Google Play Services for applications to use), the requirement for a stable, published, and versioned IPC interface means that it is much harder to evolve the interface itself. However, it is still worthwhile to have a wrapper layer around it, to match other API guidelines and to make it easier to use the same public API for a new version of the IPC interface, if that ever becomes necessary.
Note that generated AIDL interface definitions in libraries cannot currently be hidden from clients (b/135686385) and appear as public API no matter what. Additional code rewriting / manually written Binder interfaces may be needed until the generated code can be properly hidden.
Do not expose new keys from Settings.Global, Settings.System, and/or Settings.Secure.
Instead, add a proper getter and setter Java API in a relevant class, which is typically a “manager” class. Add a listener mechanism or a broadcast to notify clients of changes as needed.
SettingsProvider settings have a number of problems compared to getters/setters:
Example: Settings.Secure.LOCATION_MODE has existed for a long time, but the location team has deprecated it for a proper Java API LocationManager.isLocationEnabled() and the MODE_CHANGED_ACTION broadcast, which gave the team a lot more flexibility, and the semantics of the APIs are a lot clearer now.
Activity and AsyncTaskAsyncTask is an implementation detail. Instead, expose a listener or, in androidx, a ListenableFuture API instead.
Activity subclasses are impossible to compose. Extending activity for your feature makes it incompatible with other features that require users to do the same. Instead, rely on composition by using tools such as LifecycleObserver.
Context's getUser()Classes bound to a Context, such as anything returned from Context.getSystemService() should use the user bound to the Context instead of exposing members that target specific users.
class FooManager { Context mContext; void fooBar() { mIFooBar.fooBarForUser(mContext.getUser()); } }
class FooManager { Context mContext; Foobar getFoobar() { // Bad: doesn't appy mContext.getUserId(). mIFooBar.fooBarForUser(Process.myUserHandle()); } Foobar getFoobar() { // Also bad: doesn't appy mContext.getUserId(). mIFooBar.fooBar(); } Foobar getFoobarForUser(UserHandle user) { mIFooBar.fooBarForUser(user); } }
Exception: A method may accept a user argument if it accepts values that don't represent a single user, such as UserHandle.ALL.
UserHandle instead of plain intsUserHandle is preferred to ensure type safety and avoid conflating user IDs with uids.
Foobar getFoobarForUser(UserHandle user);
Foobar getFoobarForUser(int userId);
Where unavoidable, ints representing a user ID must be annotated with @UserIdInt.
Foobar getFoobarForUser(@UserIdInt int user);
Broadcast intents are very powerful, but they've resulted in emergent behaviors that can negatively impact system health, and so new broadcast intents should be added judiciously.
Here are some specific concerns which result in us discouraging the introduction of new broadcast intents:
When sending broadcasts without the FLAG_RECEIVER_REGISTERED_ONLY flag, they will force-start any applications which aren‘t already running. While this can sometimes be a desired outcome, it can result in stampeding of dozens of apps, negatively impacting system health. We’d recommend using alternative strategies, such as JobScheduler, to better coordinate when various preconditions are met.
When sending broadcasts, there is little ability to filter or adjust the content delivered to apps. This makes it difficult or impossible to respond to future privacy concerns, or introduce behavior changes based on the target SDK of the receiving app.
Since broadcast queues are a shared resource, they can become overloaded and may not result in timely delivery of your event. We've observed several broadcast queues in the wild which have an end-to-end latency of 10 minutes or longer.
For these reasons, we encourage new features to consider using listeners/callbacks or other facilities such as JobScheduler instead of broadcast intents.
In cases where broadcast intents still remain the ideal design, here are some best-practices that should be considered:
Intent.FLAG_RECEIVER_REGISTERED_ONLY to limit your broadcast to apps that are already running. For example, ACTION_SCREEN_ON uses this design to avoid waking up apps.Intent.setPackage() or Intent.setComponent() to target the broadcast at a specific app of interest. For example, ACTION_MEDIA_BUTTON uses this design to focus on the current app handling playback controls.<protected-broadcast> to ensure that malicious apps can't impersonate the OS.Intents in system-bound developer servicesServices that are intended to be extended by the developer and bound by the system, for example abstract services like NotificationListenerService, may respond to an Intent action from the system. Such services should meet the following criteria:
SERVICE_INTERFACE string constant on the class containing the fully-qualified class name of the service. This constant must be annotated with @SdkConstant(SdkConstant.SdkConstantType.SERVICE_ACTION).<intent-filter> to their AndroidManifest.xml in order to receive Intents from the platform.Intents to developer services.See the official Android Kotlin-Java interop guide for a full list of guidelines. Select guidelines have been copied to this guide to improve discoverability.
Kotlin uses companion object to expose static members. In some cases, these will show up from Java on an inner class named Companion rather than on the containing class.
To maximize compatibility with Java, annotate companion objects' non-const fields with @JvmField and public functions with @JvmStatic to expose them directly on the containing class.
companion object { @JvmField val BIG_INTEGER_ONE = BigInteger.ONE @JvmStatic fun fromPointF(pointf: PointF) { /* ... */ } }
Policies around what types of changes may be made to existing Android APIs and how those changes should be implemented to maximize compatibility with existing apps and codebases.
Binary-breaking changes are not allowed in public API and will generally raise errors when running make update-api. There may, however, be edge cases that are not caught by Metalava’s API check. When in doubt, refer to the Eclipse Foundation’s Evolving Java-based APIs wiki entry for a detailed explanation of what types of API changes are compatible. Binary-breaking changes in non-public (ex. system) APIs should follow the Deprecate/replace cycle.
Source-breaking changes are discouraged even if they are not binary-breaking. One example of a binary-compatible but source-breaking change is adding a generic to an existing class, which is binary-compatible but may introduce compilation errors due to inheritance or ambiguous references. Source-breaking changes will not raise errors when running make update-api, so care must be taken to understand the impact of changes to existing API signatures.
@SystemApi, @TestApi)APIs annotated with @TestApi may be changed at any time.
APIs annotated with @SystemApi must be preserved for three years. Removal or refactoring of a system API must occur on the following schedule:
Deprecation is considered an API change and may occur in a major (e.g. letter) release. Use the @Deprecated source annotation and @deprecated <summary> docs annotation together when deprecating APIs. Your summary must include a migration strategy, which may link to a replacement API or explain why the API should not be used.
/** * Simple version of ... * * @deprecated Use the {@link androidx.fragment.app.DialogFragment} * class with {@link androidx.fragment.app.FragmentManager} * instead. */ @Deprecated public final void showDialog(int id)
APIs defined in XML and exposed in Java, including attributes and styleable properties exposed in the android.R class, must also be deprecated with a summary.
<!-- Attribute whether the accessibility service ... {@deprecated Not used by the framework} --> <attr name="canRequestEnhancedWebAccessibility" format="boolean" />
Deprecations are most useful for discouraging adoption of an API in new code.
We also require that APIs are marked as @deprecated before they are @removed, but this does not provide strong motivation for developers to migrate away from an API they are already using.
Before deprecating an API, consider the impact on developers. The effects of deprecating an API include:
javac will emit a warning during compilation-Werror will need to individually fix or suppress every usage of a deprecated API before they can update their compile SDK versionAs a result, deprecating an API may discourage the developers who are the most concerned about code health -- those using -Werror -- from adopting new SDKs. At the other end of the spectrum, developers who are not concerned about warnings in their existing code are likely to ignore deprecations altogether.
Both of these cases are made worse when an SDK introduces a large number of deprecations.
For this reason, we recommend deprecating APIs only in cases where:
@removed in a future releaseWhen an API is deprecated and replaced with a new API, we strongly recommend that a corresponding compatibility API be added to a Jetpack library like androidx.core to simplify supporting both old and new devices.
We do not recommend deprecating APIs that are working as intended and will continue to work in future releases.
/** * ... * @deprecated Use {@link #doThing(int, Bundle)} instead. */ @Deprecated public void doThing(int action) { ... } public void doThing(int action, @Nullable Bundle extras) { ... }
/** * ... * @deprecated No longer displayed in the status bar as of API 21. */ @Deprecated public RemoteViews tickerView;
The behavior of deprecated APIs must be maintained, which means test implementations must remain the same and tests must continue to pass after the API has been deprecated. If the API does not have tests, tests should be added.
Deprecated API surfaces should not be expanded in future releases. Lint correctness annotations (ex. @Nullable) may be added to an existing deprecated API, but new APIs should not be added to deprecated classes or interfaces.
New APIs should not be added as deprecated. APIs that were added and subsequently deprecated within a pre-release cycle -- thus would initially enter the public API surface as deprecated -- should be removed before API finalization.
Soft removal is a source-breaking change and should be avoided in public APIs unless explicitly approved by API Council. For system APIs, soft removals must be preceded by deprecation for the duration of a major release. Remove all docs references to the APIs and use the @removed <summary> docs annotation when soft-removing APIs. Your summary must include the reason for removal and may include a migration strategy as explained in Deprecation.
The behavior of soft-removed APIs may be maintained as-is but more importantly must be preserved such that existing callers will not crash when calling the API. In some cases, that may mean preserving behavior.
Test coverage must be maintained, but the content of the tests may need to change to accomodate for behavioral changes. Tests must still ensure that existing callers do not crash at run time.
/** * Ringer volume. This is ... * * @removed Not functional since API 2. */ public static final String VOLUME_RING = ...
Certain categories of API must not be soft removed.
Abstract methods on classes that may be extended by developers must not be soft removed. Doing so will make it impossible for developers to successfully extend the class across all SDK levels.
In rare cases where it was never and will never be possible for developers to extend a class, abstract methods may still be soft removed.
Hard removal is a binary-breaking change and should never occur in public APIs. For system APIs, hard removals must be preceded by soft removal for the duration of a major release. Remove the entire implementation when hard-removing APIs.
Tests for hard-removed APIs must be removed since they will no longer compile otherwise.
The @Discouraged annotation is used to indicate that an API is not recommended in most (>95%) cases. Discouraged APIs differ from deprecated APIs in that there exists a narrow critical use case that prevents deprecation. When marking an API as discouraged, an explanation and an alternative solution must be provided.
@Discouraged(message = "Use of this function is discouraged because resource reflection makes it harder to perform build optimizations and compile-time verification of code. It is much more efficient to retrieve resources by identifier (e.g. `R.foo.bar`) than by name (e.g. `getIdentifier()`)") public int getIdentifier(String name, String defType, String defPackage) { return mResourcesImpl.getIdentifier(name, defType, defPackage); }
New APIs should not be added as discouraged. Currently, only the Performance team can discourage an API.
In some cases it can be desirable to change the implementation behavior of an existing API. (For example, in Android 7.0 we improved DropBoxManager to clearly communicate when developers tried posting events that were too large to send across Binder.)
However, to ensure that existing apps aren‘t surprised by these behavior changes, we strongly recommend preserving a safe behavior for older applications. We’ve historically guarded these behavior changes based on the ApplicationInfo.targetSdkVersion of the app, but we‘ve recently migrated to require using the App Compatibility Framework. Here’s an example of how to implement a behavior change using this new framework:
import android.app.compat.CompatChanges; import android.compat.annotation.ChangeId; import android.compat.annotation.EnabledSince; public class MyClass { @ChangeId // This means the change will be enabled for target SDK R and higher. @EnabledSince(targetSdkVersion=android.os.Build.VERSION_CODES.R) // Use a bug number as the value, provide extra detail in the bug. // FOO_NOW_DOES_X will be the change name, and 123456789 the change id. static final long FOO_NOW_DOES_X = 123456789L; public void doFoo() { if (CompatChanges.isChangeEnabled(FOO_NOW_DOES_X)) { // do the new thing } else { // do the old thing } } }
Using this App Compatibility Framework design enables developers to temporarily disable specific behavior changes during preview and beta releases as part of debugging their apps, instead of forcing them to adjust to dozens of behavior changes simultaneously.
Forward compatibility is a design characteristic that allows a system to accept input intended for a later version of itself. In the case of API design -- especially platform APIs -- special attention must be paid to the initial design as well as future changes since developers expect to write code once, test it once, and have it run everywhere without issue.
The most common forward compatibility issues in Android are caused by:
@IntDef or enum) previously assumed to be complete, e.g. where switch has a default that throws an exceptionColorStateList-type resources in XML where previously only <color> resources were supportedrequireNotNull() check that was present on older versionsIn all of these cases, developers will only find out that something is wrong at run time. Worse, they may only find out as a result of crash reports from older devices in the field.
Additionally, these cases are all technically valid API changes. They do not break binary or source compatibility and API lint will not catch any of these issues.
As a result, API designers must pay careful attention when modifying existing classes. Ask the question, “Is this change going to cause code that's written and tested only against the latest version of the platform to fail on older versions?”
If an XML schema serves as a stable interface between components, that schema must be explicitly specified and must evolve in a backward-compatible manner, similar to other Android APIs. For example, the structure of XML elements and attributes must be preserved similar to how methods and variables are maintained on other Android API surfaces.
If you'd like to deprecate an XML element or attribute, you can add the xs:annotation marker, but you must continue to support any existing XML files by following the typical @SystemApi evolution lifecycle.
<xs:element name="foo"> <xs:complexType> <xs:sequence> <xs:element name="name" type="xs:string"> <xs:annotation name="Deprecated"/> </xs:element> </xs:sequence> </xs:complexType> </xs:element>
Schemas support the sequence element, choice element and all elements as child elements of complexType element. However, these child elements differ in the number and order of their child elements, so modifying an existing type would be an incompatible change.
If you want to modify an existing type, the best-practice is to deprecate the old type and introduce a new type to replace it.
<!-- Original "sequence" value --> <xs:element name="foo"> <xs:complexType> <xs:sequence> <xs:element name="name" type="xs:string"> <xs:annotation name="Deprecated"/> </xs:element> </xs:sequence> </xs:complexType> </xs:element> <!-- New "choice" value --> <xs:element name="fooChoice"> <xs:complexType> <xs:choice> <xs:element name="name" type="xs:string"/> </xs:choice> </xs:complexType> </xs:element>