GameCore 2.0

GameCore 2.0 — five additions, all of them about the same cost: leaving a game to change
something the overlay could have changed in place. A control panel with a second shape and a tile to
switch it, refresh rate from the panel, a crosshair picker behind a held press, an eleventh design,
and per-profile CPU affinity presets that say plainly what they are worth.

Download

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

size    12,327,369 bytes (11.8 MB)
sha256  1c6539a13b7e0aad08e930ceec98f2572abc13edde22e7085a106b557b5eb37d

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, 1.1, 1.1.1 and 1.3, so this installs straight over any of them — versionCode
7 → 8. 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.

A second shape for the control panel

The panel can now split into two plates pinned to opposite screen edges — readouts on one, controls
on the other, full screen height, with the game still visible between them — instead of one plate
below the floating button.

Centred stays the default, and that is a decision rather than an oversight: a panel somebody has
already learned the shape of should not rearrange itself because they took an update. The new layout
is offered, not imposed.

Each plate scrolls independently, and the split derives its geometry from the screen rather than from
the stored panel width. The width you set for the centred panel is kept untouched while you are in
the split layout and is still there when you switch back, so trying the other shape costs nothing.

The Layout tile — switching shape without leaving the game

Changing the panel's layout used to mean closing the game, opening GameCore and finding the setting.
There is now a Layout tile inside the panel itself, and one tap moves between the two shapes.

It is a toggle rather than a row of chips, and the difference is the reason the tile is worth having.
The two tiles beside it — display shape and refresh rate — open chips because they offer several
values the device reported, and a row is the honest control for that. A layout is one of two, and
the tile's own plate already says which one is on, so chips behind a tap would be two taps to change
one bit. That would refund only part of the cost the tile exists to remove.

Nothing confirms the tap, because the panel rearranges itself under the finger that made it: the
confirmation is the thing you asked for. The tile reads the way every plate in that grid reads —
lit means not the default — so lit means split.

The tap writes GameCore's stored preference and lets the service's own configuration observer rebuild
the open window. It does not reach for a window directly. Which means a switch from the panel and a
switch from the settings screen take the same path and end in the same place, and this tile cannot
leave a panel on screen in a layout the stored preference disagrees with. The plate is lit from that
preference rather than from the window currently drawn, so it does not go dark for the one frame
between the tap and the rebuild.

It is the only tile in the grid that is never unavailable, and that is not a judgement call: it
writes a preference of GameCore's own and reads nothing from the device, so there is no permission,
elevation or platform version that could refuse it.

Refresh rate from the panel

Every rate this display reports, as chips under the tile grid, plus the way back off a pinned one.

The honesty rule here is doing real work. The platform is entitled to drop a pinned panel to 60 Hz
on a static screen, so a low reading is not evidence the pin failed, and a high one is not evidence
it holds. The tile therefore lights only from a change GameCore made and then read back. A rate
that was written but could not be verified says exactly that, rather than reporting success it did
not observe or failure it did not observe either.

Crosshair quick-select

Hold the crosshair tile for the active crosshair's design and colour, without opening a screen.

It offers the built-in colours plus the ones you already mixed somewhere with more room. There is no
HSV square, deliberately: that is a two-handed control, and this window is open over a game.

Held presses are reserved for tiles whose tap is already spent. If a one-shot tile ever needed a row,
the honest place for it would be the tap, because nothing else was competing for it — so this is a
rule about which gesture a row belongs on, not a coincidence between two tiles, and it is asserted as
a property rather than as a list of pairs.

An eleventh crosshair design, and more colours

A box — a square outline, for framing a target rather than marking a point. Eleven designs now:
cross, dot, ring, ring-and-dot, cross-in-ring, T, X, chevron, corner brackets, box, or a PNG you
import.

CPU core affinity presets, marked experimental

A per-profile choice of which cores a game's main process may run on: performance cores only, or
all cores minus one efficiency core.

The app says what this is worth in the same words every time it appears, and the words are not
flattering: it may reduce stutter by controlling which cores the game runs on, it does not make
the device faster, and depending on the game it can do more harm than good. It is labelled
experimental wherever it is offered.

The mask the process was found on is read and recorded before anything changes, and written back
when the game exits — so this leaves the scheduler where it found it rather than where it guessed the
default was. It needs Shizuku, and says so when Shizuku is absent instead of failing quietly.

taskset is the eleventh program in the closed elevated command set, and the only one that can run
another program. It is reachable in exactly two forms — taskset -ap <pid> to read and
taskset -ap <mask> <pid> to set — both asserted literally in the command test, so a third use
cannot be added without that test failing. There is still no shell interpreter anywhere in the set,
which is why there is still no string to inject into.

Under it

• Room schema 6, hand-written additive migration, schema JSON checked in — no destructive fallback.
• 393 JVM unit tests across 33 classes, no failures, no errors.
• The elevated command set is eleven programs and contains no shell interpreter. Every argument is
  validated against a form before a command is built, and a rejected argument produces no command at
  all rather than a malformed one.
• No new network anywhere. Nothing added in 2.0 makes a request.
• Nothing advertised or promoted in the floating pill, the control panel, or anywhere else visible
  while a game is running.

Unchanged

The floating overlay, the performance pill, the HUD builder, per-game profiles, monitoring, encrypted
session tracking, colour correction, display size, game storage, the session latency log, the
shareable session card, the resizable panel — and the absences: no root, no game-file modification,
no code injection, no process memory access, no anti-cheat interference, no fabricated statistics and
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
run. The overlay windows — including the split layout and the Layout tile's close-and-reopen — and
the Shizuku, colour-write, wm size, am kill, rm -rf and taskset paths have not been
exercised end to end on a phone by the build itself. The JVM suite covers the pure seams: the
samplers, the aggregators, the capability reasoning, the command builder, the affinity mask parser,
the refresh-rate verdicts, the layout switch, and every string the shareable card is allowed to
print.