GameCore 1.1.1

GameCore 1.1.1 — a per-game display size, a control panel you can resize, and the
source tree finally caught up with what the releases ship.

Download

GameCore.apk — Android 8.0 (API 26) or newer, arm64-v8a and armeabi-v7a.

size    12,244,957 bytes (11.7 MB)
sha256  08e5ee95371ae884658d1c7ad281fe127aa1a1a4165c1a2d5e87fed686b00bd2

The release variant: R8 with obfuscation and resource shrinking, signed with the project's
own release key (CN=GameCore, RSA 2048) under the v2 APK signature scheme. Certificate
SHA-256:

8eef17e0163198517f765b91a29aa9414710a852281b5e6fdd6362442586d42b

Same key as 1.0 and 1.1, so this installs straight over either — versionCode 2 → 3. With
minSdk 26 the build omits the legacy v1 JAR signature, so the absence of META-INF/*.RSA is
expected and does not mean the APK is unsigned; apksigner verify reports it as verified
under v2.

Display size, per game

A display-resolution override that a profile can hold, applied through the elevated shell that
was already there rather than a second path of its own. wm size is awkward in three specific
ways — it prints nothing on success, its effect survives a reboot, and on some builds it is
accepted for the built-in panel and then ignored — so three rules are enforced and are not
negotiable per device:

• a size is refused against the panel it is going onto before anything is written,
• the previous size is recorded before the write, not after,
• nothing is reported as applied until it has been read back.

The undo is a row in the same restore ledger every other pending change uses, replayed by the
same code, so the dashboard's count of outstanding changes stays true rather than growing a
second revert mechanism beside it.

In the overlay panel there is an Aspect Ratio tile that applies a shape on the tap, and its
first chip is always native — which makes the reset one tap that is already on screen.

And the copy says the same thing in the panel, in the profile editor and on the controller
itself: this stretches the picture into a different shape. It is not a wider field of view.
No game sees more of the world for it.

A control panel you can resize

The expanded panel's width is yours now. There is a grip at its bottom-right corner that
previews the change while your finger is down and writes once on release, inside the same
overlay window rather than a second one. It is one global preference on the floating button's
config, not a per-profile field, clamped by the model and again by the service against the live
frame, and the action grid reflows on the width available instead of clipping.

Height still follows content, up to the room measured between the button and the screen edge,
because a user-set height would fight the above-or-below anchoring the panel already does.

Developer screen

A row at the foot of Settings: the app name, the version read from BuildConfig rather than
typed into a string, and three links handed to an implicit ACTION_VIEW through the same
safe-launch helper everything else uses. No WebView, no network call, nothing recorded on a tap.

Under it

• wm size is the fourth write-capable program in the closed elevated command set — three
  commands, every argument validated against a form before a command is built, and a rejected
  argument producing no command at all rather than a malformed one. There is still no shell
  interpreter in that set, so there is still no string to inject into.
• Room schema 3, with hand-written additive migrations.
• 169 JVM unit tests across 14 classes, and lint at zero errors.

The source tree

The 1.0 import was the last time the code itself was pushed, so this release also publishes the
colour-correction work 1.1 shipped, the three features added since, and the migrations that go
with them — 74 files, on top of the existing history rather than replacing it. 1.0 and 1.1 stay
exactly where they are.

Unchanged

The floating overlay, the performance pill, the HUD builder, the crosshair, per-game profiles,
monitoring, encrypted session tracking, colour correction — and the absences: no root, no
game-file modification, no code injection, no process memory access, no anti-cheat
interference, no fabricated statistics, no background-app killing, no thermal-limit override.

Untested on hardware

The build host is an aarch64 device with no working adb, so the instrumented suite could not
be executed and the overlay, screen recording, Shizuku, colour-write and wm size paths have
not been exercised end to end on a phone by the build itself. The JVM suite covers the
geometry, the formatters, the sanitizer, the command builder, the size verdicts and the model
invariants.