F-Droid

FAQ - Programadores de apps

Como faço para incluir a minha app?

Por favor, verifique a política de inclusão para ter certeza de que a sua app é adequado para inclusão no repositório oficial do F-Droid. A maneira mais rápida de incluir uma app é de fazer um pedido de integração para fdroiddata, a seguir estas instruções. Também existe um guia de início rápido para enviar ao F-Droid. Os pedidos para embalar podem ser postados no rastreador Pedidos para Embalar.

Também pode configurar o seu próprio repositório e propriamente distribuir apps, fora do repositório F-Droid.org.

Como faço para alterar a descrição e adicionar meta-informação como screenshots?

Há três locais de onde retiramos metadados:

Embora não possa editar o último, as solicitações de mesclagem para o repositório de metadados a atualizar a descrição são bem-vindas. Screenshots, por outro lado, são atualmente usados apenas do repositório original.

Esperamos puxar mais coisas (por exemplo changelogs) diretamente do upstream no futuro, a dar aos programadores de app mais controle de como seu app é apresentado no F-Droid. No entanto, manteremos sempre um repo próprio mínimo e autoritário de metadados.

Como licencio meu app?

Existem, amplamente, duas categorias: copyleft e permissivo, os mais populares a ser a GPLv3 e o Apachev2 respetivamente. Escolha o primeiro se insistir que os derivados têm a mesma licença e o segundo se permitir qualquer tipo de reutilização.

A licença global deve ser compatível com a licença dos componentes. No entanto, concedemos alguma flexibilidade no que diz respeito a bens e recursos; por isso, se tiver, por exemplo, alguma música sob uma licença Creative Commons não comercial (ou seja, uma licença não livre), então aceitá-la-emos. O importante é incluir informações de direitos autorais para ativos, bem como código-fonte, nos cabeçalhos dos ficheiros e/ou no LEIAME. Uma cópia das licenças na raiz do repositório é útil (ficheiros LICENSE ou COPYING). Anote também os direitos autorais e as licenças referentes a recursos ou programas externos e, se ele se conectar a um serviço gratuito, considere usar a GPL Affero. Veja a Política de Inclusão para mais informações.

Como são doações tratadas?

No site e no cliente F-Droid fornecemos links para doar ao seu projeto. Idealmente deve ter uma página dedicada a explicar como e por que doar ao seu projeto, para que possamos criar um link direto para ele. Lembre-se que a maioria dos utilizadores provavelmente irão acessar isso diretamente do cliente F-Droid de um aparelho Android. Esta informação deve igualmente ser acessível do sua aplicação.

We have fields in our metadata for Bitcoin, Litecoin, Open Collective and Liberapay donations. Be sure to contact us if there is a change to any of those or if you stop accepting them; if you accept new methods you can contact us about that too.

Se o seu app está em nosso repositório, mas nos faltam quaisquer das informações acima, por favor, certifique-se de que nós o sabemos.

Meu app será construído do código-fonte?

Sim, em poucos casos (por razões técnicas ou históricas), construímos todas as aplicações diretamente do código-fonte. Isto garante que o código-fonte está disponível para a versão que as pessoas instalaram. Embora não estejamos a sugerir que o seu código-fonte está incompleto, não publicado ou desatualizado, isso acontece muitas vezes.

E quanto ao versionamento?

Android está ciente de duas informações de versão: o versionName (uma cadeia para o utilizador) e o versionCode (um inteiro que é comparado para determinar o que realmente é uma atualização). Para obter informações adicionais, consulte a Documentação do programador Android. Por favor, certifique-se de não ter informações contraditórias (por exemplo, contraditantes em AndroidManifest.xml e build.gradle).

Tentamos construir apenas o que consideraria ser lançamentos. Estes devem ter nomes de versão correspondentes e, ainda mais importante, códigos de versão correspondentes para versões que mesmo compilou e irá ser compilado do mesmo código. Obviamente esta tarefa é mais fácil se o histórico do seu código-fonte estiver claro - por exemplo, se as versões são marcadas ou rotuladas de outra forma. Se marcar o lançamento, por favor, assegure-se de manter o mesmo esquema de marcação, por exemplo, se começar a usar um prefixo “v”, continue a usar-o.

Tentamos não compilar de uma versão de cabeça de repositório aleatória.

Preciso dizer-lhe quando eu atualizar?

Iremos detectar novas versões do seu app e atualizar nossos metadados relativamente, o que nos fará verificar o código e adicionar novas compilações ao nosso sistema. Marcações ajudam muito para adicionar novas versões, mas lembre-se de empurrar as marcações para a repo de origem cada vez. Naturalmente, se mover o código-fonte para um site diferente, devia nos informar. Existem atualmente alguns problemas à volta da detecção de novas versões quando o AndroidManifest.xml é movido, então se houver alguma urgência, pode avisar-nos se isso acontecer.

