Submitting Patches to Android Open Source Store: How AI Takes Responsibility

AI can help you write code, documentation, and organize test steps, but if you contribute to open-source Android app stores like F-Droid, you are ultimately the one signing off. According to Debian voting results and discussions in the F-Droid admin repository, F-Droid is considering following suit, allowing responsible use of generative AI without mandatory labeling, but placing responsibility on contributors. The key issue in this track is liability boundaries, not tool efficiency.

For your first compliant contribution, start with low-risk tasks. Don't jump straight into modifying app code; look for README, CONTRIBUTING, or build instructions in the project repo. Beginners can add a section titled "AI Usage Responsibility Statement." Then click Fork on GitLab to copy someone else's project to your own space without affecting the original; expect your username to appear in the URL. Create a new branch, e.g., ai-responsibility-note. Branches are like temporary paths; confirm everything is okay before merging back. When drafting with AI, prompt it to write a contribution guide for open-source projects in Chinese, requiring contributors to understand, review, and test AI-generated content. Don't let it write specific version numbers or promise passing audits. After getting the draft, rewrite it sentence by sentence into a version you can explain. Ask yourself: Can I do this? Have I tested it? If you can't answer, delete it. For local verification, if only docs are changed, use git diff to see modifications; expect to see only your lines. If build instructions are involved, follow project docs to run them once; common command is ./gradlew assembleDebug, expecting BUILD SUCCESSFUL. When committing (Commit changes), write "Supplement AI usage responsibility statement." Finally, create a Merge Request, asking maintainers to merge your branch into the main project. List three things in the description: what was drafted with AI assistance, what you confirmed, and what commands you ran. Don't just write "tested."

This approach has a low barrier, is easy for maintainers to review, and lets you experience the open-source collaboration flow. The risk is that AI tends to overpromise, e.g., writing "all tests passed," which is a landmine if you haven't run them. It might also mix in inappropriate license snippets; compiling locally doesn't mean it's ready to submit.

Debian's stance passed this time is neither endorsing nor banning, but contributors must be able to understand, review, test, and modify themselves if necessary.

I've been using WorkBuddy for over three weeks, recently using Claude and Gemini for documentation assistance, and trying cloud vendor compliance checking capabilities these past few days. The experience is that AI easily creates false confidence; it's good for organizing templates, not for making judgments for you. In Android open-source app stores, judgments about whether apps are free/open-source, ad-tracked, or dependency-compliant cannot be outsourced to models.

The easiest pitfall is license contamination; search sources paragraph by paragraph and delete anything uncertain. Another pitfall is testing only success paths; it's best to deliberately delete an environment variable to see if the build errors as expected. Also, submission descriptions that are too short leave maintainers guessing what you tested; include commands and results.

If you want something lighter, open the F-Droid client, find an app you frequently install, go to its source repo, and raise an issue (a public question in the project) asking if they plan to adopt an AI policy. Next, try adding an "AI-Assisted Contribution Statement" to a commonly used open-source app and submit a small MR.