Avatar
Igor
b581c9123fb5ac1936b7d34854b6b6635844d7f1c39bb445876598fd7df8270f

Graças a Deus pelo Bitcoin - A criação, corrupção e redenção do dinheiro (Thank God for Bitcoin: The Creation, Corruption and Redemption of Money)

O ponto mais importante, na minha opinião, que esta obra traz é o entendimento de um contexto muito complexo: "Preferência Temporal".

Por definição, Preferência Temporal é a tendência humana de valorizar recompensas presentes mais do que recompensas futuras e de preferir que a satisfação de necessidades ocorra no menor tempo possível.

Mas o ponto complexo aqui é entender os resultados da alta preferência temporal, como o indivíduo é influenciado incoscientemente ao logo do tempo até chegar na situação que vivemos atualmente, onde este mesmo indivíduo não consegue visualizar que existe um problema no próprio estilo de vida, e que este problema pode ter sido causado/influenciado por fatores externos.

Eu, particularmente, passei a ver a vida com outros olhos após entender esse conceito e como ele influencia minhas decisões e consequentemente os resultados de médio e longo prazo. Acho que este é um assunto muito importante e muito menosprezado.

Segue as duas partes que mais me chamaram a atenção nesta obra e que possuem relação com "Preferência Temporal":

Pág 72 - Cap 6, AS CONSEQUÊNCIAS MORAIS DO DINHEIRO CORRUPTO

Vou resumir minha análise do livro para esse único trecho do cáp. 6 que fala sobre preferência temporal: “Um bom dinheiro permite que a comunidade planeje de forma eficaz, incentivando a poupança e nos dando uma razão para ter esperança no futuro”

Pág 102 - Cap 9, A REDENÇÃO DO DINHEIRO, Uma Nova Perspectiva Sobre o Tempo

“O Bitcoin ajuda seus proprietários a planejar a longo prazo. O Bitcoin não se desvaloriza, o que nos permite valorizar mais nosso tempo. O Bitcoin nos faz valorizar mais nosso tempo porque nosso trabalho pode ser armazenado em dinheiro que mantém seu valor. Como resultado, não nos preocupamos tanto com dinheiro e ficamos livres para buscar trabalhos mais significativos. O Bitcoin reflete a natureza escassa do tempo por ser perfeitamente escasso.”

#BestDifficulty 4,443.00

#NetworkDifficulty 126,271,255,279,307

#NerdMiner #NerdMinerV2 #TeamNerdMiner #BTC #Bitcoin

Você sabe que está com a pessoa certa quando ela prefere atravessar andando vários mapas no Ragnarok LATAM em vez de pagar o imposto de transferência remota de items/dinheiros!

Imposto é roubo!

#RAGNAROKLATAM nostr:nprofile1qywhwumn8ghj7cn0wd68ytnzd96xxmmfde68smmtduhxxmmd9uq3vamnwvaz7tm9v3jkutnwdaehgu3wd3skuep0qqsgg3jtfge602w352nmrzr8jmj2hxs5n0nhcdyal77tkc46dfe7s7ge0fkgs

Replying to Avatar Igor

# Qual a relação da KeyStore, PackageName e seu APP?

* Tentarei ser o mais didático possível, sem entrar em detalhes técnicos, com o objetivo de explicar um assunto muito complexo e de forma fácil para ser entendida, com isso estarei abstraindo detalhes técnicos que podem ser facilmente encontrados na documentação oficial do Android (use o Google para te auxiliar)

* Deixarei alguns links no final do artigo, caso tenha interesse.

* Se você não entender algumas palavras ou conceitos que forem citados, sugiro fortemente usar o Google para melhorar seus conhecimentos.

* Leia meus comentários que começam com [INFO EXTRA], para dicas e informações extras.

O Android identifica seu APP baseado no conjunto da KeyStore e do PackageName.

**PackageName**, tradução literal Nome do Pacote, é o nome do pacote do seu APP, aquele que segue o padrão **com.SeuSite.NomeApp**.

A KeyStore é uma hash utilizada para assinar seu APP. Ao assinar seu APP o JAVA vai utilizar os metadados do seu APP (PackageName incluso) e o resultado dessa assinatura será uma Hash específica.

Com estes dois dados, PackageName e KeyStore (assinatura), o Android consegue saber se seu APP é seu APP. Isso quer dizer que:

O mesmo APP feito em linguagens diferentes (Delphi e Flutter, por exemplo) mas que foram compilados usando a mesma KeyStore e PackageName serão considerados exatamente o mesmo APP para o SO Android.

Um exemplo contrário disso é: você pegar EXATAMENTE o mesmo projeto que você compilou há 5 minutos, mudar uma única letra do PackageName dele (mantendo a mesma KeyStore), o SO Android vai considerar este um APP completamente diferente, visto que agora a assinatura mudou (resultado da alteração do PackageName).

Mas o que aconteceria se Mantermos o PackageName igual MAS mudar a KeyStore? Sendo a KeyStore apenas uma hash utilizada para assinar seu APP, quando você for instalar o APP neste novo contexto o SO vai primeiro ver se existe um APP com mesmo PackageName instalado, se sim, vai verificar a assinatura do mesmo. Neste nosso caso nós mudamos a KeyStore, então a assinatura nova é completamente diferente da antiga, resultando em erro na instalação, visto que você já possui um APP instalado com mesmo PackageName mas assinado com uma KeyStore diferente.

