Implementing Firebase Authentication in your Android app

Firebase Authentication has become the default identity layer for thousands of Android apps shipped from Sydney studios, Melbourne co-working spaces, and Brisbane product houses. It hands developers a battle-tested sign-in flow, support for phone numbers, email links, and major social providers, and a dashboard that lets you peek at user growth without writing a line of SQL. For Australian teams, the appeal is even sharper because the service hosts data inside regional infrastructure, complies with the Privacy Act, and ships SDKs that play nicely with the rest of the Firebase suite.

Setting up auth the right way does take a little care. Skip a dependency here, leave a configuration file untouched there, and you will spend a Saturday afternoon staring at stack traces instead of watching the Test cricket. The walkthrough below covers every moving part of a modern implementation, from the moment you create a project in the Firebase console to the callback that fires when a user successfully signs in. Resources like Android Tutorial Point are handy when you want a second pair of eyes on the boilerplate, while the more granular bits of error handling are worth bookmarking for later.

Creating your Firebase project in the console

Open the Firebase console, click Add project, and give it the same package name as the Android Studio project on your machine. Most Australian teams name projects after their business domain, so com.aussieapps.superlative or similar, which keeps the project recognisable when the same developer is juggling two clients in Adelaide and a side project in Perth. Pick the analytics and Crashlytics toggles you want, agree to the terms, and wait for the provisioning wizard to finish spinning up your resources.

Once the project is ready, add an Android app to it. Firebase will ask for the application ID, a debug signing certificate SHA-1, and a nickname. Grab the SHA-1 from your Gradle signing report; this value also unlocks Google sign-in later, so do not skip it. After Firebase hands you a google-services.json file, drop it into the app module directory and double-check that the build is recognising it. A misplaced file is the kind of silent mistake that surfaces only when an emulator finally boots up.

Wiring up the Android SDK and dependencies

With the configuration file in place, head to the project-level build.gradle and add the Google Services plugin classpath, then apply the plugin inside the app module. Pull in firebase-auth and, if you plan to support Google sign-in, play-services-auth as well. Android Studio will offer to sync the project; let it finish, then look at the dependency tree to make sure no duplicate libraries slipped in.

It is also worth pinning the versions of every dependency you import. Firebase releases new SDK builds every few weeks, and an automatic upgrade on a long-running Australian retail app that integrates with Afterpay or a local loyalty provider can quietly break a release. Lock the versions in a libs.versions.toml file, and add a CI check that fails the build if anyone tries to bump them without a deliberate change. The result is fewer emergency Slack pings at 2am AEDT, and fewer late-night debugging sessions when a deprecated API call breaks production. For the gnarlier stack traces, an error handling guide breaks down the common pitfalls and the workarounds that actually work.

Choosing authentication providers that suit your users

Firebase supports email and password, phone, anonymous, Google, Facebook, Apple, Microsoft, Twitter, and GitHub out of the box. For an Australian consumer app, email plus Google covers most of the addressable market. Add phone authentication only if your target users include older demographics in regional Tasmania or the Northern Territory, where SMS still dominates over data-based sign-in. If you are building a tool for the local financial sector, layer in Sign in with Apple because the big four banks often require it for compliance reasons.

Each provider has its own enablement switch in the Firebase console. For Google, paste the OAuth client ID and secret from the Google Cloud console, then download an updated google-services.json. For Apple, register a Service ID with Apple Developer and paste the team ID, key ID, and private key into Firebase. Doing this once, in a calm hour, beats wrestling with the settings while the ATO filing deadline looms.

Building sign-in screens with XML and Kotlin

Most Android teams split the sign-in experience into two screens: one for new accounts, another for returning users. Keep the layout in XML with ConstraintLayout, two TextInputLayout fields, a primary Material Button, and a TextView that toggles between "Sign in" and "Create account". Style the typography with Roboto Flex so the design scales gracefully on the cheap end of devices that sell well at JB Hi-Fi.

In Kotlin, wire the button to a FirebaseAuth instance, call createUserWithEmailAndPassword or signInWithEmailAndPassword depending on the toggle, and attach a complete listener. The complete listener fires on the main thread, so it is the right place to start the next activity, persist a small flag in EncryptedSharedPreferences, and warm up your analytics. Make sure to surface meaningful error messages to the user, especially when the network drops on a flaky Telstra connection in a regional area.

Listening for auth state and managing user sessions

Firebase exposes an AuthStateListener that gives you a callback every time a user signs in, signs out, or the token rotates. Attach it in onStart and detach it in onStop so the listener does not leak when the activity pauses. This pattern lets you write a single decision point that decides whether to show the sign-in screen or the home screen, instead of scattering null checks across every screen in the app.

For long-lived sessions, persist the user's UID and a refresh token through Firebase's local persistence. When the user reopens the app after a fortnight in Bali or a business trip to Auckland, the SDK will silently revalidate the token and skip the login screen. Wrap this whole flow in a sealed Result class so the rest of your codebase can react in a Kotlin-idiomatic way. A clean auth foundation is what separates a weekend prototype from a product your investor in Barangaroo will actually back.

Fire up Android Studio today, create a fresh project in the Firebase console, and start wiring things up. Stick to version-pinned dependencies, test every provider on a real device, and keep your auth state callbacks predictable. Share what you build at the next MelbJS or SydJS meetup, file a PR against your team's internal auth template, and keep shipping polished Android experiences to the Australian market.