Most of an Android GitHub portfolio never gets read. The contribution graph is the least useful part. By default, GitHub’s graph shows only public activity. GitHub’s own 2025 data shows that most contributions happen in private repositories. So for many working engineers the graph is mostly blank, however hard they work. When a reviewer does open your profile, they usually look at one pinned project. They read its README and glance at the commits. That short look is what your portfolio should be built for. Pin two or three real projects, not six filler ones. Give each a README that states what it does and one Android decision it made, with the trade-off. Write commit messages that explain why. And turn on private contribution counts so your graph reflects real work. Below is a sample README for one small Android project.
Your contribution graph misses most real work
GitHub’s 2025 Octoverse report found that 81.5% of contributions happened in private repositories. It also reported 58 million new private repositories, up 33% from the year before. Most professional Android work sits in company repos that outsiders never see.
GitHub’s documentation on contributions on your profile explains the default. Private contributions don’t appear unless you opt in. The setting to show private contributions adds anonymized activity from private repositories. It shows that you’re committing, without exposing code or repository names. It won’t replace a public project. It stops a mostly blank graph from suggesting you don’t code.
Build your Android GitHub portfolio around two or three projects
GitHub lets you pin up to six repositories or gists. That’s a limit, not a target. Six slots filled with tutorial apps and forks give a reviewer six things to discount. Two projects with clear READMEs give them something to credit.
For an Android role, at least one pinned project should show an Android-specific decision. A weather app that fetches JSON into a list shows you can call an API. It doesn’t show platform judgment. A small app that explains why it uses WorkManager for sync, or where its ViewModel is scoped, does.
The example: a README that states a decision
Here’s a README for a small offline-first reading list app. It’s short enough to read in under a minute.
Reading List (Android, Kotlin, Compose) Save articles to read later, including offline. Key decision: Articles sync with WorkManager, not a foreground service. Sync isn't urgent, so WorkManager can batch it and respect battery limits. The trade-off is that a new save can take a few minutes to reach the server. The UI shows a "pending sync" badge until it does. Architecture: Single activity, Compose navigation. Room is the source of truth. One ViewModel per screen, scoped to its nav destination. Tests: ViewModel tests for loading and error states. A repository test for the offline fallback. Not done yet: Conflict handling when the same article is edited on two devices.
A reviewer can see what the app does and one decision with its trade-off. They also see what’s missing, stated honestly. That’s what a quick look can credit. The project details are illustrative.
Commit messages should explain the why
A reviewer who opens a repository often scans the recent commits. “Add pagination” says what changed. “Switch reviews list to Paging 3 to stop out-of-memory crashes” says why. The second tells a reviewer how you think.
What to change before your next application
- Unpin anything that’s a fork, a tutorial copy or unfinished filler.
- Keep two or three projects. Make sure at least one is Android-specific.
- Write a README for each with one decision and its trade-off.
- Rewrite recent commit messages on active projects to state the reason.
- Turn on private contribution counts in your profile settings.
A GitHub link may not be opened at all in many loops. When it is, a reviewer who finds one clear, specific project has something to act on. The same idea applies in interviews, as our post on being rejected after a good interview explains. Specific evidence outweighs volume.