Este é um processo utilizado pela Google para assegurar que ninguém além de você vai conseguir sobrepor seu APP no celular do usuário e fazer coisas maliciosas.

Agora vamos começar a parte difícil. Se você chegou até aqui e não entendeu nada, sugiro não continuar lendo. Vá usar o Google e/ou ChatGPT até entender o que foi escrito até agora.

# Mas por que tudo isso é importante?

Isso é importante PRINCIPALMENTE como nós, desenvolvedores, distribuímos os APPs para nossos clientes e adicionalmente como o Delphi ‘assina’ nossos APPs.

## Vamos primeiro entender o Delphi:

O Delphi possui dentro de “Target Platforms-Android(32/64)-Configuration” duas opções: **Application Store** e **Development** (você pode verificar essa configuração como na foto à baixo OU em “Project-Options-Deployment-Provisioning”)

Sempre que você compilar seu APP utilizando o tipo **Development** o Delphi vai usar uma KeyStore aleatória (normalmente chamada de **debug.keystore**) para assinar seu pacote.

Pontos importantes:

- Esse arquivo **debug.keystore** é criado do zero SEMPRE que você instala o Delphi, isso quer dizer que, dois Delphis instalados no seu PC terão cada um uma **debug.keystore**.

- Você possui o Delphi XYZ instalado e compila seu APP direto no seu celular, se você instalar uma atualização, Delphi XYZ.1 por exemplo, ele gerará um novo **debug.keystore**, na próxima vez que você tentar compilar seu APP no mesmo aparelho, você verá um erro.

- Se por acaso você instalar exatamente a mesma versão do seu Delphi em outro PC (ou até mesmo re-instalar no seu PC), ele irá criar um novo **debug.keystore**.

(todos os casos citados vão gerar o mesmo problema descrito no começo deste artigo: KeyStore diferentes geram assinaturas diferentes)

## O que acontece quando tentamos compilar na configuração **Application Store**?

Com esta configuração o Delphi espera que você, desenvolvedor, tenha especificado corretamente sua própria KeyStore em “Project-Options-Deployment-Provisioning” (atente-se ao **Target**, precisa estar selecionado algum Android).

O Delphi vai pegar seu arquivo KeyStore e assinar seu APP na hora da compilação.

Usando os conhecimentos anteriores deste artigo, podemos imaginar que neste contexto, se você manter seu PackageName sempre igual e o Delphi usando sempre exatamente o mesmo arquivo KeyStore que você criou anteriormente, o Android vai sempre considerar seu APP exatamente o mesmo APP, não importando a versão do Delphi, ou até mesmo se você usar outra ferramenta para compilar seu APP (Flutter, por exemplo).

Isso acontece porque você está mantendo sempre a mesma KeyStore (hash) e PackageName para assinar seu APP.

## Mas como tudo isso influencia na forma como nós, desenvolvedores, distribuímos nossos APPs?

Vou dar um exemplo prático em vez de algo teórico:

O Dev fez um APP super legal, mas infelizmente não tem dinheiro OU não quer passar por toda a burocracia necessária de distribuição pela loja. Ele manda seu APK para um amigo, que gosta muito da sua solução, então manda para outro amigo, para outro, então para outro, outro e etc. No fim do ano, O Dev já tem quase mil pessoas utilizando seu APP, ele colocou Ads (propaganda), botão de doação e outras milhares de coisas que já estão rendendo para ele uma boa grana.

Acabou de sair o Android novo XYZsuper, seus usuários não esperam e já atualizaram seus aparelhos e infelizmente o APP não é mais compatível com esta nova versão. O Dev então atualiza seu Delphi para nova versão e gera um novo APK, compatível com essa nova versão do Android, e distribui para o auto-atualizador! Mas seu APP não consegue mais se auto-atualizar, aparece um erro de incompatibilidade ou “APP não foi instalado”.

Depois de dias na luta, estudando Delphi, lendo a documentação do Android… O Dev encontra este artigo aqui no NOSTR e compreende onde errou:

Ele compilou o APK dele em modo DEBUG. Agora com o novo Delphi o APK foi assinado com uma nova KeyStore, nem copiando o arquivo antigo **debug.keystore** para o novo Delphi resolveu o problema.

A única solução viável para O Dev é:

Criar uma KeyStore própria (salvar a sete-chaves onde não irá se perder), manter o mesmo PackageName e passar a distribuir o APP compilado em modo **Application Store**.

Mas todos usuários terão que remover o APP atual e instalar novamente, infelizmente talvez alguns usuários não estarão dispostos a este trabalho todo.

Depois de ter aplicado a correção e os usuários interessados terem realizado o processo de ‘atualização’ manual, o processo de Self Update do APP deverá funcionar normalmente, enquanto O Dev usar o mesmo arquivo de KeyStore e PackageName.

[1] Alguns detalhes mais técnicos sobre como a assinatura do seu APP funciona: https://developer.android.com/studio/publish/app-signing

[2] Artigo original publicado no Discord do “Adriano Santos Community”: https://discord.com/channels/824480379616493589/831906746318454824/942523981536321586

#Delphi #Embarcadero #RadStudio #Android #APP #Mobile #Dev #Development #KeyStore #PackageName #Provisioning #ApplicationStore

A versão Delphi 12.3 permite selecionar separadamente a KeyStore para os modos DEBUG e Development, oque permite a geração assinada correta do APK em 64bits, ou seja, configure corretamente e compile normalmente.

