fix(controller): show real device arch on the dashboard#8
Merged
Conversation
The dashboard "device architecture" field reported the app's own ABI (derived from nativeLibraryDir), so a 32-bit build running on a 64-bit device wrongly displayed 32-bit. We intentionally install the 32-bit app on 64-bit hardware to test the 32-bit path, so the device panel must report the hardware truth, not the app's ABI. Add a small layered "deviceinfo" slice (refactor-by-feature): - domain: DeviceAbiProvider port + GetDeviceArchUseCase (prefer the device's primary 64-bit ABI, else 32-bit, else generic). Pure JVM, unit-tested incl. the 32-bit-app-on-64-bit-device case. - data: BuildDeviceAbiProvider reads device-level Build.SUPPORTED_*_ABIS (populated from device properties, so correct even in a 32-bit process). - DashboardFragment uses the use case for the device panel; getTermuxArch() (app/content ABI) is unchanged for modules, termux and debian arch. Docs: CLAUDE.md design map + controller/docs/TECH_DEBT_PLAN.md progress log.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
The dashboard "device architecture" field reported the app's own ABI (derived from
nativeLibraryDir), so a 32-bit build running on a 64-bit device wrongly displayed 32-bit. We intentionally install the 32-bit app on 64-bit hardware to test the 32-bit path, so the device panel must report the hardware truth, not the app's ABI.Fix
Adds a small layered
org.iiab.controller.deviceinfoslice (refactor-by-feature):domain/—DeviceAbiProvider(port) +GetDeviceArchUseCase(rule: prefer the device's primary 64-bit ABI, else 32-bit, else generic). Pure JVM.data/—BuildDeviceAbiProviderreads device-levelBuild.SUPPORTED_*_ABIS, which are populated from device system properties and so report the real hardware arch even inside a 32-bit process.DashboardFragmentuses the use case for the device panel only.getTermuxArch()(app/content ABI) is unchanged for modules, termux and debian arch — those should follow the app.Testing
GetDeviceArchUseCaseTest(pure JVM) covers the key case: 32-bit app on a 64-bit device →arm64-v8a, plus 32-bit-only device, generic fallback, and unknown../gradlew :app:assembleDebug— compiles.arm64-v8a(was 32-bit); termux/debian/module arch still reflect the app's ABI.Notes
Follows
CLAUDE.md: domain pure JVM, data reads Android, wired by hand. Design map +TECH_DEBT_PLAN.mdupdated.