---
title: "The First 2 Commits Every Android Project Should Have"
source: "/writing/the-first-2-commits-every-android-project-should-have/"
---

Article

# The First 2 Commits Every Android Project Should Have

Andrew Haisting

February 28, 2019

Photo by [Martin von Rotz.](https://www.snapwi.re/user/mavoro)

## File -> New -> New Project...

It's an exciting feeling, isn't it? _Tabula rasa._ There's so much fun in store -- dreaming up your implementation of the latest architecture fad, authoring a git history Marie Kondo would be proud of, and if you're lucky, you might even get to work with a new `minSdkVersion`!

Hold on though, before you get lost in the sauce, there are a couple quality of life changes that will prevent headaches down the line.

## 1) Use Activity Alias for launcher activity

The "New Project" wizard will create an Activity in the Manifest with proper launcher intent filters. That's fine, but later on in the project if we change which activity handles the launcher intent, the launcher icon will disappear from users' devices!

Prevent this annoying bug from ever being born by using `<activity-alias>`:

This way, if you ever want to specify a new launcher, you can change the `targetActivity` of the `<activity-alias>` and users won't have launcher icons go missing!

## 2) Sign debug builds with a keystore kept in version control

An APK cannot be installed onto a device unless it is signed. A fresh project from the "New Project" wizard doesn't specify any `signingConfigs` for `debug` builds, but you can still run the app out of the box. Why?

Behind the scenes Android Studio automatically creates a debug keystore and certificate in `$HOME/.android/debug.keystore`, and uses it to sign debug builds. There are two problems with this:

1.  If we install a debug build from a different machine, it will be signed differently and therefore won't be able to install without entirely wiping out the previous APK.
2.  The generated keystore expires after 365 days, which means on your project's first birthday you'll get a build error. Not a fun way to celebrate one trip around the sun.

Let's create a key for signing debug builds, and check it into source code:

To create a key for signing debug builds, select **Build -> Generate Signed Bundle / Apk...**

It doesn't matter which of these you choose right now, we're just generating a new keystore!

Use "android" for both the store password and the key password

After generating the new keystore, you can close the wizard and add the following to your `app/build.gradle`:

This way, we won't run into signing conflicts when distributing debug builds to testers, adding other developers to the project, or creating builds from different machines!

Are there commits that you find helpful on every single greenfield project? I'd love to hear about it in a response below!

_Andrew loves clicking_ _File -> New -> New Project..._ _at_ [_Livefront_](https://livefront.com/) _._

-   Andrew Haisting

    Software Engineer

    Andrew Haisting

### Tags

[Digital Engineering](/insights/all/?topic=digital-engineering) [Mobile Apps](/insights/all/?topic=mobile-apps)

### Share

-   Copied

## View these next.

[See all](/insights/all/?type=writing)

-   [

    Article

    How To Sabotage Your Project Using Inconsistency

    Collin Flynn

    ](/writing/how-to-sabotage-your-project-using-inconsistency/)
-   [

    Article

    Unit Testing race conditions by creating chaos (Swift)

    Sean Berry

    ](/writing/unit-testing-race-conditions-by-creating-chaos-swift/)
-   [

    Article

    UIApplicationDelegate call sequence reference

    Sean Berry

    ](/writing/uiapplicationdelegate-call-sequence-reference/)