Receber o reconhecimento de profissionais que admiro, como o Landerson Gomes, é uma honra que eleva ainda mais a motivação para continuar entregando o melhor.

Este vídeo, inicialmente gravado para reforçar minha capacidade técnica e transmitir confiança a um novo cliente, ficou tão autêntico e especial que decidi compartilhá-lo nas minhas redes profissionais (com a devida autorização).

Muito obrigado, Landerson, pelo feedback valioso e por endossar meu trabalho com tanta sinceridade. Seguimos juntos, comprometidos com excelência e transparência!

https://youtu.be/tWLuyHbMmkc

Para quem é dos anos 2000 vai se lembrar da abertura do Digimon, e se você é Brasileiro, vai se lembrar da Angélica (1) contando na Rede Globo.

O que acham da paródia que criei com o ChatGPT? Lembre-se de ler "cantando" no ritmo da música 'original' 😅

Bitcoin digitais

Bitcoins são campeões

Bitcoin digitais

Bitcoins são campeões

Eles vão ser minerados

Blocos para confirmar

Juntos combatem a fraude

São os guerreiros do token

Nesse mercado virtual

Os bitcoins são demais

Bitcoin digitais

Bitcoins são campeões

Bitcoin digitais

Bitcoins são campeões

Bitcoin é nossa moeda

Bitcoin é nossa esperança

Basta a crise chegar

Eles vão se valorizar

São os investimentos da paz

Os bitcoins são demais

Bitcoin digitais

Bitcoins são campeões

Bitcoin digitais

Bitcoins são campeões

Bitcoin digitais

Bitcoin

(1) Abertura 1 - Digimon https://www.youtube.com/watch?v=HbHLrBg2o8M

I didn't vote because Bitcoin is not crypto, si any answer would be wrong 🤷‍♂️

Introdução ao desenvolvimento de jogos de forma fácil e didática.

Leia, aprenda e suba uns leves 🫡

nostr:naddr1qpqxvdtpv33rwwfhxvex2cecxf3xxdnzxfjrzve3v43kydmyvgmrvvmzvejnwdmpxccn2vrxxesngvmy8qengvtzxc6kyer9xaskgve3v5q3wamnwvaz7tmjv4kxz7fwwpexjmtpdshxuet59upzppzxfd9r8faf6x320vvgv7twf2u6zjd7wlp5nhlmewmzhf4886reqvzqqqrkcg4er78j

[OFF]

Aleatoriamente um amigo [Amigo1] questionou outro amigo [Amigo2] (que cursou/cursa filosofia) sobre o ato de “cagar nas calças”, o Amigo1 então resolveu criar uma dissertação sobre o assunto com a ajuda do ChatGPT.

Compartilharei aqui o decorrer deste acontecimento aleatório, somente e apenas porque sim 🤷‍♂️…

Dissertação, se é que podemos chamar assim, do Amigo1, criada no ChatGPT sobre o ato de “Cagar nas calças”:

“O ato de "cagar nas calças", quando analisado filosoficamente, revela um encontro visceral entre o corpo humano e suas limitações, desafiando conceitos de dignidade, liberdade e controle. Este fenômeno, muitas vezes relegado ao plano do humor ou do constrangimento, guarda profundas lições sobre a vulnerabilidade humana e a ruptura entre o desejo e a realidade. O filósofo Jean-Paul Sartre, em O Ser e o Nada, explora a noção de má-fé como um autoengano para evitar o confronto com a verdade de nossa liberdade e responsabilidade. O ato de "cagar nas calças" pode ser interpretado como a recusa involuntária da autonomia corporal, expondo o ser a uma verdade inescapável: somos criaturas finitas, sujeitas a falhas físicas. A questão é: o que este evento pode nos ensinar sobre a condição humana? Maurice Merleau-Ponty, em Fenomenologia da Percepção, argumenta que o corpo não é meramente uma máquina, mas uma dimensão fundamental de nossa existência. Quando o controle fisiológico falha, como no ato de evacuar involuntariamente, somos lembrados de que o corpo é um terreno de contingências, que nem sempre se submete à nossa vontade. Em A Ideia de Justiça, Amartya Sen explora como normas sociais moldam nossa percepção de dignidade. O constrangimento de "cagar nas calças" não surge apenas do ato em si, mas da consciência de que ele viola as expectativas culturais de autocontrole. Michel Foucault, em Vigiar e Punir, poderia acrescentar que tais normas são instrumentos de poder, reforçando o autocontrole como uma forma de disciplina social. O evento também dialoga com a clássica tensão entre liberdade e determinismo. Friedrich Nietzsche, em Assim Falava Zaratustra, sugere que aceitar nossa natureza caótica é um ato de liberdade suprema. Evacuar involuntariamente, portanto, desafia a noção de que temos pleno domínio sobre nossas ações, obrigando-nos a reconsiderar o papel do acaso em nossa existência. "Cagar nas calças" é mais do que uma falha fisiológica; é um momento de verdade ontológica. Ele destrói a ilusão de controle absoluto e nos conecta à vulnerabilidade inerente à condição humana. Ao invés de ser um tabu, o ato pode ser ressignificado como um lembrete de que a humanidade é definida, em última análise, por sua imperfeição.”

Respostas do Amigo2, que entrou no debate sem inicialmente ter conhecimento que a dissertação tinha sido escrita pelo ChatGPT. As respostas foram enviadas em pequenas partes via WhatsAPP, sendo assim estarei postando em várias linhas:

