Verwenden Sie als Einstiegshilfe bei Arbeiten zur Aufnahme einer neuen Anwendung fdroid import, um eine neue Projektvorlage einzurichten. Es gibt zwei Arbeitsverfahren, mit einem geklonten Git-Repo anfangen:

git clone https://gitlab.com/fdroid/fdroidclient
cd fdroidclient
fdroid import

oder mit einer URL zu einer Projektseite beginnen:

fdroid import --url=http://address.of.project

Wenn eine Adresse durch Verwendung des Parameters --url= festgelegt ist, wird fdroid import diese verwenden, um Informationen zum Projekt herauszufinden, und wenn dabei ein Git-Repo gefunden wird, dieses auch klonen. Damit dies funktioniert, muss die URL auf ein Projektformat verweisen, das vom Skript verstanden wird. Momentan ist dies auf eines der Folgenden beschränkt:

1. GitLab - https://gitlab.com/<PROJECTNAME>/<REPONAME>
2. GitHub - https://github.com/<USER>/<PROJECT>
3. Bitbucket - https://bitbucket.org/<USER>/<PROJECT>/
4. NotABug - https://notabug.org/<USER>/<PROJECT>
5. Git - git://<REPO> oder https://<REPO>

Abhängig vom Projekttyp, können mehr oder weniger Informationen erfasst werden. Eine reine Repo-Adresse, wie z. B. die git:// , ist die von allen schlechteste Option, da hier viel mehr Informationen von Hand eingegeben werden müssen. Während auf gradle basierende Builds bei allen Typen selbständig erkannt werden sollten, können Verweise auf IssueTracker für einfache Git-Projekte nicht festgelegt werden. Sie können auch eines der folgenden Argumente verwenden, um Ihre Metadaten vorab auszufüllen:

• -u <URL>, --url=<URL>: Projekt-Adresse, von der importiert werden soll.
• -s <DIR>, --subdir=<DIR>: Pfad zum Haupt-Android-Projekt-Unterverzeichnis, wenn nicht im Wurzelverzeichnis.
• -c <CATEGORIES>, --categories=<CATEGORIES>: Kommagetrennte Liste der Kategorien.
• -l <LICENSE>, --license=<LICENSE>: Projektübergreifende Lizenz.
• --revision <REV>: Ermöglicht die Bestimmung einer abweichenden Revision (oder eines Git-Branch) für den initialen Import

Wenn der Import erfolgreich ist, wird eine Metadaten-Datei erstellt werden. Sie müssen diese, um die Informationen zu überprüfen, weiter bearbeiten und die Lücken darin füllen.

Wenn er fehlschlägt, wird Ihnen mitgeteilt warum. Wenn er soweit kam, dass der Quellcode abgefragt wurde, können Sie ihn sich in tmp/importer durchsehen, wohin er komplett ausgecheckt wurde.

Ein häufiger Grund für ein anfängliches Scheitern ist, dass das Projektverzeichnis eigentlich ein Unterverzeichnis im Repository ist. In diesem Fall führen Sie den Importvorgang nochmals aus und verwenden Sie die Option --subdir, um ihm mitzuteilen von wo. Er wird nicht den Versuch unternehmen, dies automatisch zu bestimmen, da es dafür verschiedenste Möglichkeiten geben kann.