このページは__作成途中__であり、特にファクトチェックについて、この分野の専門家による確認が必要です。

このガイドでは、メタデータフィールドに何を保存するかについて、やや詳しい情報を提供します。ほとんどの項目は古くなっており、時間をかけてマニュアルに統合される予定です。

ソースコード

• 例 https://gitlab.com/fdroid/fdroidclient/tree/master

F-DroidサーバーはAPKを直接オンラインで公開するのではなく、APKをビルドするためのビルド可能なソースを必要とします。これにより、生成されるAPKが、隠れたアンチ機能を含まず、ソースコードを正確に反映していることをサーバーが保証できます。

F-Droidはすべてのアプリをソースコードからビルドします（Android SDK経由で、ant、gradle、mavenを使用し、場合によってはAndroid NDK、標準的なGNU/Linuxプログラム、BASHシェルでの少しの前処理も利用します）。そのため、ソース内に AndroidManifest.xml または build.gradle というファイルが見つかる場合、F-Droidでビルドできる可能性が高いです。

ほとんどのプロジェクトはビルド済みライブラリを利用している点に注意してください。これらのソースコードは別の場所にあります。antの場合、これらは libs/ フォルダーにあり、外部のものは project.properties ファイルで言及されます。gradleの場合、これらは build.gradle で言及され、通常はhttp://mvnrepository.comから取得されます。mavenの場合、依存関係を説明する pom.xml ファイルがあります。ネイティブコードのビルド済みライブラリが使用されている場合、それらは多くの場合 res/raw/ または assets/ にあります。これらについては README に何らかの説明があるはずです。上記の例には、テキスト参照付きのjarファイル依存関係が1つあり、外部ライブラリは使用していないため、追加の参照は不要です。

ライセンス

• 例 全体:

https://gitlab.com/fdroid/fdroidclient/blob/master/LICENSE（GPLv3+ ライセンスの下にあるソースコード全体）; - 例 ソースコードヘッダー: https://gitlab.com/fdroid/fdroidclient/blob/master/app/src/main/java/org/fdroid/fdroid/AppDetails.java（GPLv3+ ライセンスの下にあるファイルのヘッダー）; - 例 ライブラリ: https://gitlab.com/fdroid/fdroidclient/tree/master/libs（そのライブラリについては、Apache License, Version 2.0 ライセンスの LICENSE ファイルを参照）; - 例 アートワーク: https://f-droid.org/about（アートワークについては CC BY-SA 3.0 ライセンスを参照）

F-Droidリポジトリ内のすべてのアプリは、FOSS（自由かつオープンソースのソフトウェア）である必要があります。そのソフトウェアが、GNUライセンス一覧 に自由ソフトウェアライセンスとして掲載されているライセンスを明確に示していない場合、おそらくFOSSではありません。

アプリのソースコード内に README や LICENSE がない場合、F-Droidコミュニティが、ソースコード全体、ライブラリ、アートワークのそれぞれが適切な自由かつオープンソースのライセンスの下で公開されていることを確認するのは非常に困難です。そのため、ソースコードのすべてのファイルにヘッダーがあること、ライブラリフォルダーにテキストファイルがあること、またアプリに関連して見つかるすべてのもののライセンスを明確に説明する声明が、ソースコード内またはアプリの公式ウェブサイト上にあることを確認するのがよい慣行です。

注: GNU General Public License v2 の使用について、少し補足が必要です。Androidサポートライブラリやその他のほとんどの Androidライブラリは、Apache Licence の下でライセンスされています。技術的な 法的理由により、これらは GNU General Public License v2 と組み合わせることができません。GPLv2 の下でリリースされたアプリの場合、 そのアプリのソースコードヘッダーに「GPLv2 or later」と記載されている場合にのみ、 法的に認められます。その場合、全体のライセンスとして GPLv3 を選択できます（逆に GPLv3 は、 Androidサポートライブラリやその他の ライブラリと完全に法的互換性があるためです）。

概要

概要は、そのアプリが何をするものか、またはユーザーが何をできるようにするものかを説明する、できるだけ短いものにしてください。たとえば「E-mail client」ではなく「Receive and send e-mails」を使用します。