- “Uma perspectiva nem se coloca na outra”

- “Muito menos tem sentido dessa forma”

- “Até dá pra analisar a situação em si, mas não porcamente assim”

- “Gpt?”

- “Tem muita cara de ser feito no gpt, um ser humano articula melhor”

- “Não, qual ameba faz melhor”

- “E a articulação”

- “Não é o conteúdo”

- “Não dá pra usar Nietzsche e Foucault falando sobre se ter controle absoluto de algo

- “Falar de Nietzsche e falar que precisa reconsiderar o papel do acaso é se fuder”

- “Nietzsche justamente defende que a vida precisa ser vivida, tem obstáculos, tem intensidade e que precisa ser intensa, acha que esse mesmo cara vai ser um cara que diz que a gente tem controle de tudo e a partir disso então reconsiderar o acaso?”

- “Nietzsche e Foucault falam sobre a humanidade, não pressuporiam absurdos”

E esse é o tipo de conversa produtiva que temos no meu círculo de amigos.

[Imagem gerada por IA utilizando Grok, criado pela xAI.]

"Bitcoin e Propriedade" [1], autor nostr:npub1wsws3wjgq7dl5h3hhavn2gqht493yudhafwjd9cwfx8wsfse496qx9stqv

E imaginar que o Bitcoin, de forma tão óbvia, acabou com um argumento que tenho carregado por muito tempo:

Não existe patente/propriedade de produtos digitais.

Eu, sendo um desenvolvedor de software e libertário, nunca me senti confortável com a ideia de patentes sobre produtos e serviços digitais.

Patente, diferentemente de direito de propriedade, já é uma definição ridícula, a situação piora quando falamos de patentes de produtos e serviços digitais.

Na teoria, propriedade de um bem só faz sentido no caso de este bem/recurso for escasso (conceito abordado tanto por David Hume, citado no artigo em questão, por Rothbard e Hayek). Sendo assim, se o recurso não é escasso, não faz sentido lógico aplicar teorias de propriedade privada.

Um recurso digital, até antes do Bitcoin, nunca foi escasso. Você pode copiar um arquivo e distribuir ele quantas vezes você quiser, isso não vai obrigatoriamente impedir que outros indivíduos tenham acesso ao mesmo arquivo por culpa de escassez ou afins.

Visto a não escassez, logicamente, você poderia continuar usando seu editor de imagens sem licença de software, sendo que tudo rode localmente sem utilizar recursos externos de terceiros.

Logicamente, não deveria ser considerado crime assistir a um vídeo ou filme que foi baixado de um site suspeito mas que ainda nem foi lançado nos cinemas.

(Antes que alguém tente me processar, gostaria de deixar claro que não estou fazendo apologia à pirataria, esta prática é proibida em vários países e regiões, por favor, atente-se às leis e regras da comunidade em que você se localiza)

Tudo isso muda com Bitcoin!

Ao introduzir seu sistema de consenso, prova de trabalho e descentralização, Bitcoin se torna o primeiro recurso digital a ter garantia da propriedade privada (e apesar de eu não me sentir confortável com a definição, garantia da patente) ao prover ao seu 'proprietário' acesso ao recurso apenas e somente com a posse da(s) Seed(s).

Como o nostr:npub17hgdpn9xnt5zyxlx8pz0uuus8d23pxwr9a5vq96nw5nawx20zxnsj6fym6 sempre diz:

Se o proprietário das chaves não quiser, nem os herdeiros recebem os Bitcoins.

[1] https://paipe.substack.com/p/bitcoin-e-propriedade

Depends, do I died while doing it?

Or, is it like the Westworld's series theory? Some technology that copies everything that makes you, you. Replicate perfectly the consciousness, so when you die, turn on the Robot and "life" keeps going.

Important to note that your human life is gone naturally, but now with your copied consciousness ON, it is like you just took a snap and woke up to a new day.

[Vídeo]

Delphi/Lazarus integração com CoinOS API

Permita que seus clientes recebam em Bitcoin, assim como já recebem com Cartão, PIX, dinheiro, etc. Rápido e sem rastro.

Vídeo apresentando o passo-a-passo (e um pouco mais) sobre a integração com a API da CoinOS, uma carteira Lightning de Bitcoin.

Fique à vontade para tirar dúvidas.

#CoinOS #Delphi #Lazarus #Delphi #Embarcadero #Lives

https://www.youtube.com/watch?v=l4bSgcR4Z5c

I liked it

Person: " cool, you invest in Bitcoin"

Answer: "no, I buy Bitcoin, I'm investing in freedom!"

Replying to Avatar Igor

# Vamos falar sobre assinatura de um APK?

Neste artigo gostaria de falar sobre como podemos assinar um APK ‘manualmente’, mas por que alguém iria querer fazer isso sendo que o Delphi já assina automaticamente o APK/AAB?

Antes de responder, gostaria de recomendar a leitura de outro artigo que escrevi “Qual a relação da KeyStore, PackageName e seu APP?” [1], não continue a leitura se você ainda não leu/entendeu este artigo! Atente-se também aos comentários no mesmo artigo, visto que são importantes para melhor entendimento do problema dos dois assuntos.

Respondendo à pergunta:

