Starting March 27, 2025, we recommend using android-latest-release instead of aosp-main to build and contribute to AOSP. For more information, see Changes to AOSP.

Code with respect

Inclusivity is central to Android’s culture, and our values include treating each other with dignity. As such, it’s important that everyone can contribute without facing the harmful effects of bias and discrimination. However, terms in our codebase, user interfaces, and documentation can perpetuate that discrimination. This policy gives guidance to address disrespectful terminology in code, interfaces, and documentation.

See Code of conduct for more information about Android standards.

Policy

Terminology that is derogatory, hurtful, or perpetuates discrimination, either directly or indirectly, should be avoided. This agrees with Google’s guidance on writing inclusive documentation.

The scope for this policy

The scope of this policy includes anything that a contributor would read while working on Android, including but not limited to:

Names of variables, types, functions, files, build rules, binaries, exported variables
Test data
System output and displays
Comments and documentation (both inside and outside of source files)
Commit messages

Principles

Be respectful: Derogatory language shouldn’t be necessary to describe how things work.
Use culturally appropriate language: Some words might have significant historical or political meanings. Please consider this and use alternatives.

Determine if a particular terminology is OK or not

Apply the principles above. If you have any questions, you can reach out to android-community@googlegroups.com.

Examples of terminology to avoid

This list is NOT meant to be comprehensive. It contains a few examples that people have run into frequently.

Note that it's always worth considering whether a comment adds any value. Sometimes the best fix is to remove the comment entirely. For example, a comment saying only "Sanity check the header" immediately before a function called verify_header doesn't add any value even if you're writing the doc comment for public API. Be more specific about what is being checked, for example "Check header for out of range values".

Term	Suggested alternatives
master/slave	See alternatives for master and slave.
redline	priority line, track changes, design specs, UI annotations, exception, anomaly, special case, replacement list
whitelist/blacklist	See alternatives for blacklist.
(dark\|light) graylist	For APIs: (graylist) "non-SDK API lists" (dark-graylist) "conditionally blocked" when referring to all max-target-sdk lists as a group, or "max-target-X" when referring to a specific list (light-graylist) "unsupported"
crazy, insane, cripple	See Avoid ableist language for guidelines.
sanity check	The word "check" alone often conveys the same meaning. Otherwise consider validate, verify, quick check, initial check, confidence check, soundness check, calibration check, readiness check.
dummy	unused, placeholder, no-op, base, fake/mock/stub.
grandfathered	See alternatives for grandfathered for guidelines.
gendered pronouns (for example, he or she)	they, them, their
man-in-the-middle (MITM)	on-path attacker
(black\|white\|gray) hat	ethical/unethical
first-class citizen	core feature, built-in, top-level

When changing the language changes the meaning

In some circumstances, changing the language in the specification might interfere with the ability to understand the implementation, particularly when implementing code specifications. For these circumstances, we suggest one of the following, in order of decreasing preference:

If using alternate terminology doesn't interfere with understanding, use alternate terminology.
Don't propagate the terminology beyond the layer of code that is performing the interfacing. Where necessary, use alternative terminology at the API boundaries.
If you can't fix the language yourself, file a bug with the respective team.

Code with respect Stay organized with collections Save and categorize content based on your preferences.