• Home
  • Features
  • Pricing
  • Docs
  • Announcements
  • Sign In

bleedingdeacons / monitor / 33527915083
93%

Build:
DEFAULT BRANCH: main
Ran 01 Sep 2026 03:48PM UTC
Jobs 1
Files 16
Run time 1min
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst

01 Sep 2026 03:47PM UTC coverage: 92.422%. Remained the same
33527915083

push

github

web-flow
perf(android): build one ABI on Debug, halving the edit-install loop (#41)

A one-line change took 2m06 to reach a handset. The Android SDK defaults
RuntimeIdentifiers to 'android-arm64;android-x64' and pays every
packaging step - assembly embedding, dexing, native libs, signing - once
per ABI. Release already narrowed to arm64; Debug did not, so half of
every debug build went on an ABI only an emulator loads.

Measured on the same real one-line edit, with EmbedAssembliesIntoApk
which a hand-installed APK requires:

  both ABIs   2m06
  arm64 only  1m07

The APK also drops from 95MB to 53MB, so `adb install -r` is quicker too.

$(HandDebugAbi) is the way back for emulator work:
-p:HandDebugAbi="android-arm64;android-x64" restores the old behaviour.
Release is untouched.

Set in the csproj rather than passed on the command line, and that
distinction is the whole point. -p:RuntimeIdentifiers=... is a global
property, so it propagates into the plain net10.0 projects this one
references and they start hunting for their output under an
android-arm64 RID folder that does not exist:

  error MSB3030: Could not copy "obj\Debug\net10.0\android-arm64\
  TheBleedingDeacons.Intergroup.Hand.Core.dll" because it was not found

The same trap -f falls into, for the same reason. Inside a PropertyGroup
conditioned on this project's own TargetFramework it stays this
project's business.

Two things measured and deliberately NOT changed. Analyzers are not the
bottleneck - 1m05 with RunAnalyzers=false against 1m07 with them, which
is noise, so the gate stays. And switching HandAndroidOnly to a singular
TargetFramework to unlock -t:Run and Fast Deployment - which would skip
assembly embedding entirely - breaks Android resource linking with a
wall of APT2260 errors. That one is worth revisiting, but not like this.

1305 of 1412 relevant lines covered (92.42%)

1338.16 hits per line

Jobs
ID Job ID Ran Files Coverage
1 33527915083.1 01 Sep 2026 03:48PM UTC 16
92.42
GitHub Action Run
Source Files on build 33527915083
  • Tree
  • List 16
  • Changed 0
  • Source Changed 0
  • Coverage Changed 0
Coverage ∆ File Lines Relevant Covered Missed Hits/Line
  • Back to Repo
  • Github Actions Build #33527915083
  • 2b1939be on github
  • Prev Build on main (#33421976365)
  • Next Build on main (#33535890171)
  • Delete
STATUS · Troubleshooting · Open an Issue · Sales · Support · CAREERS · ENTERPRISE · START FREE TRIAL · SCHEDULE DEMO
ANNOUNCEMENTS · TWITTER · TOS & SLA · Supported CI Services · What's a CI service? · Automated Testing

© 2026 Coveralls, Inc