説明

説明は客観的で中立的な文体で書き、少なくとも最初の段落では、そのアプリケーションが何であり、どのような機能を備えているかを説明してください。その後に、特定の機能や問題についての簡潔なヘルプ、さらに詳しい情報を得るための外部リソースへのリンクを続けることができます。関連するアプリケーション、互換性のあるアプリケーション、必要なアプリケーション（ただし代替アプリケーションではない）へのリンクなど、追加情報も必要に応じて含めてください。

その他の注意点:

• 「Android向けのメモアプリ」のような表現は絶対に使わないでください。Android向けであることは明らかです。アプリであることも明らかです。
• 同様に、「これは自由ソフトウェアです」や「これはオープンソースです」とは書かないでください。それも明らかだからです。
• 互換性に関する注記（例：「Android 2.3以降向け」）は、自動的に処理されるため含めないでください。クライアントアプリが自動的に検出できない場合にのみ、互換性に関する注記を含めてください。
• 概要は常に説明と一緒に表示されるため、同じ内容を繰り返さないでください。
• F-Droidビルドが標準ビルドと異なる点がある場合は、その内容を説明してください。
• 開発者の視点で書かれた内容は絶対に含めないでください。たとえば「猫が好きなので、この猫ギャラリーアプリを作りました」のような表現です。

他に指定すべき情報としては、以下のようなものがあります。

• アプリにルート権限が必要ですか?
• 他のアプリと連携できますか?
• 簡単に使えますか?

寄付

プロジェクトが寄付を受け付けている場合、理想的な寄付リンクは、その目的のためにプロジェクトが管理している専用ページへのリンクです。そのようなページがない場合は、寄付アイコンなどがどこかに表示されているページへリンクするだけでも許容されますが、たとえばF-Droidクライアントで「Donate」を選択したユーザーが、その後ページ内で詳細を探さなければならないような場合、良いユーザー体験にはなりません。可能であれば、開発者に専用ページを作成するよう促してください。

好ましくない機能

さらに、一部のソフトウェアは、自由かつオープンソースのソフトウェアであっても、望ましくないと見なされる行為を行うことがあり、F-Droidではこれを AntiFeatures と見なします。可能な場合、F-Droidコミュニティはそれらのアプリケーションもリポジトリに収載しますが、ユーザーに警告するため、アプリに存在するアンチ機能をフラグ付けし、カタログ化します（F-DroidクライアントおよびWebリポジトリブラウザー上で表示されます）。アンチ機能があってもソフトウェアをF-Droidに収載できる場合はありますが、そのようなアンチ機能を含むソフトウェアは、実際には完全なFOSSではないこともよくあります（たとえば、広告やユーザーアクティビティの追跡は、非フリーのバイナリライブラリによって有効化されていることが多いです）。その場合、F-Droidリポジトリへのアプリの収載に支障が出ます。

更新

• https://gitlab.com/fdroid/fdroidclient/graphs/master
• https://gitlab.com/fdroid/fdroidclient/network/master
• https://f-droid.org/news-and-reviews

リポジトリにアプリを登録すればそれっきり、というわけではありません。バージョン、説明文、URLを最新の状態に保っておく必要があります。

最も重要なのは、新しいバージョンがいつ公開されたかを把握することです。これには、自動方式が3つ、手動方式が1つあります。タグから確認する方法、リポジトリの最新リビジョンにある AndroidManifest.xml を確認する方法、Google Playを確認する方法です。これらが使えない場合は、Google PlayのWebページを読み込むか、APKをダウンロードしてそのバージョンを確認し、アップストリーム開発者が公開したパッケージのバージョンを調べる必要があります。リポジトリのタグは、新しいバージョンにラベルを付ける自然な方法です（github.com の例では「releases」の下、SVNリポジトリの場合は「tags」ディレクトリの下を探してください）。タグが見つからない場合は、Issueトラッカーでその件についてIssueを作成すると役に立ちます。この例では、バックアップ用の確認先として変更履歴ページを指定しています。他にも、Google CodeのダウンロードページやGoogle Playリンクなどが考えられます。