Muitos são os casos que precisamos distribuir nossos APKs fora da loja, e baseado no artigo sobre a KeyStore sabemos que precisamos compilar nosso APK em RELEASE+Application Store, só que em 64bits o Delphi (10.4+) gera um AAB e não um APK.

Neste artigo irei demonstrar uma das várias técnicas possíveis de ter seu APK Release 64bits para ser distribuído para seus clientes.

Fiz testes apenas nas versões do Delphi 10.4.2 e 12.2, então talvez para sua versão possa ser diferente, sinta-se à vontade para fazer uso do Google caso encontre algum problema. Ele costuma ajudar bastante.

Devido a diferenças entre as duas versões do Delphi, estarei escrevendo nos comentários a solução proposta para assinatura do APK Release 64bits.

Por favor, leia a parte de [Pré-requisitos] e depois encontre o comentário que atende à sua realidade. Talvez sua versão do Delphi seja diferente, mas seu SDK possui os arquivos corretos para o ‘serviço’, o que também resolverá o problema.

Também recomendo o uso do software “Everything” [2], que facilitará muito encontrar arquivos no seu PC.

[Pré-requisitos] comuns entre todas versões do Delphi:

Para começar, vamos primeiro gerar o APK em 64bits, seguindo na contramão do artigo “Qual a relação da KeyStore, PackageName e seu APP?”

Pq? Para não gerarmos automaticamente o AAB, visto que não precisamos de um AAB, mas sim um APK.

Por favor, configure e compile seu projeto na seguinte configuração:

Target: Android 64 bits

Build: RELEASE

Configuration: Development

Baseado no artigo “Qual a relação da KeyStore, PackageName e seu APP?”, sabemos que o APK resultante neste processo será assinado com uma KeyStore aleatória do Delphi, o que é NÃO recomendado, mas aqui entra a beleza da solução proposta…

Agora vá nos comentários e encontre a solução que atenda seu ambiente de trabalho.

# Referências:

[1] “Qual a relação da KeyStore, PackageName e seu APP?” https://nostrudel.ninja/#/n/nevent1qvzqqqqqqypzpdvpeyfrlddvrymt056g2jmtvc6cgntlrsumk3zcwevcl47lsfc0qyt8wumn8ghj7mn0wd68ytnyv96xztngv96hxtcpr3mhxue69uhhxarjvee8jtnwdaehgu3wd35kw6r5d9hxwtcqyzaq6e4lgapz6fc5n28vhepekrhtheguwe2lsxu39chyl3mey895sfhmc8l

[2] Everything https://www.voidtools.com/downloads/

#Delphi #Embarcadero #RadStudio #Android #APP #Mobile #Dev #Development #KeyStore #Sign #Signature #ApplicationStore

[apksigner.bat]

Tenha certeza de ter gerado o APK assim como indicado na seção anterior, de Pré-requisitos [1].

Para fazer a assinatura manual, vamos precisar do arquivo “apksigner.bat” que já deve estar instalado no seu ambiente. Caso você não saiba onde ele está, utilize o programa “Everything” ou afins para encontrar o arquivo. Caso você não encontre o arquivo “apksigner.bat” no seu ambiente pode significar que o Delphi não baixou o “build-tools” do SDK automaticamente, por favor, leia o comentário [build-tools] que explico como baixar.

Vamos precisar do terminal do Windows, o CMD, e rodar o seguinte comando (substitua os nomes entre <> pelos valore reais):

sign --ks --ks-key-alias --ks-pass pass: --key-pass pass: --out

Explicação:

caminho_completo_do_apksigner.bat: o caminho completo do arquivo “apksigner.bat”, utilize aspas duplas em caso de ter espaços no caminho;

caminho_completo_para_o_seu_keystore: o caminho completo para seu arquivo “.keystore” criado por você para este projeto, utilize aspas duplas em caso de ter espaços no caminho;

alias_da_chave: o Alias da sua KeyStore

senha_do_keystore: a senha da sua KeyStore

senha_da_chave: a senha do Alias

caminho_completo_para_o_apk_assinado: o caminho completo para o APK assinado, de destino final onde será salvo o arquivo assinado. NÃO utilize o mesmo nome do arquivo original, utilize aspas duplas em caso de ter espaços no caminho;

caminho_completo_para_o_apk_original: o caminho completo do APK origina, o mesmo que foi compilado no Delphi em modo Release, utilize aspas duplas em caso de ter espaços no caminho;

Após rodar este comando com sucesso, o arquivo deverá ser seu APK re-assinado com a sua KeyStore original, pronto para ser enviado para o cliente.

[1] “Artigo, pré-requisitos” nostrudel.ninja/#/n/nevent1qvzqqqqqqypzpdvpeyfrlddvrymt056g2jmtvc6cgntlrsumk3zcwevcl47lsfc0qy88wumn8ghj7mn0wvhxcmmv9uq3qamnwvaz7tmwdaehgu3wd4hk6tcqyrdjvn6cu4rhhrskz6gpanwlnv92tyraqzy6weaf8x79uzh3k0k6yf8qnsd

Replying to Avatar Igor

# Vamos falar sobre assinatura de um APK?

Neste artigo gostaria de falar sobre como podemos assinar um APK ‘manualmente’, mas por que alguém iria querer fazer isso sendo que o Delphi já assina automaticamente o APK/AAB?

Antes de responder, gostaria de recomendar a leitura de outro artigo que escrevi “Qual a relação da KeyStore, PackageName e seu APP?” [1], não continue a leitura se você ainda não leu/entendeu este artigo! Atente-se também aos comentários no mesmo artigo, visto que são importantes para melhor entendimento do problema dos dois assuntos.

