# Device Report — Galaxy Tab 3 7.0 LTE A 2013 Samsung tablet that had been sitting in a drawer: Android 4.4.2, a 32-bit Qualcomm chip and 1.35 GB of memory. It was brought in as an **implant** — nothing removed, nothing disabled, no account touched — and the attempt to scoop it out afterwards failed on a permission this build does not give the shell user, so every number here is the device as its owner left it. The short verdict: **it is a node at most, it will never host a mind, and the firmware is the only thing standing between it and software from this decade.** ## Identity | | | |---|---| | Model | Samsung Galaxy Tab 3 7.0 LTE (`SM-T217S`, `lt02ltespr`), Sprint, 2013 | | SoC | Qualcomm MSM8930AB Snapdragon 400, dual Krait 300 at 1.728 GHz | | CPU | 2 cores, 384 MHz–1.728 GHz, `ondemand`; `NEON` and `VFPv4` present | | GPU | Adreno 305, no Vulkan | | Memory | 1,379,944 kB usable (1.35 GB), no swap and no zram | | Storage | `/data` 12.3 GB with 11.7 GB free; `/system` 1.7 GB with 7.4 MB free | | OS | Android 4.4.2 (API 19), build `KOT49H.T217SVPSBQA1`, bootloader `T217SVPSBQA1` | | Security patch | None reported. The last stock build is dated 2017-01-04 and predates the monthly bulletin | | Screen | 1024 × 600 at 160 dpi | | ABI | `armeabi-v7a` — 32-bit only | Two entries in that table are traps rather than facts. `/proc/cpuinfo` reports CPU implementer `0x51` with part `0x04d`, and `0x04d` looks exactly like ARM's code for a Cortex-A7. It is not one: implementer `0x51` is Qualcomm using its own part numbers, and the part is a Krait 300 — out of order, and appreciably faster per clock than a Cortex-A7. Match vendor part numbers against the vendor. The same file has `ro.board.platform` reporting `msm8960` on a device whose SoC is an MSM8930, which is the older name for the family rather than a different chip. The display is the other one. `wm size` reports 600 × 1024 while `dumpsys display` reports `app 1024 x 600, rotation 3`. Both are true of different things, and `input` takes coordinates in the second, which is why the first attempts to dismiss the lock screen went nowhere. ## What was done to it **Nothing.** It arrived with zero accounts, zero device admins and zero of its 249 packages disabled, and it stayed that way. The only writes made to it were the adb authorization and `adb tcpip 5555`. **Scooping was then attempted, and failed on a permission.** `pm disable-user --user 0 <package>` is refused: ``` java.lang.SecurityException: Permission Denial: attempt to change component state from pid=10201, uid=2000, package uid=10099 at android.content.pm.IPackageManager$Stub$Proxy.setApplicationEnabledSetting at com.android.commands.pm.Pm.runSetEnabledSetting(Pm.java:1247) ``` `uid=2000` is the shell user adb runs as, and it does not hold `CHANGE_COMPONENT_ENABLED_STATE` here. A second attempt against a different package (`package uid=10032`) was refused identically, so this is the build rather than one awkward package. Each refusal throws an uncaught exception inside `pm`, AndroidRuntime reports it as a fatal crash of a system process, and the device answers by collecting a **92-second dumpstate** — heavy enough on a machine this size that the low-memory killer took the shell out mid-loop. Sixty packages pushed through that would have thrashed the tablet and changed nothing. There is no way around it from here. `ro.debuggable`, `ro.secure`, `ro.build.type` and `ro.build.tags` read `0`, `1`, `user` and `release-keys`; `adb root` answers `adbd cannot run as root in production builds` and drops the connection as it goes; and there is no `su` in `/system/bin` or `/system/xbin`. What that leaves is the flash. Disabling by hand in Settings → Apps would still work, because Settings runs as the system uid and holds the permission the shell lacks, but sixty packages one tap at a time is a worse use of an afternoon than one Download Mode session — and it leaves the device on KitKat, which is the larger problem. ## Memory, at each stage | Stage | Available RAM | Free storage | User apps | Accounts | |---|---|---|---|---| | As found, system running | ~500 MB of 1.35 GB | 11.8 GB | 0 | 0 | | Scoop attempted | unchanged — the pass did not run | — | — | — | The first row is the one that matters, because it is what a preflight would have refused on. Total RAM reads 1,379,944 kB, and the system holds **578,877 kB** of it: 506,753 of used PSS, 54,844 of slab, 15,220 of buffers. What is left to hand out is `MemFree` plus `Cached` — 24 MB free and 475 MB cached at the first reading, 184 MB free and 338 MB cached after half an hour of idling. Call it **500 MB**, moving by a hundred either way with how long the tablet has been left alone. There is no swap and no zram, so there is no second chance under pressure. `dumpsys meminfo` also reports `Committed_AS` of 37 GB against a `CommitLimit` of 690 MB, which is Android's overcommit behaving as designed and not a figure to plan with. A hollowed device would have freed the Google and Samsung suites; this one was never hollowed. Seventeen Google processes and forty-seven Samsung or Sprint processes were running, out of 265 in total. Their `ps` RSS sums to 615 MB and 1,454 MB respectively, which is nonsense on a 1.35 GB device — nearly all of it is framework pages mapped into every process — so the honest figure for what a scoop would have returned is a guess in the low hundreds of megabytes, not a measurement. ## Load test **Not run, and the reason is a dead end rather than a delay.** Every llama.cpp Android build in circulation is `arm64`; this device is `armeabi-v7a`, and there is no NDK installed on the host, so building one from source is a project in its own right. The arithmetic argues against it too: a 0.5B Q4 is around 350–400 MB before a KV cache, against 500 MB with no swap and a low-memory killer that has already been shown, on another device, to reap a bare server without a word. No thread sweep, no prompt-processing figures, no tier-up test. Recorded as a dead end. ## Context Not measured, because nothing was loaded to measure it. The 32 KB per token the other devices pay would be the same figure here; what is missing is any evidence that this device can hold a model at all. ## Thermals Sampled idle only. `tsens_tz_sensor0` read 33 °C with the tablet lying on a table, and the battery read 26.0 °C at 100% and 4,178 mV. Only two of the eleven thermal zones report anything: `pm8921_tz` returns a raw 29682 on a scale that does not map to a temperature, and the rest are empty. There is no `dumpsys thermalservice` before Android 6, so there is no HAL block to sample the way the Pixel's report does. Under load: unmeasured. Anything said about sustained temperature on this device would be invented. ## Link and reachability The cable is the weak point. The tablet enumerated on Windows as `SAMSUNG_ANDROID` and reached adb as a device, then vanished between two calls a second apart, and dropped again later in the session. `adb tcpip 5555` over Wi-Fi then held without a stumble for the rest of the work. | | | |---|---| | Wi-Fi | the house network, 5 GHz, RSSI −40 dBm, 150 Mbps negotiated | | Inbound transfer | 0.8 MB/s as adb reports it, **1.8 MB/s on the wire** | | Wire against file | 17,545,404 bytes carried for a 16,777,216-byte file | The wire figure is the one to trust, and it is also the explanation: the radio carried almost exactly the file with a little overhead, so nothing was being retransmitted and the slow number is Android 4.4's `adbd` waiting on small synchronous writes rather than a bad link. Fine for telemetry, painful for a model. Reachability after a reboot is the real constraint. `persist.adb.tcp.port` will not take — `setprop` reported success and the value read back empty — so `adb tcpip 5555` is lost on every reboot, and the only port that could restore it is the worn micro-USB. Whatever role this device takes, it should be one where the device dials out rather than waiting to be dialled. The shell is from 2010 as well. There is no `cmd`, and `head`, `tail`, `wc`, `awk`, `printf` and `which` are all missing; `pm`, `am`, `settings` and `svc` are the tools that exist. ## Verdict | Role | Verdict | |---|---| | Mind host, any tier | No, for three independent reasons: 1.35 GB with ~500 MB usable sits below the 4 GB floor; the ABI is 32-bit and the app requires `arm64`; and its `minSdk` is 31 against a device that will run Android 7.1 at best | | Node, hosting a small ship | The hardware would take it — ~500 MB is ample for a rule-only ship, whose whole machinery is a supervision tree, a watch bill and a log — but the platform is closed to it by the decision of 2026-11-07 that a phone is not a node, on the grounds that OTP on Android is experimental, fights the sandbox and has no reliable background execution. This report does not reopen that decision | | Consort | Unmeasured. It would need a harness of the right vintage running on Android 7.1 ARMv7, and nothing has been tried | | A bench for the firmware question | Yes, and this is the honest role. It is the cheapest way to find out whether an obsolete device's ceiling is set by its silicon or by its firmware | The second row is the interesting one. The Galaxy gives a device three ways to be useful — a node in the Erlang cluster, a mind in the pool, or a consort outside the chain — and this tablet is closed to all three as written. That is not a reason to throw the device out. It is a reason to write down that no clean, rooted, 32-bit Android device currently has a berth, and to find out from research item 28 whether one is worth making. ## What this changes in the project - **Research item 27** moves to partly answered: the ceiling is measurable, and the reason to flash is not an upgrade but the absence of any other way to remove anything. - **Research item 28** exists because of this device — whether Android is the right base at all, given that the platform can carry a Linux userland on top. - **The device floor table** in [[Low Passage Mind Host]] gains a note beneath it, because its lowest row is 4 GB and this device cannot run the app at all. - **The network inventory** records its address and MAC. - **A tension in [[Low Passage]] was resolved on 2026-11-11**, and this device is what forced it. The enrollment section said a hollowed device "is a node and nothing else" while the Android section said a phone is never a node. The layers now keep the words apart: a hollowed device belongs to the Galaxy, and whether what it runs is a node is a separate question with its own answer. ## Caveats - Every number is the device as found. Nothing was stripped, so nothing here says what a hollowed Android 7.1 tablet would do. - No model was loaded. The load test is a documented dead end, not a pending result. - The tablet has been running on battery since the cable came out, with nothing charging it. - The port is worn and may fail outright; the cable may also be the fault. A new cable is on order to tell the two apart. - The unofficial LineageOS 15.1 build for this model was not evaluated. It is one Android version newer and one maintainer less dependable. ## Reference - [[Low Passage]] — the specification; the tender class is what produced this report. - [[Low Passage Research]] — the evidence behind the design, items 27 and 28. - [[Low Passage Mind Host]] — the app spec, and the floor this device sits under. - [[Proposal — Galaxy Tab 3 7.0 LTE reflash]] — what to do about it. - The network inventory — the device's address and MAC.