# Facebook SDK for Android: Module Layout, Maven Install and What to Verify

> The Facebook SDK for Android is a set of Maven-published modules for login, sharing, Messenger, App Links and analytics in Android apps. The design is modular, the licence is not a standard open source one, and the documentation lives outside the repository.

**facebook/facebook-android-sdk** — Used to integrate Android apps with Facebook Platform.

- Repository: https://github.com/facebook/facebook-android-sdk
- Website: https://developers.facebook.com/docs/android
- Stars: 6,463 · Forks: 3,716
- Language: Kotlin
- License: NOASSERTION
- Published: 2026-09-22 · Updated: 2026-09-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/facebook-facebook-android-sdk

## What the Facebook SDK for Android actually solves

The README states the library "allows you to integrate Facebook into your Android app." That covers a specific set of surfaces: Login, Sharing, Messenger, App Links, Analytics, the Graph API and Marketing. If you are building an Android app that needs a Facebook login button, a share sheet, deep links that open your app, or app-event tracking, the SDK is the client that talks to those endpoints. The repository is written mostly in Kotlin, and the sample apps under samples/FBLoginSample, samples/HelloFacebookSample and samples/KotlinSampleApp show the intended shape of an integration.

The audience is narrow in a useful way: Android developers who already have a Facebook app registered and want the platform's own client rather than a hand-rolled HTTP layer. The README does not position the SDK as a general social graph library, and it does not claim to replace the Graph API documentation. It points to developers.facebook.com/docs/android for tutorials and reference material, which means the repository itself is mostly packaging, build files and samples.

## The module graph and the main-process constraint

The structure diagram in the README is the clearest thing in the repository. Facebook-Core sits at the bottom. Facebook-Common sits above it. Facebook-Login, Facebook-Share, Facebook-Messenger and Facebook-Applinks sit on top of that. The repository layout confirms this with directories: facebook-core, facebook-common, facebook-login, facebook-share, facebook-messenger, facebook-applinks, plus facebook-gamingservices, facebook-bolts, facebook-testutil and a facebook aggregator module.

That layering is the mechanism. Each published artifact pulls in the layers beneath it, so adding facebook-login does not require you to also add facebook-core by hand. The README makes the trade-off explicit: "To ensure the most optimized use of space only install the modules that you intend to use." That is a real constraint for APK size, and it is why the all-in-one artifact exists as a separate choice rather than the default.

The second constraint is process scope. The README states that "Any Facebook SDK initialization must occur only in the main process of the app" and that use in other processes "is not supported and will likely cause problems." If your app runs background work in a separate process, or uses a library that initializes in one, that is a design limit you have to plan around rather than a bug you can file.

## Installing facebook-android-sdk from Maven Central

The README gives the installation path directly: the modules are published to Maven as independent artifacts, and you add the ones you need to app/build.gradle. The example below is copied from the README and shows every module it lists. In practice you would keep only the lines you need.

```gradle
dependencies {
    // Facebook Core only (Analytics)
    implementation 'com.facebook.android:facebook-core:latest.release'

    // Facebook Login only
    implementation 'com.facebook.android:facebook-login:latest.release'

    // Facebook Share only
    implementation 'com.facebook.android:facebook-share:latest.release'

    // Facebook Messenger only
    implementation 'com.facebook.android:facebook-messenger:latest.release'

    // Facebook App Links only
    implementation 'com.facebook.android:facebook-applinks:latest.release'
}
```

The README also notes that you may need to add the Maven Central repository to your project-level build file. That block is short and worth pasting as-is:

```gradle
buildscript {
    repositories {
        mavenCentral()
    }
}
```

After a Gradle sync, the dependency should resolve from com.facebook.android coordinates and the SDK classes become available to your module. What you will not find in the README is an initialization snippet: it defers to the getting-started page at developers.facebook.com/docs/android/getting-started. If you want a first working screen rather than a dependency graph, the fastest route is to open one of the sample projects, since samples/FBLoginSample and samples/KotlinSampleApp are part of the repository and demonstrate the intended wiring. The README does not document rollback or downgrade steps, so version pinning is something you would decide yourself rather than follow from the docs.

## Where the SDK is the wrong tool

The clearest limitation is scope. If you need a provider-agnostic login layer that also handles Google, Apple or email, this SDK does not do that. It is a Facebook client, and the feature list is entirely Facebook surfaces. The module split makes that obvious: there is no generic OAuth module.

The developer terms in the README add a second boundary that is easy to skim past. They state that by enabling Facebook integrations you share information with Facebook, including information about people's use of your app, and that Facebook will use it in accordance with its Data Use Policy, including to provide insights about ad effectiveness. The terms also say you must give users "appropriate and sufficiently prominent notice" and obtain consent, and that you must not share information about children under 13. That is a product and compliance constraint, not a technical one, and it means the SDK is a poor fit for apps whose data-sharing posture cannot accommodate it.