Respondendo à pergunta:

Muitos são os casos que precisamos distribuir nossos APKs fora da loja, e baseado no artigo sobre a KeyStore sabemos que precisamos compilar nosso APK em RELEASE+Application Store, só que em 64bits o Delphi (10.4+) gera um AAB e não um APK.

Neste artigo irei demonstrar uma das várias técnicas possíveis de ter seu APK Release 64bits para ser distribuído para seus clientes.

Fiz testes apenas nas versões do Delphi 10.4.2 e 12.2, então talvez para sua versão possa ser diferente, sinta-se à vontade para fazer uso do Google caso encontre algum problema. Ele costuma ajudar bastante.

Devido a diferenças entre as duas versões do Delphi, estarei escrevendo nos comentários a solução proposta para assinatura do APK Release 64bits.

Por favor, leia a parte de [Pré-requisitos] e depois encontre o comentário que atende à sua realidade. Talvez sua versão do Delphi seja diferente, mas seu SDK possui os arquivos corretos para o ‘serviço’, o que também resolverá o problema.

Também recomendo o uso do software “Everything” [2], que facilitará muito encontrar arquivos no seu PC.

[Pré-requisitos] comuns entre todas versões do Delphi:

Para começar, vamos primeiro gerar o APK em 64bits, seguindo na contramão do artigo “Qual a relação da KeyStore, PackageName e seu APP?”

Pq? Para não gerarmos automaticamente o AAB, visto que não precisamos de um AAB, mas sim um APK.

Por favor, configure e compile seu projeto na seguinte configuração:

Target: Android 64 bits

Build: RELEASE

Configuration: Development

Baseado no artigo “Qual a relação da KeyStore, PackageName e seu APP?”, sabemos que o APK resultante neste processo será assinado com uma KeyStore aleatória do Delphi, o que é NÃO recomendado, mas aqui entra a beleza da solução proposta…

Agora vá nos comentários e encontre a solução que atenda seu ambiente de trabalho.

# Referências:

[1] “Qual a relação da KeyStore, PackageName e seu APP?” https://nostrudel.ninja/#/n/nevent1qvzqqqqqqypzpdvpeyfrlddvrymt056g2jmtvc6cgntlrsumk3zcwevcl47lsfc0qyt8wumn8ghj7mn0wd68ytnyv96xztngv96hxtcpr3mhxue69uhhxarjvee8jtnwdaehgu3wd35kw6r5d9hxwtcqyzaq6e4lgapz6fc5n28vhepekrhtheguwe2lsxu39chyl3mey895sfhmc8l

[2] Everything https://www.voidtools.com/downloads/

#Delphi #Embarcadero #RadStudio #Android #APP #Mobile #Dev #Development #KeyStore #Sign #Signature #ApplicationStore

[build-tools]

Algumas versões do Delphi não baixam o “build-tools” do Android SDK de forma automática, nos forçando a baixar manualmente.

Irei explicar como fazer o download utilizando o arquivo ‘sdkmanager.bat’ da pasta ‘command-lines’ disponível no Delphi 11+.

Para este tutorial, é recomendado assistir ao vídeo do Landerson Gomes sobre como utilizar os comandos do terminal no Delphi [1].

Após assistir ao vídeo do Landerson Gomes, você deve estar familiarizado com os comandos de terminal do SDK Manager, então vamos lá (perceba que todos os comandos possuem DOIS sinais de menos -- no início e é ‘separado’ com um underline _ ):

- o primeiro passo será vc rodar o comando --list_installed, este comando deve retornar todos os recursos do SDK que está instalado no seu ambiente;

- Aqui vamos nos atentar ao “platform-tools”, este recurso é obrigatório para funcionamento do Android, então teoricamente ele deve aparecer no resultado da listagem do comando --list_installed;

- Atente-se à versão do “platform-tools”, precisamos manter a compatibilidade e baixar a versão do “build-tools” mais próxima. No nosso caso de exemplo, é a versão 35.0.2;

- O próximo comando a ser rodado será o --list, este comando irá listar TODOS os recursos do Android SDK, encontre a lista dos “build-tools” disponíveis e copie o nome e a versão assim como é listado

- O próximo comando é a instalação, rode --install build-tools;, substituindo version pela versão que você escolheu, no nosso exemplo, o comando seria: --install build-tools;35.0.0

A versão 35.0.0 é a mais próxima da versão do platform-tools do nosso exemplo.

Após a correta instalação do build-tools, agora você deve ser capaz de encontrar o arquivo “apksigner.bat” e está pronto para prosseguir para o tópico anterior [apksigner.bat]

[1] “Android SDK Manager: Configuração por linha de comando” https://www.youtube.com/watch?v=3jWe6G69VzM

# Vamos falar sobre assinatura de um APK?

Neste artigo gostaria de falar sobre como podemos assinar um APK ‘manualmente’, mas por que alguém iria querer fazer isso sendo que o Delphi já assina automaticamente o APK/AAB?

Antes de responder, gostaria de recomendar a leitura de outro artigo que escrevi “Qual a relação da KeyStore, PackageName e seu APP?” [1], não continue a leitura se você ainda não leu/entendeu este artigo! Atente-se também aos comentários no mesmo artigo, visto que são importantes para melhor entendimento do problema dos dois assuntos.

