Esta página é um trabalho em andamento e precisa da atenção de especialistas no assunto, especialmente na verificação de fatos.

Este guia fornece algumas informações mais detalhadas sobre o que armazenar em campos de metadados. A maioria dos itens estão desatualizados e serão mesclados com o manual ao longo do tempo.

Código-fonte

• Por exemplohttps://gitlab.com/fdroid/fdroidclient/tree/master

O servidor F-Droid não publica um APK diretamente online, mas o servidor F-Droid precisa de uma fonte compilável para compilar um APK dele. Desta forma, o servidor garante que o APK resultante representa com precisão o código-fonte sem quaisquer características indesejadas ocultas.

Porque o F-Droid compila cada app do seu código-fonte (através do SDK Android com ant, gradle ou maven, às vezes com a ajuda do Android NDK, programas padrão GNU/Linux e um pouco de pré-processamento no shell BASH), provavelmente se vê um ficheiro chamado AndroidManifest.xml ou build.gradle em suas fontes, haverá muitas possibilidades de F-Droid construí-lo.

Observe que a maioria dos projetos recorre a bibliotecas pré-construídas. O código-fonte para estes encontra-se em outro lugar. Para ant, estes estarão na pasta libs/ e os externos são mencionados nos ficheiros project.properties; para gradle, estes serão mencionados em build.gradle e normalmente são puxados de http://mvnrepository.com; para maven haverá ficheiros pom.xml que descrevem as dependências. Se bibliotecas de código nativo pré-construídas forem utilizadas, estas frequentemente encontram-se em res/raw/ ou assets/: deve haver algo sobre elas no README. O exemplo acima tem uma dependência de ficheiro jar com uma referência de texto e não usa nenhuma biblioteca externa, então nenhuma referência adicional é necessária.

Licença

• P. ex. Global:

https://gitlab.com/fdroid/fdroidclient/blob/master/LICENSE (total de um código-fonte uma licença GPLv3+); - E.g. Cabeçalho de código-fonte: https://gitlab.com/fdroid/fdroidclient/blob/master/app/src/main/java/org/fdroid/fdroid/AppDetails.java (cabeçalho de um ficheiro sob a liçença GPLv3+); - P.ex. Bibliotecas: https://gitlab.com/fdroid/fdroidclient/tree/master/libs (veja o ficheiro LICENSE com a Licença Apache, versão 2.0 para essa biblioteca); - P.ex. Obras de arte: https://f-droid.org/about (veja a licença CC BY-SA 3.0 para obras de arte)

Todos os apps no repositório F-Droid devem ser FOSS (software livre e de código aberto). Se o software não indica claramente uma licença que está listada como Licença de Software Livre na lista de licenças GNU então provavelmente não está.

Se não houver nenhum README ou LICENSE no código-fonte da app, é muito difícil para a comunidade do F-Droid verificar se todo o código-fonte, bibliotecas e artework estão liberados sob uma licença Free and Open Source adequada. Então, é uma boa prática verificar que o app tem cabeçalhos em cada ficheiro do código-fonte, um ficheiro de texto na pasta da biblioteca e uma declaração no código-fonte ou no site oficial da app que explicam claramente a licença sobre todas as coisas que encontram-se relacionadas ao app.

Nota Há uma pequena precisão a fazer sobre o uso do GNU Licença Pública Geral v2. A biblioteca de suporte Android e a maioria de outras bibliotecas Android estão licenciadas sob a Licença Apache. Devido a razões técnico-jurídicas, estas não podem ser combinadas com o GNU Geral Licença Pública v2. No caso de uma app lançada sob a GPLv2, é legalmente aceite somente se os cabeçalhos do código-fonte da app diz “GPLv2 ** ou depois”, podemos escolher a licença geral ser GPL**v3 (porque, pelo contrário, a GPLv3 está completamente legalmente compatível com a biblioteca de suporte Android e os outras bibliotecas).

Resumos

O resumo deve ser o mais curta possível a descrever o que o app faz ou permite o utilizador fazer, por exemplo, em vez de “Cliente de e-mail” use “Receber e enviar e-mails”.

Descrições

As descrições devem ser escritas num estilo objetivo, neutro, com pelo menos o primeiro parágrafo dedicado a descrever o que a aplicação é e quais recursos ela tem. Isso pode ser seguido com ajuda concisa para recursos específicos/problemas e ligações para recursos externos para obter mais informações. Informações adicionais, como ligações para aplicações relacionadas/compatíveis/obrigatórias (mas não alternativos), também devem ser incluídas, quando apropriado.

Outras notas:

• Frases como “uma app de anotações para Android” nunca devem aparecer. Obviamente é para o Android. Obviamente é uma app.
• Da mesma forma não diga “é software livre” ou “é open source”, porque obviamente é.
• Não deve ter quaisquer coisas relacionadas à compatibilidade (por exemplo, “para Android 2.3+”) porque isso será tratado automaticamente. Inclua somente notas de compatibilidade quando o app cliente não as detetar automaticamente.
• O resumo será sempre exibido com a descrição, por isso evite repeti-lo.
• Se houver algo diferente sobre a compilação do F-Droid comparado com um padrão, deverá ser descrito.
• Nunca deve ter nada escrito do ponto de vista do programador, por exemplo: “Escrevi este app de galeria de gatos porque gosto de gatos”.

Outras informações que merecem menção são:

• O app requer permissões de root?
• Pode interagir com outras aplicações?
• É fácil de usar?

Donativos

Quando um projeto aceita doações, o link de doação ideal seria para uma página específica que o projeto mantém para esse fim. Se um não existe, é aceitável apenas vincular a sua página que tem um ícone de doação ou similar em algum lugar sobre ele, mas isso não cria uma boa experiência do utilizador quando, por exemplo, alguém seleciona ‘Doar’ no cliente F-Droid e, em seguida, tem que procurar uma página para os detalhes. Tente incentivar os programadores a criar uma página dedicada, se possível.

AntiFeatures

Além disso, alguns softwares, mesmo a ser livres e de código aberto, podem fazer práticas que podem ser consideradas indesejáveis e que consideramos Características indesejadas”. Sempre que possível, a comunidade F-Droid ainda inclui essas aplicações no repositório, mas sinaliza e cataloga essas características indesejadas para avisar os utilizadores (no cliente F-Droid e no navegador do repositório web) por quaisquer características indesejadas presentes na app. Mesmo que o software possa ser incluído no F-Droid mesmo com características indesejadas, é frequente que o software com essas características indesejadas não seja totalmente FOSS (por exemplo, publicidade e rastreamento da atividade do utilizador são muitas vezes ativados por bibliotecas binárias não livres), a comprometer dessa forma a inclusão da app no repositório do F-Droid.

Atualização

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

Obter o app no repositório não é o fim da história: temos que manter as versões, descrições e URLs atualizadas.

O mais importante é saber quando novas versões são publicadas. Temos três métodos automáticos e um manual: de marcações; a verificar o AndroidManifest.xml na revisão mais recente no repositório; e a verificar o Google Play. Se isso não for possível, devemos olhar à versão do pacote publicada pelos programadores, seja a carregar a página web do Google Play ou a descarregar um APK e a verificar a sua versão. As marcações de repositório são a forma obvia de rotular novas versões (procure por elas em “lançamento” num exemplo em github.com ou no diretório “tags” no caso de repositórios SVN). Se não conseguir encontrar marcações, seria útil criar um problema sobre isso no rastreador de problemas. No exemplo, apontamos para uma página de changelog como uma verificação de backup; outras possibilidades são uma página de descarregamento do Google Code ou uma ligação do Google Play.