Alguns programadores de apps enviam-nos solicitações de mesclagem com todos os dados de compilação relevantes quando são lançados. Não precisa de o fazer, mas pode acelerar a processo. Historicamente, como um pequeno projeto comunitário, temos sido mais lentos a processar atualizações do que gostaríamos de ser, mas essa situação melhora todo o tempo.

As nossas actualizações são estúpidas e só raspam ficheiros de construção: não executamos qualquer código de compilação, então não use versionamento baseado em tempo ou qualquer outro tipo de cálculo de sua versão no momento da compilação (por exemplo, a mover-os para várias subversões que são concatenadas na compilação ou mesmo a ter chamadas de função complexas para o fazer).

Publiquei uma nova versão. Porque não está no repositório?

Quando detectamos uma nova versão, pode levar alguns dias para que ela entre no repositório, pois o processo de criação tem várias etapas e é executado apenas uma vez por dia. Antes de a compilação estar concluída, a página de monitorização da sua aplicação irá listá-la em [Monitor F-Droid

  • Necessita de atualização](https://monitor.f-droid.org/builds/needsupdate). Desde que o texto sob Versions stating “A versão atual (recomendada) é xxx (versão código yyy)” mostra os números de versão correspondentes à sua última versão, detectámo-la e o APK deverá estar disponível em breve. Dá-lhe algum tempo.

Outro motivo pode ser o facto de a aplicação não ter sido construída. Pode ver o processo de compilação em F-Droid Monitor - Running e o ciclo anterior em Build.

E quanto a assinar?

Packages not setup for reproducible builds are signed by F-Droid keys. F-Droid will generate a new key for each app that is included. All of the different APKs built from different versions of an app will be signed by the same app key. But do note: if an app is also distributed in an APK signed by the developer, like in the Google Play Store, then the F-Droid APK will have a different signature.

O sistema operacional Android exige que, para que uma app seja atualizada no local, que tenha a mesma assinatura como a versão atualmente instalada. Isso protege contra a instalação inadvertida de uma atualização não confiável ou indesejada e também protege os dados privados da app, que só podem ser acessados por essa aplicação (ou uma aplicação ao qual acesso root foi concedida).

Esta situação apresenta um inconveniente menor para os utilizadores que querem mudar de uma versão assinada por uma parte para uma versão assinada por outra. Por exemplo, se um utilizador executa uma versão que instalou via F-Droid e depois deseja mudar para uma versão que assina e se distribui através de outro canal, ele teria que fazer o passo adicional de desinstalar e reinstalar o app. Por si só, isso não é suficiente para se qualificar como um pequeno inconveniente - no entanto, as consequências da desinstalação são que os dados privados da app são removidos (novamente, isso é para segurança), então o utilizador provavelmente vai primeiro querer exportar dados e depois reimportá-los.

We also support and encourage you to setup apps to be ready for reproducible builds, so we can build a version from source and check against your official release. If they match (ignoring the signature) we can then publish your official APK with your signature used. This is a tedious task, since we have to standardize on the build parameters and tools, but it should be worth it in the long run. We also try to verify our own builds and get a lot of binary differences, see our verification server results. However, things will improve over time.

Podem APKs assinados pela minha chave ser incluídos?

Sim, para reproducible builds o F-Droid irá incluir os seus APKs assinados no repositório oficial do F-Droid depois de terem sido verificados como tal. Se isto falhar (por exemplo, a sua aplicação não pode ser construída de forma reprodutível ou quando quiser distribuir uma aplicação com componentes de código fechado ou chaves API, etc.), pode colocar qualquer APK no seu próprio “F-Droid binary repo”, e as pessoas podem adicionar o seu repo ao seu cliente F-Droid para obter os seus APKs.

São necessárias compilações reproduzíveis?

No. But we do consider them best practice and hope you’ll consider trying to make your app reproducible. See our Submitting to F-Droid: Quick Start Guide for more information.

Como posso lidar com o “erro fsck em objeto empacotado” para a minha aplicação?

Para garantir que o nosso buildserver receba exatamente os mesmos commits que colocou no git, o git fsck é ativado por padrão sempre que novos commits são obtidos. Ative o git fsck assegura que os commits correspondem ao seu checksum SHA1. Às vezes, os repositórios git têm commits corrompidos, mas utilizáveis, que não podem ser alterados, pois todo o histórico é baseado no commit corrompido. Nestes casos, nós temos a funcionalidade skipList em fdroiddata

Posso executar meu próprio repositório de pacotes F-Droid?

Sim! Também pode configurar e executar seu próprio repositório F-Droid de apps e outros pacotes. Se também lançar seu próprio app através de outras lojas de apps, como o Google Play, recomendamos que também inclua essas versões em seu próprio repositório binário, que por entre outras razões, irá fornecer uma fonte de APKs para compilações reproduzíveis. Este repositório pode ser um “repo binário simples”, que não usa o sistema de construção fdroidserver, ou pode hospedar seu próprio espelho do repo F-Droid.org completo.

Posso ver quem está a instalar meu app?

Não. Embora as informações e métricas sobre instalações fossem interessantes e úteis para si, também nos obrigaria a rastrear e monitorar os nossos utilizadores, algo que não faremos. Não temos nenhuma informação sobre quais aplicações ou versões as pessoas instalam, se eles os mantêm instalados, que outro software ou versão de sistema operacional eles executam, ou qualquer outra coisa, então não podemos passar essa informação para si.

Posso rastrear utilizadores do meu app?

Pode, mas se incluir qualquer tipo de rastreio ou análise na sua aplicação (mesmo o envio de relatórios de falhas), isso deve ser algo a que o utilizador opte explicitamente por entrar - ou seja, pergunte-lhe na primeira execução, antes de enviar qualquer coisa para qualquer lugar, ou há uma preferência que é DESLIGADA por defeito. Em todos os outros casos, podemos ainda incluir a aplicação, mas será assinalada com a nossa funcionalidade anti-rastreamento, o que significa que os utilizadores só verão a aplicação se optarem por ver tais aplicações.

Além disso, note que as bibliotecas analíticas de terceiros que vêm na forma de software proprietário (por exemplo, Google Analytics ou Flurry) não são aceitáveis aqui.

Posso incluir publicidade?

Sim, mas:

  1. Muitos utilizadores não gostam de anúncios e os acham intrusivos. Marcamos aplicações que incluem anúncios, para que as pessoas saibam o que estão a receber. Eles podem escolher se estas aplicações serão-lhes mostrados ou não.
  2. Frequentemente, a incorporação de anúncios n uma app é feita pela inclusão de software proprietário na forma de uma biblioteca binária (ficheiro jar). Obviamente, isso tornaria seu app inelegível para inclusão.

Quais bibliotecas e dependências são boas para usar-las?

Para ser FLOSS, toda a sua app tem que o ser, a incluir dependências. Se usar bibliotecas não livres/proprietárias, não podemos compilar a sua app e, portanto, infelizmente não pode ser incluída no nosso repositório mainline (consulte “Posso executar o meu próprio repositório de apps?) , a excluir quaisquer bibliotecas que fazem parte do “repositório do Google” do gerente do SDK (por exemplo, play-services, fabric, firebase) – apenas o “repositório de suporte Android” é permitido.

For external resources, please restrain yourself to “well known repositories”, e.g. Maven Central or OSS Sonatype (see complete listing in the “srclib” section of Build Metadata Reference). Please note that sometimes these repos also host user-repos as well. Those are not part of the trusted repository list.

Se precisar de dependências que não estão disponíveis através desses repositórios, por favor não use ficheiros binários jar diretamente, mas forneça uma maneira fácil de compilá-los do código-fonte: por exemplo, a fornecer um script “pre-build”, a incluí-los no seu processo de compilação (tarefa gradle) e a incluir o código-fonte da biblioteca no seu projeto (hard ou por submódulo).

Substituição de “suspeitos habituais” conhecidos:

Note que todos os seguintes são apenas sugestões subjetivas baseadas em popularidade; pode haver outros projetos FOSS mais adequados para suas necessidades.

  • Crittercism, BugSense — ACRA, Bugmenot, Sentry
  • Google Analytics — Piwik
  • Google Maps — OpenStreetMap, e.g. through mapsforge, osmdroid or maplibre

O SDK e as bibliotecas do Google não são software livre e de código aberto?

Enquanto grande parte do Android é software livre de código aberto, muitos deles não são de modo nenhum. Os binários do SDK do Android são disponibilizados pelo Google sob uma licença proprietária, mas quase todo o código-fonte do SDK do Android está disponível sob a licença do Apache. As APIs do Google, usadas para criar apps a usar os serviços da Google como Mapas, GCM, etc., são gratuitas na medida em que a biblioteca vem pré-instalada no aparelho. Quase todas as bibliotecas do Google, como Play Services, Google Admob e GCM, são proprietárias e não podem ser incluídas no repositório principal do F-Droid.

Qual sistema de compilação usar?

Temos bom suporte para compilações baseadas em “ant” e “gradle”, enquanto “maven” foi usado apenas por pouco tempo e para dependências. Para outros sistemas de compilação, Pode ter que nos fornecer algumas informações detalhadas sobre como lidar com isso, para que possamos configurar o app corretamente ou talvez até mesmo incorporá-los em nossas ferramentas de servidor.

Nota especial sobre apps de Córdoba/Phonegap/HTML:

Não podemos construir aplicações cordova diretamente, mas a versão recente permite que exporte o código específico da plataforma que pode ser construído de forma independente a usar “gradle”. Então, por enquanto precisamos que este código esteja presente e atualizado no repositório fonte.

Como faço para remover a minha app?

A prática recomendada é que a nossa equipa de embalagem geralmente garante que tenhamos o consentimento dos programadores upstream, antes de adicionar apps ao repositório oficial de f-droid.org. Se você, por qualquer motivo, quiser que removamos a sua app do repositório oficial de f-droid.org, por favor, peça à nossa equipa de embalagem para fazê-lo. A maneira provavelmente mais rápida de obter a sua solicitação processada é de abrir um problema nos nossos rastreador de problemas de dados. Também pode entrar em contacto com a nossa equipa nos nossos outros canais de comunicação.

Como é que a minha aplicação pode ser removida?

Quaisquer alterações à sua aplicação que resultem na violação da nossa política de inclusão fará com que a sua aplicação seja removida ou arquivada. Por exemplo, você pode usar uma licença para versões futuras que proíba qualquer pessoa de distribuí-la ou pode introduzir binários proprietários no seu código-fonte. Ambos os procedimentos irão garantir que essas futuras versões não apareçam no nosso repositório, mas você teria que ir muito mais longe (por exemplo, falhas graves de segurança nas versões anteriores, combinadas com código-fonte não publicado e uma atitude não cooperante) para que nós removamos realmente a aplicação por completo.

Em alguns casos raros também temos de cumprir com pedidos de remoção de acordo com as nossas outras políticas. De um modo geral, recomendamos que se oriente de forma a não infringir marcas registadas e direitos de autor.

Vejo aplicações nas lojas grandes que são cópias óbvias. Não seria melhor se eu fizesse o meu app ser código fechado?

Firstly, it depends on the license: unless you apply a copyleft licence like the GPLv3, other people can do whatever they like with the source code (though they may be required to rebrand it). If your app is GPLv3 and no source code is published by the plagiarists; their versions obviously include proprietary ad libraries, or any sign of your authorship was simply removed, those copies are breaking the law and you should demand Google to remove them from their app store. You may threaten them with DMCA or other local laws if you wish. If all else fails, before going proprietary, balance the loss and confusion to the users and maintainers of the free app against the feeling of justice that you’ll get by seeing those illegal clones lose the few cents in ad revenue that they would have got. In the longer run we want to improve donations via F-Droid so you can be supported financially and we already support Bitcoin, Litecoin, Open Collective and Liberapay as well as any other payment method that you can suggest via a website.

Como o fluxo de trabalho git do cliente F-Droid é estruturado?

O git permite muitíssima flexibilidade no fluxo de trabalho de como as pessoas trabalham em conjunto e por isso é importante definir claramente o fluxo de trabalho desta comunidade para que as pessoas saibam o que esperar. O fluxo de trabalho git que o app cliente F-Droid usa é relativamente simples e tem base no fluxo de trabalho muito comum estabelecido por github.com, gitlab.com e outros parecidos. Aqui está uma descrição do que isso significa:

  • todo o trabalho de desenvolvimento acontece no ramo master
  • o código é apresentado para inclusão através de pedidos de fusão (Merge Requests, MRs)
  • lançamentos acontecem num ramo de lançamento estável e de curta duração por lançamento principal (e.g. stable-0.95, stable-0.96, stable-0.97, etc.)
  • o trabalho que vai para o ramo de lançamento estável deve ser bem focado e o mais pequeno possível para manter o ciclo de lançamentos o mais curto possível
  • o ramo master nunca deve ser mesclado com qualquer ramo de lançamento estável
  • ramos da versão estável nunca devem ser mesclados com o ramo master
  • Solicitações de mesclagem (Merge Requests) para um ramo de versão estável pode incluir commits de master
  • nem todos os commits que estão incluídos num ramo de lançamento estável precisam estar no master
  • o que faz nas suas bifurcações git é consigo, mas a solicitação de mesclagem final não deve incluir commits de mesclagem

Aqui está a discussão da reunião em que o determinamos: https://web.archive.org/web/20171220230923/https://botbot.me/freenode/fdroid-dev/2015-08-04/?msg=46407489&page=1

Este artigo inclui uma boa discussão sobre “ramos de recursos” contra “ramos de lançamento” e ramos de vida curta contra ramos de vida longa: http://blogs.atlassian.com/2013/11/the-essence-of-branch-based-workflows/

Procurar aplicações

Fazer um donativo

F-Droid é sustentado pelos seus donativos!

Connect

mastodon
@fdroidorg@floss.social

Notícias