mirror of
https://github.com/pezkuwichain/pezkuwi-wallet-android.git
synced 2026-11-11 13:17:15 +00:00
00bd5c043dae49bb33ec44e8c6a1eae3d85ca664
12
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 SatoshiQaziMuhammed
|
35c71062f0 |
Strip native libraries; XCM by genesis; CodeQL for Kotlin; bridge credits in history (#31)
* Strip native libraries in the app and keep light client line tables
The app module named no NDK, so AGP expected its default 27.0 against the 26.1 that CI installs,
could not strip any native library and made no native-debug-symbols.zip for Play. Pin 26.1 in the
app. The light client now keeps line tables for that symbol file; the packaged library is still
stripped to 8.6 MB.
Also adds an XCM encoding test for PezkuwiChain networks. This commit points WESTEND at Zagros
to check that the test fails against that change.
* Fix the encoding test's read of the interior field
* Encode PezkuwiChain networks by genesis in XCM
WESTEND held a stale genesis labelled Zagros. The runtimes declare ThisNetwork as ByGenesis and
the XCM v5 NetworkId has no Westend or Zagros variant, so the named mapping is removed and every
PezkuwiChain network is encoded as ByGenesis.
* Run CodeQL for every language on hosted runners, Kotlin with a build
Default setup analyses Java without a build and leaves out every Kotlin file, and the Java job on the
self-hosted runner stopped at the NDK install because sudo asks for a password, so Kotlin had not been
analysed since February. One matrix job covers actions, JavaScript/TypeScript, Rust and Java/Kotlin.
* Use CodeQL Action v4, v3 is deprecated in December 2026
* Build for CodeQL without Gradle and Kotlin daemons so the analysis has the memory
* Show incoming USDT bridge credits in history without a refresh
The realtime transfer extractor for assets pallets knew only transfer and transfer_keep_alive. The
bridge credits with transfer_approved, spending the multisig's allowance, so a credit appeared only
after the indexer caught up and the user refreshed. transfer_approved is now a transfer from owner to
destination; the signing delegate is not the sender.
* Stop the light client five minutes after RPC is back
A chain registered with the light client kept syncing for as long as the process lived. Measured on
the emulator over 5-minute windows, that was about 14 MB of data an hour and 2% of a core while the
wallet read nothing from it.
Once RPC has stayed connected for five minutes after a fallback, the connection releases the light
client: LightClients unregisters the chain, a relay chain only after its teyrchains. The engine gains
remove_chain. Its database saver now checks, under the registry lock, that the chain is still
registered: smoldot panics on a request to a removed chain. The next fallback starts cold from the
saved database.
* Refresh light client specifications from the signed config while RPC works
The light client started from the checkpoint the APK was built with, so a first fallback months after
a release warp-synced from months back, and on a phone that never fell back there is no saved database
to help. The fallback is wanted when RPC is blocked, and then the config repository may be blocked too.
On the first RPC connection of the process, each chain's specification is fetched from the config
repository through the app's HTTP client, which checks it against the signed targets and falls back to
the mirrors. It is kept when it is the same chain (id and genesis state root) with a later checkpoint;
an older file never rolls the checkpoint back. Registration uses the kept file when it is later than the
APK's own.
* Close the light client's peer connections once its last chain is removed
smoldot keeps its peer-to-peer network service, with the connections in it, for as long as the client
lives, so removing every chain left them open: on the emulator, four libp2p connections were still up
eleven minutes after the release, and data use stayed above the RPC-only level. The engine now
replaces the client once no chain and no loopback connection is left; the connections close about 20 s
later, when the attempts under way finish.
The database saver now checks a per-registration number instead of the smoldot chain id, which smoldot
reuses after a removal: a saver of a removed chain could otherwise keep running for the next chain
that got the same id. A connection whose chain is removed between the handshake and its setup now
ends instead of panicking.
* Obfuscate the app's own classes and build the R8 variant in pull requests
-keep class io.novafoundation.nova.** { *; } with -keepnames left 2.6% of the app's 26,602 classes
renamed in the 1.3.0 Play build (15.6% of all classes). It is replaced by keeping only the field names
of the app's classes, which Gson reads by name where a class has no @SerializedName, so class and method
names are obfuscated. No persisted value or reflective lookup in the app depends on a class or method
name: class names appear only in logs and in an in-memory cache key.
@JavascriptInterface methods had no rule of their own; the blanket keep covered the DApp browser's web3
bridge, its integrity check and the Transak bridge. They are kept explicitly.
Pull requests built only the unminified develop variant, so an R8 break would first show in the Play
build. A second job builds releaseTest (the release rules, debug-signed) and uploads its APK and mapping.
* Give the releaseTest build the debug package, which the CI Firebase config knows
* Build releaseTest under the production package, the one its Firebase config has
* Stop keeping every app class under the JNI rule
-keep class io.novafoundation.nova.** { native <methods>; } keeps every class the pattern matches,
whether or not it has a native method, so the app's class names stayed unobfuscated after the blanket
keep went: 2.6% of its classes were renamed in the R8 build. The rule under it already keeps the names
of classes with native methods and of those methods, which is what JNI binds by name; the Rust
bindings look up no other app class.
* Keep TypeToken and Retrofit generic signatures under R8 full mode
The R8 build failed to map every chain from the local database: R8 full mode keeps generic signatures
only on kept classes, and the app's anonymous TypeToken subclasses had been kept by the blanket rule.
These are the rules Gson 2.11 and Retrofit 2.10 ship; the app is on Gson 2.10.1 and Retrofit 2.9.0.
* Keep constructors of the app's classes so Gson can instantiate its models
The R8 build failed to read the DApp list: R8 full mode had made DappMetadataResponse abstract because
nothing in the code instantiates it, and Gson does so reflectively. It matches none of the name
patterns the rules keep models by. Keeping constructors costs no obfuscation, since they are all named
<init>.
* Keep the type argument of web3j TypeReference subclasses under R8 full mode
* Run R8 in compatibility mode
After the app's own classes became obfuscatable, the full-mode R8 build kept breaking reflective
decoding in new places: TypeToken and TypeReference subclasses lost their type argument, a Gson model
was made abstract, and SubQueryResponse<T> lost its class signature so a proxy query decoded to a
LinkedTreeMap. Full mode keeps generic signatures only on explicitly kept classes, and this code base
has many generic models outside any name pattern. Compatibility mode keeps them everywhere under
-keepattributes Signature and does not make uninstantiated classes abstract; obfuscation is unchanged.
* Allow the java.beans classes Jackson's Java 7 support refers to, missing on Android
|
||
|
SatoshiQaziMuhammed
|
39dd67ba94 |
fix: drop the unused GIF library that blocks 16 KB page size support (#19)
Play rejects updates whose native libraries are not aligned for 16 KB memory pages, enforced since Nov 1 2025. Measuring the released bundle showed exactly one library short, and only on one ABI: arm64-v8a 7/7 aligned at 0x4000 x86_64 6/7 aligned; libpl_droidsonroids_gif.so at 0x1000 That library comes from pl.droidsonroids.gif:android-gif-drawable 1.2.19, inherited from upstream and never used here: no GifDrawable, GifImageView, GifTextView or pl.droidsonroids reference exists in any Kotlin, Java or XML file in the project. Removing it beats upgrading to 1.2.32 — an unused dependency should not be carried at any version, and this also drops roughly 175 KB of dead native code across four ABIs. Everything else in the bundle was already aligned, and jniLibs.useLegacyPackaging is already false, so nothing more is needed for the requirement. |
||
|
SatoshiQaziMuhammed
|
27aff873a6 |
feat: tell users a new version exists, and let them rate the wallet from inside it (#17)
Two gaps, both invisible until you look for them. There was no update mechanism at all. Someone on an old build stayed on it until they happened to open the Play Store on their own. For a wallet that is worse than an inconvenience: today's multisig signing fix would have reached nobody who was not already looking. InAppUpdates asks Play on every foreground. A user a few days behind gets the flexible flow — the download runs in the background and the wallet stays usable, because interrupting someone mid-transfer to force an update is its own kind of harm. Past fourteen days of staleness, or on a release marked priority 4+ in Play Console, it switches to immediate. onResume finishes an interrupted immediate update and installs a flexible one that completed while the app was backgrounded; without that the first leaves a user stuck and the second never installs. Ratings had the same shape of gap: people who would happily rate the wallet never do, because nothing ever asks. Play's in-app card asks without sending them to the store. Play answers neither "has this user rated" nor "what did they choose" — by design. It also throttles to a handful of showings a year and silently drops the rest. So the gates in AppReviewTracker are not there to avoid nagging, which Play already handles; they exist to spend those few real chances well: three successful operations, three days since first use, ninety since the last ask, and not within two days of an error. Recording sits in RealExtrinsicService, the single point every on-chain action passes through, so transfers and staking are covered without a hook per screen. The tracker swallows everything it touches — a rating counter must never be able to fail a transfer. Both features no-op outside a Play install, so neither can be verified from a Firebase build; that needs an internal testing track. Version 1.2.0. |
||
|
Satoshi Qazi Muhammed
|
4cf6cef68d |
fix: add missing scalars converter dependency for androidTest
TronBalancesIntegrationTest.kt uses ScalarsConverterFactory but nothing in app/build.gradle declared it, so the app module's androidTest compilation failed with "Unresolved reference 'scalars'" - this was never caught before now because the emulator balances_test.yml workflow only runs on a schedule/ manual dispatch, not on every push. |
||
|
SatoshiQaziMuhammed
|
7dea79dbee |
fix: use arm64-v8a emulator image on macos-14 runners (#11)
* fix: use arm64-v8a emulator image on macos-14 runners
The "Run balances tests" job has been failing on every scheduled run
for weeks: the emulator requested an x86 system image while
macos-14 GitHub-hosted runners are Apple Silicon (aarch64) - QEMU2
refuses to boot a mismatched-architecture image ("Avd's CPU
Architecture 'x86' is not supported by the QEMU2 emulator on
aarch64 host"), so every adb command against the never-booted
emulator failed with "device not found" for the full 10-minute
boot timeout on every run.
* fix(ci): run balances-test emulator on ubuntu-latest with KVM instead of macos-14
macos-14 (Apple Silicon) GitHub-hosted runners don't expose nested
virtualization to guests, so the Android emulator's HVF backend fails
with HV_UNSUPPORTED and the job times out waiting for boot - this
affects both x86 and arm64-v8a system images, so the arch: arm64-v8a
change alone wasn't sufficient. macos-13 (which previously supported
this via HAXM) was retired by GitHub.
Linux hosted runners support KVM-accelerated emulators once the kvm
device's udev permissions are relaxed, which is the documented setup
for reactivecircus/android-emulator-runner and also faster/cheaper
than macOS runners.
* fix(ci): build instrumentialTest androidTest APK to match AllureAndroidJUnitRunner
run_balances_test.sh has always targeted
io.novafoundation.nova.debug.test/io.qameta.allure.android.runners.AllureAndroidJUnitRunner,
but android_build.yml's "Build debug tests" step built the plain
debug variant's androidTest APK, whose manifest declares the module
default runner (androidx.test.runner.AndroidJUnitRunner, from
allmodules.gradle) - AllureAndroidJUnitRunner is only wired via
testInstrumentationRunner on the dedicated instrumentialTest build
type (app/build.gradle), which was apparently created for exactly
this purpose but never actually wired into CI. Result:
INSTRUMENTATION_FAILED as soon as the emulator boot issue was fixed
and this step was reached for the first time.
instrumentialTest initWith buildTypes.debug (same applicationIdSuffix
'.debug', same default debug signing), so it installs under the same
package next to the already-built debug app APK - only the
androidTest APK's build type needs to change, not the main app build.
Only balances_test.yml sets build-debug-tests: true, so this doesn't
affect any other android_build.yml caller (pull_request.yml has it
explicitly disabled with its own separate pre-existing TODO).
* test: temporarily point android_build.yml ref at this branch for verification
TEMPORARY - reusable workflow calls (uses: ...@ref) pin to that ref's
copy regardless of the caller's branch, so android_build.yml's fix
never actually ran in the previous verification attempts even though
it was committed to this branch. Must revert to @main before merging
this PR, once android_build.yml's changes are on main.
* fix(ci): declare AllureAndroidJUnitRunner on debug build type, not instrumentialTest
AGP only ever compiles one androidTest APK per module, tied to
android.testBuildType (default "debug", never overridden in this
project) - so a testInstrumentationRunner override on any other build
type, including instrumentialTest, is unreachable regardless of which
gradle task or main-app variant is used. That's why the previous
attempt (assembleInstrumentialTestAndroidTest) failed outright: no
such task exists, since androidTest is only ever generated for
testBuildType.
Reverts the previous commit's task/path changes back to
assembleDebugAndroidTest / app/androidTest/debug/..., and instead
moves the testInstrumentationRunner override onto the debug build
type itself, which is what androidTest actually compiles against and
what run_balances_test.sh has always targeted. Also drops the dead
override from instrumentialTest now that it's confirmed non-functional
there.
* debug(ci): dump pm list instrumentation before running balances test
Diagnostic only - the previous fix (testInstrumentationRunner moved
to the debug build type's defaultConfig) still hit the identical
INSTRUMENTATION_FAILED for AllureAndroidJUnitRunner even though both
APKs now install successfully with the corrected paths. Need to see
what PackageManager actually registered for the installed test APK
rather than keep guessing from Gradle DSL evaluation-order theory -
allmodules.gradle's subprojects{} block also sets
testInstrumentationRunner on every module including app, and it's not
yet confirmed which assignment wins.
* fix(ci): use current io.pezkuwichain.wallet package instead of stale upstream name
Diagnostic (pm list instrumentation) confirmed the real, final root
cause: AllureAndroidJUnitRunner IS correctly registered on-device
after the previous fix, but under the app's real applicationId
(io.pezkuwichain.wallet, set in build.gradle since the Pezkuwi rebrand)
- not the pre-rebrand upstream Nova Wallet package
(io.novafoundation.nova) these scripts still hardcoded. Every previous
INSTRUMENTATION_FAILED was simply am instrument targeting a package
that was never installed.
Also fixes the identical stale reference in run_instrumental_tests.sh
(currently unused by any workflow, but has the same bug).
The BalancesIntegrationTest class's own Kotlin package
(io.novafoundation.nova.balances) is untouched - that's the test
class's real source package on disk, unrelated to the app's
applicationId, and was never part of the bug.
* fix(ci): bound run-tests to 25min and unbuffer python output
Latest verification run hung for 1h15m+ inside am instrument with
zero visible progress - had to be cancelled manually. Post-mortem:
Python's stdout is fully buffered (not line-buffered) when piped
under GitHub Actions' `run:`, so the script's own 5s heartbeat prints
(explicitly there to avoid CI's inactivity-based cancellation) never
actually reached the log until the buffer filled near the very end,
making the run look identical to a genuine hang for its entire
duration with no way to tell what BalancesIntegrationTest was doing.
- timeout-minutes: 25 on run-tests bounds any future hang to a fixed,
reasonable ceiling instead of requiring a manual cancel after an
hour+.
- python -u unbuffers stdout so the next run's logs show real-time
heartbeat/output, giving actual visibility into where a hang (or
slow chain RPC) occurs instead of a silent multi-hour gap.
Root cause of the hang itself is still open - this only makes it
diagnosable and bounds its cost.
* fix: skip WSS ChainConnection setup for Tron-based chains
Real root cause of the 1h15m+ hang in the previous verification run
(had to be cancelled manually): ChainRegistry registers all chains
sequentially (diff.newOrUpdated.forEach { registerChain(it) }), and
registerConnection() unconditionally called
connectionPool.setupConnection(chain), which creates a ChainConnection
backed by a WSS-only SocketService - for every chain, with no check
for chain type. Tron's node (https://api.trongrid.io) is a plain REST
API with no WebSocket support, so this connection attempt just hangs
forever with no timeout, and since registration is sequential and
Pezkuwi chains (including Tron) are ordered first in the merged chain
list, every chain after it in the list never finishes registering
either - including all the third-party chains BalancesIntegrationTest
actually exercises.
This isn't just a test problem: any real user with the Tron chain
enabled would hit the same registry-wide freeze during chain sync.
Tron balance/transfer operations already go through their own
TronGridApi REST client (built in the Phase 1/2 Tron work),
independent of ConnectionPool/ChainConnection - confirmed nothing else
reads chainRegistry.getConnection() for a Tron chain id - so skipping
ChainConnection setup entirely for isTronBased chains is safe.
* debug(ci): stream live logcat during test run
Diagnostic only. Previous fix (skip WSS ChainConnection for
isTronBased chains) did NOT resolve the hang - identical symptom
(silent for the full 25min timeout, just heartbeats, nothing from the
actual test process). Need real device-side visibility into what's
actually happening (network calls, coroutine timeouts, ANRs) instead
of guessing blind from am instrument's own stdout/stderr, which stays
completely silent until the process exits.
* debug(ci): SIGQUIT thread dump 3min into a hung run, bump logcat to debug level
Previous diagnostic (live logcat at info level) showed the app staying
genuinely alive (GC cycles, system chatter) but produced zero signal
from the test itself after the initial successful chains.json fetch -
no WSS/DB/coroutine activity visible, likely because relevant logging
is below info level. Static code reading (ChainConnection.setup(),
ChainSyncService.syncUp(), ChainFetcher) hasn't turned up an obvious
blocking call, and this exact hang predates this session by at least
a month (zero successes in the last 100 scheduled runs going back to
2026-06-09) - so it's a real, previously-latent bug in the app/test
itself, never previously reached because every earlier run failed at
an earlier CI-infra stage.
kill -3 on the app process forces ART to dump every thread's Java
stack trace to logcat (the standard ANR-diagnosis technique) - this
should show exactly which coroutine/thread is parked and where,
instead of continuing to guess from log filtering.
* fix(ci): bump run-tests timeout to 90min, drop now-unneeded SIGQUIT diagnostic
With the chain blacklist fixed, the previous run genuinely started
executing the 160-case parameterized test suite (visible TestRunner
started/finished events for real chains) instead of hanging silently
- first time this has happened in this entire investigation.
It still hit the 25min ceiling: each test case has an explicit
withTimeout(80.seconds), and several chains that aren't fully dead
(so not blacklisted) but are slow/unresponsive burn the full 80s
before failing. With 160 total test cases, the worst-case aggregate
easily exceeds 25 minutes even with zero actual hangs - so the
timeout needs to be realistic for the test's own design, not just
long enough to catch a true infinite hang. 90min matches
android_build.yml's existing precedent for this project's CI jobs.
The SIGQUIT-after-3-minutes diagnostic added earlier is now
counterproductive noise: any healthy run legitimately takes far
longer than 3 minutes to get through 160 cases, so it would fire on
every run rather than only genuine hangs. Removed now that its actual
purpose (finding the real hang) is done - the blacklist was the
answer, not something a thread dump would have caught anyway (dead
sockets, not deadlocked application code).
* chore: revert temporary android_build.yml ref pin back to @main
Was pointed at this branch only to verify android_build.yml's own
fixes actually took effect during iteration (reusable workflow calls
resolve against the ref they're pinned to, not the caller's branch).
android_build.yml is now byte-identical to main (the wrong task-name
attempt was fully reverted in an earlier commit), so this is a no-op
functionally - just restoring the correct long-term reference before
merge.
|
||
|
Kurdistan Tech Ministry
|
f5b38eed8c |
chore: remove Branch.io SDK and route deep links through own domain
Branch.io was inherited from Nova Wallet fork but never configured. Removed SDK integration, manifest intent filters, Gradle dependencies, Dagger DI modules, and string resources. Deep linking now routes exclusively through app.pezkuwichain.io with verified assetlinks.json. |
||
|
Kurdistan Tech Ministry
|
28d0391d72 |
fix: store native libs uncompressed with 16KB zip alignment
Set jniLibs.useLegacyPackaging = false to ensure .so files are stored uncompressed and 16KB-aligned within the AAB, as required by Google Play for Android 15+ compatibility. |
||
|
Kurdistan Tech Ministry
|
64d727dd21 |
fix: 16KB page alignment for all native libraries
- Rebuild renderscript-toolkit.aar from source with NDK 27 and 16KB alignment - Rebuild libsr25519java.so from substrate-sdk source with 16KB alignment - Realign libsqlcipher.so ELF segments to 16KB (preserves JNI API compatibility) - Add jniLibs overrides for sr25519java and sqlcipher to replace AAR versions - All native .so files now have 0x4000 (16KB) LOAD segment alignment |
||
|
Kurdistan Tech Ministry
|
c30cdf2411 | build: add native debug symbols for releaseMarket | ||
|
Kurdistan Tech Ministry
|
9c7bb7c6e9 |
Prepare for Play Store release: simplify dashboard, clean debug logs
- Simplify dashboard card: remove referral/staking/perwerde fields (not yet on-chain), keep roles + trust score + action button - Remove all debug Log.d/e/w calls added during development (PEZ_STAKE, RuntimeFactory, ExtrinsicBuilder, etc.) - Change Play Store track from beta to production - Add release notes (whatsnew-en-US) |
||
|
Kurdistan Tech Ministry
|
921e6de224 |
prepare release: staking config, proguard fixes, icons and build cleanup
- Add subquery endpoints for staking-rewards, history, staking APIs - Add identityChain, stakingWiki, pushSupport to chain config - Remove versionNameSuffix/applicationIdSuffix from releaseMarket build - Fix privacy/terms URLs to use .html extension - Strengthen proguard rules for Retrofit, SR25519, Substrate SDK, WalletConnect, Google Drive, Navigation and crypto classes - Update launcher icons for debug and release variants |
||
|
Kurdistan Tech Ministry
|
a294aa1a6b |
Initial commit: Pezkuwi Wallet Android
Security hardened release: - Code obfuscation enabled (minifyEnabled=true, shrinkResources=true) - Sensitive files excluded (google-services.json, keystores) - Branch.io key moved to BuildConfig placeholder - Updated dependencies: OkHttp 4.12.0, Gson 2.10.1, BouncyCastle 1.77 - Comprehensive ProGuard rules for crypto wallet - Navigation 2.7.7, Lifecycle 2.7.0, ConstraintLayout 2.1.4 |