Respondendo à pergunta:

Muitos são os casos que precisamos distribuir nossos APKs fora da loja, e baseado no artigo sobre a KeyStore sabemos que precisamos compilar nosso APK em RELEASE+Application Store, só que em 64bits o Delphi (10.4+) gera um AAB e não um APK.

Neste artigo irei demonstrar uma das várias técnicas possíveis de ter seu APK Release 64bits para ser distribuído para seus clientes.

Fiz testes apenas nas versões do Delphi 10.4.2 e 12.2, então talvez para sua versão possa ser diferente, sinta-se à vontade para fazer uso do Google caso encontre algum problema. Ele costuma ajudar bastante.

Devido a diferenças entre as duas versões do Delphi, estarei escrevendo nos comentários a solução proposta para assinatura do APK Release 64bits.

Por favor, leia a parte de [Pré-requisitos] e depois encontre o comentário que atende à sua realidade. Talvez sua versão do Delphi seja diferente, mas seu SDK possui os arquivos corretos para o ‘serviço’, o que também resolverá o problema.

Também recomendo o uso do software “Everything” [2], que facilitará muito encontrar arquivos no seu PC.

[Pré-requisitos] comuns entre todas versões do Delphi:

Para começar, vamos primeiro gerar o APK em 64bits, seguindo na contramão do artigo “Qual a relação da KeyStore, PackageName e seu APP?”

Pq? Para não gerarmos automaticamente o AAB, visto que não precisamos de um AAB, mas sim um APK.

Por favor, configure e compile seu projeto na seguinte configuração:

Target: Android 64 bits

Build: RELEASE

Configuration: Development

Baseado no artigo “Qual a relação da KeyStore, PackageName e seu APP?”, sabemos que o APK resultante neste processo será assinado com uma KeyStore aleatória do Delphi, o que é NÃO recomendado, mas aqui entra a beleza da solução proposta…

Agora vá nos comentários e encontre a solução que atenda seu ambiente de trabalho.

# Referências:

[1] “Qual a relação da KeyStore, PackageName e seu APP?” https://nostrudel.ninja/#/n/nevent1qvzqqqqqqypzpdvpeyfrlddvrymt056g2jmtvc6cgntlrsumk3zcwevcl47lsfc0qyt8wumn8ghj7mn0wd68ytnyv96xztngv96hxtcpr3mhxue69uhhxarjvee8jtnwdaehgu3wd35kw6r5d9hxwtcqyzaq6e4lgapz6fc5n28vhepekrhtheguwe2lsxu39chyl3mey895sfhmc8l

[2] Everything https://www.voidtools.com/downloads/

#Delphi #Embarcadero #RadStudio #Android #APP #Mobile #Dev #Development #KeyStore #Sign #Signature #ApplicationStore

"Desenvolvimento de jogos: um guia para começar" de Luma Wanderley de Oliveira

De fácil leitura, o livro introduz a base teórica mínima para quem está começando no mundo de desenvolvimento de jogos, rico em exemplos reais e do dia a dia, faz com que a 'absorção' do conteúdo seja fácil e direta.

Adicionalmente é interessante ver como uma infância com 'incentivos' direcionam o indivíduo para o que ele poderá ser no futuro.

Postarei os links para adquirir/baixar assim que forem disponibilizados.

# Qual a relação da KeyStore, PackageName e seu APP?

* Tentarei ser o mais didático possível, sem entrar em detalhes técnicos, com o objetivo de explicar um assunto muito complexo e de forma fácil para ser entendida, com isso estarei abstraindo detalhes técnicos que podem ser facilmente encontrados na documentação oficial do Android (use o Google para te auxiliar)

* Deixarei alguns links no final do artigo, caso tenha interesse.

* Se você não entender algumas palavras ou conceitos que forem citados, sugiro fortemente usar o Google para melhorar seus conhecimentos.

* Leia meus comentários que começam com [INFO EXTRA], para dicas e informações extras.

O Android identifica seu APP baseado no conjunto da KeyStore e do PackageName.

**PackageName**, tradução literal Nome do Pacote, é o nome do pacote do seu APP, aquele que segue o padrão **com.SeuSite.NomeApp**.

A KeyStore é uma hash utilizada para assinar seu APP. Ao assinar seu APP o JAVA vai utilizar os metadados do seu APP (PackageName incluso) e o resultado dessa assinatura será uma Hash específica.

Com estes dois dados, PackageName e KeyStore (assinatura), o Android consegue saber se seu APP é seu APP. Isso quer dizer que:

O mesmo APP feito em linguagens diferentes (Delphi e Flutter, por exemplo) mas que foram compilados usando a mesma KeyStore e PackageName serão considerados exatamente o mesmo APP para o SO Android.

Um exemplo contrário disso é: você pegar EXATAMENTE o mesmo projeto que você compilou há 5 minutos, mudar uma única letra do PackageName dele (mantendo a mesma KeyStore), o SO Android vai considerar este um APP completamente diferente, visto que agora a assinatura mudou (resultado da alteração do PackageName).

Mas o que aconteceria se Mantermos o PackageName igual MAS mudar a KeyStore? Sendo a KeyStore apenas uma hash utilizada para assinar seu APP, quando você for instalar o APP neste novo contexto o SO vai primeiro ver se existe um APP com mesmo PackageName instalado, se sim, vai verificar a assinatura do mesmo. Neste nosso caso nós mudamos a KeyStore, então a assinatura nova é completamente diferente da antiga, resultando em erro na instalação, visto que você já possui um APP instalado com mesmo PackageName mas assinado com uma KeyStore diferente.