The third limitation is operational. Because initialization is main-process only, an app architecture that isolates SDK work in a separate process will fight the library. The README does not offer a workaround, so treat this as a hard boundary rather than a configuration problem.

## How it compares with AppAuth for Android

AppAuth for Android is the natural alternative when the requirement is OAuth or OpenID Connect rather than Facebook specifically. The difference in approach is architectural. AppAuth is a client SDK for the OAuth 2.0 and OpenID Connect specifications; you configure an authorization endpoint, a token endpoint, a client ID and a redirect URI, and it works against any compliant provider, including your own. The Facebook SDK is the opposite: it is a provider-specific client whose modules map to Facebook features, and whose behaviour is defined by Facebook's platform rather than by a specification you can point at another server.

That has practical consequences. With AppAuth you own the provider configuration and can swap it. With the Facebook SDK you get Facebook Login, Sharing, App Links and app-event analytics as first-class modules, which AppAuth does not provide at all. If your app needs a Facebook share sheet or App Links handling, AppAuth is not a substitute. If your app needs one login flow across several identity providers, the Facebook SDK is not a substitute. The two can coexist, but they solve different halves of the problem, and the README does not discuss interoperability with either.

## Maintenance, releases and the licence question

The repository is not archived, and the last push was on 2026-09-14, which is recent. Release tags follow an sdk-version-N.N.N pattern: sdk-version-18.3.0 on 2026-06-25, sdk-version-18.2.3 on 2026-03-26 and sdk-version-18.1.3 on 2025-07-29. The README instructs contributors to submit pull requests to the main branch, noting that changes are merged into an internal main and then pushed out in the next release. That is a normal vendor-controlled release train, and it means your upgrade cadence is set by Meta's schedule rather than by your own patches.

Upgrade cost is mostly about the module split and the process rule. Because artifacts are published independently, a version bump is a dependency change per module, and the all-in-one artifact is the fallback if you would rather track one coordinate. The repository does not document a deprecation policy or a supported-version window in the README, so pinning a version and reading the CHANGELOG.md before upgrading is the practical approach.

On licensing: the README states the SDK is licensed under the Facebook Platform License, and the repository reports the licence as NOASSERTION because that licence is not on the standard list. The README also includes the usual "AS IS" disclaimer and a separate developer terms section. This is not a permissive open source licence in the Apache or MIT sense, and the developer terms are part of the deal. Whether that is acceptable depends on your legal review, which is outside what this article can settle.

## Conclusion

Adopt facebook-android-sdk if you already ship on Android and need Facebook Login, sharing, App Links or app-event analytics, and you accept that the SDK is maintained by Meta under the Facebook Platform License rather than a standard open source licence. Do not adopt it if you only need a generic OAuth provider, if you cannot disclose data sharing in your privacy policy, or if you need SDK calls from a non-main process, which the README says is unsupported. Before you commit, verify three things: that the module list still matches the features you need, that your app/build.gradle resolves com.facebook.android artifacts from mavenCentral, and that your legal review accepts the Facebook Platform License and the developer terms in the repository.

## FAQ

### What is the Facebook SDK for Android used for?

The README states the library allows you to integrate Facebook into your Android app. Its feature list covers Login, Sharing, Messenger, App Links, Analytics, the Graph API and Marketing.

### How do I install the Facebook SDK for Android?

Add the module you need to app/build.gradle using the com.facebook.android coordinates from the README, for example facebook-login or facebook-core, and add mavenCentral() to the repositories block in your project-level build file.

### Can I use the Facebook SDK for Android in a background process?

No. The README states that any Facebook SDK initialization must occur only in the main process, and that use in other processes is not supported and will likely cause problems.

### What licence is the Facebook SDK for Android released under?

The README says the SDK is licensed under the Facebook Platform License, which is why the repository reports the licence as NOASSERTION rather than a standard open source identifier. The README also includes a separate developer terms section.

### How do I keep the Facebook SDK for Android small in my app?

The README advises installing only the modules you intend to use, because the SDK is split into independent Maven artifacts such as facebook-login, facebook-share and facebook-core. The facebook-android-sdk coordinate pulls in everything.

## Sources

- [facebook/facebook-android-sdk on GitHub](https://github.com/facebook/facebook-android-sdk)
- [Issues](https://github.com/facebook/facebook-android-sdk/issues)
- [Project website](https://developers.facebook.com/docs/android)
- [README](https://github.com/facebook/facebook-android-sdk/blob/main/README.md)
- [Releases](https://github.com/facebook/facebook-android-sdk/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/facebook-facebook-android-sdk