Verwende 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. Du kannst auch eines der folgenden Argumente verwenden, um deine 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 Metadatendatei erstellt werden. Du musst diese, um die Informationen zu überprüfen, weiter bearbeiten und die Lücken darin füllen.

Wenn er fehlschlägt, wird dir mitgeteilt warum. Wenn er soweit kam, dass der Quellcode abgefragt wurde, kannst du ihn dir 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ühre den Importvorgang nochmals aus und verwende 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.