Este é um processo utilizado pela Google para assegurar que ninguém além de você vai conseguir sobrepor seu APP no celular do usuário e fazer coisas maliciosas.

Agora vamos começar a parte difícil. Se você chegou até aqui e não entendeu nada, sugiro não continuar lendo. Vá usar o Google e/ou ChatGPT até entender o que foi escrito até agora.

# Mas por que tudo isso é importante?

Isso é importante PRINCIPALMENTE como nós, desenvolvedores, distribuímos os APPs para nossos clientes e adicionalmente como o Delphi ‘assina’ nossos APPs.

## Vamos primeiro entender o Delphi:

O Delphi possui dentro de “Target Platforms-Android(32/64)-Configuration” duas opções: **Application Store** e **Development** (você pode verificar essa configuração como na foto à baixo OU em “Project-Options-Deployment-Provisioning”)

Sempre que você compilar seu APP utilizando o tipo **Development** o Delphi vai usar uma KeyStore aleatória (normalmente chamada de **debug.keystore**) para assinar seu pacote.

Pontos importantes:

- Esse arquivo **debug.keystore** é criado do zero SEMPRE que você instala o Delphi, isso quer dizer que, dois Delphis instalados no seu PC terão cada um uma **debug.keystore**.

- Você possui o Delphi XYZ instalado e compila seu APP direto no seu celular, se você instalar uma atualização, Delphi XYZ.1 por exemplo, ele gerará um novo **debug.keystore**, na próxima vez que você tentar compilar seu APP no mesmo aparelho, você verá um erro.

- Se por acaso você instalar exatamente a mesma versão do seu Delphi em outro PC (ou até mesmo re-instalar no seu PC), ele irá criar um novo **debug.keystore**.

(todos os casos citados vão gerar o mesmo problema descrito no começo deste artigo: KeyStore diferentes geram assinaturas diferentes)

## O que acontece quando tentamos compilar na configuração **Application Store**?

Com esta configuração o Delphi espera que você, desenvolvedor, tenha especificado corretamente sua própria KeyStore em “Project-Options-Deployment-Provisioning” (atente-se ao **Target**, precisa estar selecionado algum Android).

O Delphi vai pegar seu arquivo KeyStore e assinar seu APP na hora da compilação.

Usando os conhecimentos anteriores deste artigo, podemos imaginar que neste contexto, se você manter seu PackageName sempre igual e o Delphi usando sempre exatamente o mesmo arquivo KeyStore que você criou anteriormente, o Android vai sempre considerar seu APP exatamente o mesmo APP, não importando a versão do Delphi, ou até mesmo se você usar outra ferramenta para compilar seu APP (Flutter, por exemplo).

Isso acontece porque você está mantendo sempre a mesma KeyStore (hash) e PackageName para assinar seu APP.

## Mas como tudo isso influencia na forma como nós, desenvolvedores, distribuímos nossos APPs?

Vou dar um exemplo prático em vez de algo teórico:

O Dev fez um APP super legal, mas infelizmente não tem dinheiro OU não quer passar por toda a burocracia necessária de distribuição pela loja. Ele manda seu APK para um amigo, que gosta muito da sua solução, então manda para outro amigo, para outro, então para outro, outro e etc. No fim do ano, O Dev já tem quase mil pessoas utilizando seu APP, ele colocou Ads (propaganda), botão de doação e outras milhares de coisas que já estão rendendo para ele uma boa grana.

Acabou de sair o Android novo XYZsuper, seus usuários não esperam e já atualizaram seus aparelhos e infelizmente o APP não é mais compatível com esta nova versão. O Dev então atualiza seu Delphi para nova versão e gera um novo APK, compatível com essa nova versão do Android, e distribui para o auto-atualizador! Mas seu APP não consegue mais se auto-atualizar, aparece um erro de incompatibilidade ou “APP não foi instalado”.

Depois de dias na luta, estudando Delphi, lendo a documentação do Android… O Dev encontra este artigo aqui no NOSTR e compreende onde errou:

Ele compilou o APK dele em modo DEBUG. Agora com o novo Delphi o APK foi assinado com uma nova KeyStore, nem copiando o arquivo antigo **debug.keystore** para o novo Delphi resolveu o problema.

A única solução viável para O Dev é:

Criar uma KeyStore própria (salvar a sete-chaves onde não irá se perder), manter o mesmo PackageName e passar a distribuir o APP compilado em modo **Application Store**.

Mas todos usuários terão que remover o APP atual e instalar novamente, infelizmente talvez alguns usuários não estarão dispostos a este trabalho todo.

Depois de ter aplicado a correção e os usuários interessados terem realizado o processo de ‘atualização’ manual, o processo de Self Update do APP deverá funcionar normalmente, enquanto O Dev usar o mesmo arquivo de KeyStore e PackageName.

[1] Alguns detalhes mais técnicos sobre como a assinatura do seu APP funciona: https://developer.android.com/studio/publish/app-signing

[2] Artigo original publicado no Discord do “Adriano Santos Community”: https://discord.com/channels/824480379616493589/831906746318454824/942523981536321586

#Delphi #Embarcadero #RadStudio #Android #APP #Mobile #Dev #Development #KeyStore #PackageName #Provisioning #ApplicationStore