Write a .gitignore for an Android Studio project

An Android Studio project's .gitignore should exclude generated build output, local machine settings, and private signing material. Start from the maintained Android template in GitHub's gitignore repository, then adapt it to the files your team intentionally shares.

A practical starting point

Place this in the project root:

# Gradle caches and build output
.gradle/
build/
.cxx/
.externalNativeBuild/
*.apk
*.aab
*.ap_

# Machine-specific Android SDK configuration
local.properties

# IDE state: adjust if your team shares selected .idea settings
.idea/
*.iml
*.iws
*.ipr
.navigation/
captures/

# Private signing keys and local signing configuration
*.keystore
*.jks
key.properties

# Operating-system and diagnostic files
.DS_Store
Thumbs.db
*.log

A build/ pattern matches directories named build at any depth, so it covers both app and library modules. Keep the Gradle wrapper scripts and wrapper files needed for reproducible builds; do not confuse .gradle/, a local cache, with the tracked gradle/ directory.

Do not blindly ignore every .pem file. PEM is a format used for both private keys and public certificates. Exclude actual private-key paths and review what your project requires.

Decide what to share from .idea

Ignoring the entire .idea/ directory is one policy. Another is to track selected code-style or inspection settings while excluding workspace-specific state. If you choose selective tracking, replace the whole-directory exclusion with rules that keep the parent traversable and explicitly allow the desired files.

Make the decision as a team. Shared .editorconfig, ktlint, or detekt configuration can express conventions independently of each developer's IDE; those configuration files normally belong in version control.

Handle signing and Firebase configuration separately

Keep private app-signing or upload keys and their passwords out of the repository. Provide them through an approved secret-storage process when building releases. A committed ignore rule does not revoke a key that has already leaked.

google-services.json contains Firebase client configuration and is different from a service-account private key. Firebase API keys used for Firebase services identify the project; access is controlled separately through mechanisms such as Security Rules and IAM. Review API restrictions and your organization's policy before committing the file. Never treat that distinction as permission to commit service-account credentials or unrestricted keys for other APIs.

If generated or local files are already tracked, use a scoped git rm --cached operation, add the rules, and commit the removal after reviewing its effect on collaborators.

FAQ

Where can I get a complete template?

Use the maintained GitHub template linked above and review its comments. It is a starting point, not proof that every excluded file is disposable in your project. Template generators such as gitignore.io can combine technologies, but inspect the combined rules before adopting them.

Why exclude local.properties?

It commonly contains a local SDK path and other machine-specific Android build settings. Each checkout can generate its own file; supported SDK environment variables such as ANDROID_HOME are another way to provide the SDK location. Do not commit one developer's absolute path as a team default.

Do app and library modules need separate ignore files?

Usually not. A root file can cover all modules. Add module-specific rules only when the modules have different generated content or intentional exceptions.

See the Android template, Android build configuration, and Firebase security checklist.