Why AnkiDroid Removed Its Donation Link From Google Play

On August 28, 2026, an AnkiDroid release ran into a problem that had nothing to do with flashcards, synchronization, or Android code. Google Play rejected an update because the app contained a link leading users to an Open Collective donation page.

That sounds like a small button to lose. It is not. AnkiDroid is a free, open-source Android flashcard app with more than 10 million installs, and its maintainers say donations are the project’s main source of funding. As of September 1, the public dispute remains open, but the developers have already merged a store-specific workaround: the Google Play build no longer exposes the donation links.

The episode is a useful lesson in how app-store policies, nonprofit structures, and build engineering collide.

Why did Google Play reject a donation link when the app is free?

Google Play’s payments policy is mainly designed around a familiar rule: when an app charges for digital features, content, or subscriptions, the transaction normally has to use Google Play Billing, Google’s own payment system.

The policy also contains an important exception. Google Play Billing must not be used for several categories of payment, including tax-exempt donations. That creates a narrow path for apps that want to link users to an outside donation service. The donation must go to an eligible tax-exempt organization, and the payment system must be secure.

There is a second rule, though. Outside those exceptions, an app may not lead users to another payment method through buttons, links, web views, promotions, or account flows. AnkiDroid’s donation link landed directly in the middle of that boundary: Google saw an in-app link to an external payment page, while the AnkiDroid team believed the tax-exempt donation exception applied.

The disagreement was not about whether Open Collective could process a secure payment. It was about whether the organization receiving the money met Google’s definition of an eligible tax-exempt recipient.

The confusing part: 501(c)(6) is tax-exempt, but not a charity

AnkiDroid does not operate as a conventional corporation with a payment account in its own name. Its Open Collective project uses Open Source Collective as a fiscal host. A fiscal host is an organization that can receive money, manage expenses, and handle legal or administrative responsibilities for a project that may not have its own nonprofit structure.

Open Source Collective is organized in the United States under section 501(c)(6) of the Internal Revenue Code. This is a tax-exempt category commonly associated with business leagues, trade associations, chambers of commerce, and professional organizations. The organization’s income can be exempt from federal income tax while its funds are used for its stated nonprofit mission.

That status is different from section 501(c)(3), the category most people associate with charitable organizations. The difference matters to donors: contributions to a 501(c)(6) organization generally are not deductible as charitable donations on a federal tax return. “Tax-exempt” describes the organization’s tax treatment. “Tax-deductible” describes whether the donor can claim a deduction. They are related ideas, but they are not interchangeable.

AnkiDroid’s maintainers supplied Open Source Collective’s IRS determination letter to Google on July 21. Google’s August 6 response still described its requirement using the example of a validated 501(c)(3) charity. On August 7, support said the app was directing users to an organization that was not tax-exempt, even though the submitted document identified a 501(c)(6) determination.

That left the maintainers with a practical problem and no clear explanation of why the legal status was insufficient. Google’s warning said the app could be removed from most regions on September 11 if the issue was not fixed.

The engineering solution was to change one build, not the whole project

AnkiDroid is distributed through several channels, including Google Play, F-Droid, and direct releases. Those copies do not have to be identical. Android projects can use a build flavor, which is a named set of store-specific settings and source choices used to assemble a particular version of an app.

A simplified version of that idea might look like this:

productFlavors {
 create("play") {
 buildConfigField("boolean", "SHOW_DONATE", "false")
 }

 create("full") {
 buildConfigField("boolean", "SHOW_DONATE", "true")
 }
}

The example is illustrative rather than AnkiDroid’s exact configuration. The important idea is that one codebase can produce different packages. The Play flavor can follow Google’s rules while another distribution preserves features that are acceptable elsewhere.

On August 30, pull request 21657 merged the donation-link removal into the main development branch. A companion pull request, 21658, applied the same change to the release-2.24 branch. The changes disable controls that open the donation screen and remove clickable donation links from the HTML changelog. In other words, the team did not only hide one visible button; it checked other paths through which an automated review might discover an external payment link.

That detail is easy to miss, but it is the most technical part of the story. A policy check does not experience an app the way a human reviewer does. It may inspect screens, embedded web content, accessible labels, and navigation paths. A link that is harmless in a changelog can still be part of the app’s in-app experience.

A merged fix is not the same as a shipped update

The source-code workaround protects the project’s Play distribution, but merging a pull request does not immediately publish a new app. The branch still has to produce a signed Android package, pass the store’s checks, and move through Google Play review.

That distinction matters for users. As of September 1, the repository showed the donation-removal work merged, while the release process was still tied to the 2.24.1 maintenance milestone. The latest publicly listed GitHub release remained 2.24.0, so the code change and the downloadable release were separate stages of the story.

For Play users, the expected visible change is modest: the app continues to function as a flashcard client, but its Play-specific build no longer advertises the Open Collective donation route. The funding arrangement itself has not necessarily disappeared. The change removes the in-app link required for store compliance; it does not turn AnkiDroid into a paid app or change how the project is maintained outside that build.

The larger lesson for open-source maintainers

This dispute shows why funding infrastructure is part of software architecture. A project may have a transparent ledger, a legitimate fiscal host, and a valid tax-exempt determination, yet still fail an app-store review because the store evaluates the user-facing payment path differently from the tax authority.

Maintainers who distribute through large app stores need to document the entire chain: who receives the money, what legal status that organization has, which payment processor is used, and which builds expose the link. They also need tests for less obvious surfaces such as changelogs and embedded web pages.

AnkiDroid’s workaround is not a glamorous feature. It is a small, carefully targeted removal made under deadline pressure. But it captures a real truth about open-source software: keeping a free app available to millions of people can require as much attention to policy boundaries and release variants as to the code users came to install.