GameCore 1.1

GameCore 1.1 — colour correction, applied to the display rather than drawn over it.

Download

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

size    12,192,769 bytes (11.6 MB)
sha256  55a199a2619d1ce91570bd3bbf0840b9f411fe1c6fc6139c78c50a794fe36783

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, so this installs straight over it — versionCode 1 → 2. 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.

New in 1.1 — colour correction

• Eleven values. Red, green and blue gain; gamma as one slider or three; saturation,
  contrast, hue rotation and a brightness offset. Every slider shows its number, and tapping
  the number opens a keypad for an exact entry — held to that field's own range, so a hue turns
  ±180° while a gain stops at ±100%, and an out-of-range entry is refused rather than silently
  clamped to a value you did not type.
• Presets you own. Seven ship — Vibrant, Warm, Cool, Night, Protanopia, Deuteranopia,
  Tritanopia — seeded as ordinary saved rows rather than a fixed menu: open one, move a slider,
  save it under a new name, rename it, delete it. No cap on how many you keep.
• Per game. A profile can carry a colour preset, applied when the game comes to the front
  and put back when it leaves — from the reading taken before the change, which is the same
  restore rule every other profile field follows.
• In the overlay panel. Saturation, contrast and hue join the existing volume and brightness
  sliders, a Colour tile joins the action grid, and a long press on it drops your saved presets
  in as chips. Everything applies as the slider moves, with no confirm step.
• In the session report. Which preset, and which values, the display was held at while the
  session ran. Sessions recorded before 1.1 read back as no colour reading rather than as a
  neutral one.

What Android actually allows, and what this does about it

Android exposes no per-channel colour matrix to an app. ColorDisplayManager's matrix and
SurfaceControl.setDisplayColorTransform are hidden platform API that neither
WRITE_SECURE_SETTINGS nor a shell running as uid 2000 can reach. Eleven sliders that wrote
into that matrix would have been the easy version and would also have been a lie.

So the values you set are projected onto the sinks that do exist on the device the app is
running on — night-display warmth, the display colour mode, the daltonizer,
reduce-bright-colours, colour inversion — and the screen lists every write it would make, names
each value this particular device has no sink for, and says why. The colour-vision filters are
the one part the platform implements properly for ADB-level authority: the daltonizer runs in
the compositor and applies device-wide.

Reset restores each setting to the reading taken before the change rather than writing neutral
values over the top, so a night shift or colour mode you set yourself is left where it was.

Colour correction needs WRITE_SECURE_SETTINGS, which Android never grants an app on its own —
Shizuku or a wireless-ADB pairing is the only way to hold it. Without it the screen says so and
points at the setup; it does not present sliders that write nothing.

Also in 1.1

• WRITE_SECURE_SETTINGS is the third permission the Shizuku screen can grant to this app
  itself, with its own explanation of what it unlocks.
• The elevated command surface is still closed and still enumerated by a unit test: nineteen
  settings keys now rather than eleven, three self-grants, two self-app-ops, no shell
  interpreter anywhere in it, every externally-sourced argument validated against a form before
  a command is built.
• 126 JVM unit tests across 8 classes, including the colour model's range clamping, its
  field-by-field round trip, and the shipped presets.

Unchanged from 1.0

The floating overlay and its control panel, the performance pill, the HUD builder, the
crosshair, per-game profiles, monitoring, encrypted session tracking, 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 without a working adb, so the instrumented suite could not
be executed and the overlay, screen recording, Shizuku and colour-write paths have not been
exercised end to end on a phone by the build itself. The JVM unit suite covers the geometry, the
formatters, the sanitizer, the command builder and the model invariants.