Android: build experiment and how QtPass could use GnuPG there

Open
#2,005 6 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
25/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Tech stack
android, cpp, git

Research direction

The issue reports an Android build probe on the android-probe branch and points to main.pro for the static library name fix. First inspect that project file and reproduce the Qt 6.8.3 Android build; then run the probe APK in an emulator to assess the UI. The broader GnuPG work is exploratory: the suggested first milestone is bundling gpg and decrypting one test store entry with a loopback passphrase dialog.

Written by the indexing model from the issue text.

Description

enhancement help wanted

An experiment: can QtPass run on Android, and how would it talk to GnuPG there?

Building: works

A probe on a fork (annejan/qtpass android-probe, run) builds src and main with Qt 6.8.3 for android_arm64_v8a (NDK r26b, API 35) and packages a debug APK (18.5 MB) with androiddeployqt. The only change needed:

  • Android's qmake adds the ABI to the static library's name (libqtpass_arm64-v8a.a), while main.pro links libqtpass.a. The probe copies it; a real fix belongs in main.pro.

Notes for the install step: Qt 6.7 and later list their Android packages under host all_os (not linux), and autodesktop: true brings the host tools along.

Not tried yet: running the APK. The Widgets UI is the desktop one, so on a phone it will be small and mouse-shaped; a usable phone UI is a separate (big) question.

GnuPG: the real problem

QtPass runs gpg, git and pass as processes through Executor. On Android:

  • An app cannot run binaries from its own writable storage (since Android 10). Binaries shipped as lib*.so in the APK's native library directory can still be run (extractNativeLibs), which is how Termux works.
  • pass is a Bash script, so Android would use the ImitatePass mode (gpg and git directly) anyway.
  • There is no pinentry: gpg-agent has nothing to ask the passphrase with. QtPass would need its own passphrase prompt and --pinentry-mode loopback.
  • Smartcards and YubiKeys over USB or NFC would not reach a bundled scdaemon.
  • The store would live in the app's own storage (cloned with Git); gpg cannot read Android content:// URIs.

Options:

  1. Bundle GnuPG built for Android (Termux packages gnupg 2.5.24 and its libraries), plus git, as executable "libraries" in the APK. Keeps QtPass's process model and real GnuPG keyrings. Needs: the loopback passphrase prompt, GNUPGHOME in app storage, packaging a dozen libraries. Fastest way to something that decrypts.
  2. OpenKeychain through its OpenPGP API (what Android Password Store first used). It has had no commits since May 2024, so not something to build on.
  3. An in-process OpenPGP library as a third backend next to RealPass and ImitatePass, for example RNP (C++, used by Thunderbird, reads GnuPG keyrings). No processes, no agent, no pinentry problem, and it would also fit iOS. The most work: key listing, generation, import and signing all move to the library.

Suggested next steps, if this goes anywhere: run the probe APK in an emulator to see the UI, then try option 1 with only gpg and a loopback passphrase dialog to decrypt one entry from a test store.

Not planned for 2.0; this is exploration.

Dominant language
C++
Stars
1.1k
Forks
172
Avg merge
4h 26m
Merged PRs (30d)
122

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from IJHack/QtPass

All issues in IJHack/QtPass

Similar issues

More C++ issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.