GameCore 3.5.4 — config editor and resolution override

Two features in this release: a config editor for the games that keep their settings in a file, and a per-game render resolution.

Config editor

Some games keep their graphics and control settings in a plain config file in their own shared-storage directory, and changing a value there is the only way to reach a setting the game's own menu does not offer. GameCore can now browse and edit those files.

• It stays inside the game's own Android/data/<package>/files directory. A path guard refuses anything that tries to climb out of it, and it never touches the game's code or its private storage.
• Every write is shown to you line by line before it happens. You see exactly which lines change, and nothing is written until you confirm.
• The file is staged and then committed whole, atomically, so an interrupted write cannot leave a half-rewritten config behind.
• The original is backed up automatically before the first edit. You can also take named checkpoints as you go and restore any of them later.
• If the game updates its config file behind you, the editor says so rather than quietly writing over the new version.
• A one-time notice before your first edit, and it needs Shizuku.

Resolution override

• A per-game render resolution, set as a scale of the display's native size and applied through wm size when the game comes to the front.
• Cleared and the display put back exactly as it was when the game leaves — the same restore rule every other profile field follows.
• Lowering it can lift frame rate on a GPU-bound game, at the cost of sharpness. It is per game, off unless you set it, and it asks once for confirmation the first time because it reshapes the whole display while the game runs.
• An in-game status chip shows while an override is active, so a changed resolution is never a mystery. Needs Shizuku.

Also in this build

These have been in the source since 3.5 but have never shipped in a release until now:

• A pinned magnifier — a loupe that shows the centre of the screen enlarged. A crop-and-scale of one capture frame, parked so it can never magnify itself. No detection, no tracking, no aim logic.
• Panel macros — a named, ordered set of overlay actions you already have, fired in sequence by one tap.
• Config backup and restore — export every configuration store to one file and restore it later. Configuration only; your recorded sessions are never written into it and a restore cannot overwrite them.
• Profile transfer — share game profiles as a file, presets and all, recreating what is missing and matching-then-remapping what already exists.
• Profile suggestions — a starting profile derived only from what a game was measured doing, with a sentence behind every field. A game with thin history gets no suggestion rather than a guess.
• Per-sample export — one row per sample, the raw time series behind a graph, as CSV or JSON. Blank, never zero, for a reading a sample never took.

Notes

• Database schema 13, migrated in place. Your profiles, sessions and Aim Lab runs carry over.
• Five new elevated commands (ls, stat, cp, mv, rm -f), all bounded to one game's own config directory and enumerated by the command test alongside every other one.
• No new Android permissions.
• The README's account of what the app can run with elevated authority has been brought up to date, including the config editor's writes.

versionCode 22 · versionName 3.5.4 · minSdk 26 · targetSdk 34

GameCore 3.5

GameCore 3.5 — the app now sets itself up, and then looks after the session on its own. Four new
features, plus two versions of redesign work (3.3 and 3.4) that never reached a release until now.

Download

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

size    12,859,169 bytes (12.3 MB)
sha256  b6bfe5cb846ac7c924788701fabf6b105fba0b73024367c9d84855940ce3bfde

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 every release since 1.0, so this installs straight over any of them — versionCode
16 → 19. 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. Your profiles, HUD layouts, crosshairs, sessions and Aim Lab runs survive the
upgrade: the database moves from schema 10 to 11 through one additive migration, and every statement
in it adds a column.

A first-run setup wizard, and a Setup health screen

A new install used to land you on an empty Home screen, where the way to find out what GameCore
needed was to try something and watch it not work. It now walks through it: which features you want,
and then only the permissions those features actually use.

Nothing is granted on your behalf and no step is required. Skip all of it and the app still runs,
minus whatever you skipped — which is the honest outcome rather than a nag screen that will not let
go. Every permission the wizard offers says what stops working without it.

Afterwards, Settings › Setup health is the same information as a report: every item with its
real state — Ready, Not set up, or Unavailable with the reason Android gave — a Fix button that opens
the exact system page, and a re-check when you come back from it. The two halves of each row come
from deliberately different places: whether you want a thing is read from your own profiles and
settings, whether it is present is read from the platform. A screen that read both from one place is
how a permission ends up reported as missing because it is granted.

Upgrading never re-runs the wizard over your existing setup. If something needs attention it offers a
dismissible card on Home, and only then.

Thermal auto-downshift

Off by default, per profile. When the device holds a temperature you choose, or the thermal status
Android reports crosses the floor you set, the refresh rate steps down — and steps back up once it
has stayed cool for long enough.

The reason it is not a single threshold is that a single threshold oscillates. You set the
hysteresis, the sustain window in each direction and the minimum time between changes, so a
temperature sitting on the line produces one decision rather than a stream of them. The state
machine that makes that decision is pure Kotlin with an injected clock, and it is tested against
held, spiking and drifting temperatures rather than against one reading.

The session records how many times it stepped down and the lowest rate it reached, so the question
"did this actually do anything during that match" has an answer that is not a guess.

This is not a thermal limit override, and it is not a governor tweak. It lowers a refresh rate that
GameCore had already been asked to pin, and it reports what it did.

Network check

Off by default, per profile. Before a launch it can warn you about the connection you are about to
play on; during a session it can alert you when the connection turns poor.

It reads the transport, the Wi-Fi band and the link speed — and nothing else. No SSID, no BSSID,
and no location permission, which is the permission Android would demand before handing either of
those over. The app declares no new permission of any kind for this feature.

"Poor" is latency, jitter, or probes that stop coming back, each rated separately so the alert can
say which one it was. A probe that did not complete is reported as a probe that did not complete —
it is still not called packet loss, because a TCP handshake that times out is not a dropped packet,
and that distinction has been in this app since the latency log shipped.

Anything Android will not report shows as Unavailable with the reason it gave.

Keep full performance under battery saver

Off by default, per profile. Battery saver caps the refresh rate and the governor on most builds,
which is correct for a phone in a pocket and wrong for the twenty minutes you spend in a match.

With this on, a profile holds full performance for that game anyway, puts the saver's own behaviour
back when the game exits, and notices when the system switched the saver back on behind it — which
some builds do, at a low battery level, without telling the app. That case is recorded on the session
rather than silently ignored, because a session that ran at half the rate you asked for should say so.

No new access of any kind: it goes through the same elevated shell the refresh-rate setting already
uses, and says so when Shizuku is absent instead of failing quietly.

Also new here: the 3.3 and 3.4 redesigns

Neither of these has been in a release before.

The in-game overlay (3.4). The floating button has real states — dimmed after a few seconds
idle, with a small orange or red dot when the shared thermal classifier says hot or critical — three
sizes, four corner snaps, and a position stored as fractions per orientation, so it is where you left
it after a rotation rather than near where it was.

Tapping it now opens a quick sheet: a narrow panel on the screen edge nearest the button, holding
up to six toggles you pin yourself, brightness and media volume, the game's own icon and the session
clock. It is narrow on purpose. The point of the redesign is that the things you reach for mid-game
should not cover the game to reach them.

The full panel is still there, behind More or an optional double tap, now divided into
Display, Overlays, Capture and Session tabs, with a hold-to-confirm End session so a
misplaced tap cannot end a run. Every control that was reachable before is still reachable and still
does exactly what it did; a test enumerates them to keep that true. Switching the panel's layout to
split-across-both-edges keeps the earlier design.

The stats pill comes as a compact single line or a detailed card, with one shared formatter for units,
rounding and unavailable values — so the pill, the HUD and the panel cannot disagree about the same
number. And it stops sampling the moment nothing is looking at it, including when the screen goes
off, which is where it previously kept ticking under the foreground service's doze exemption.

Themes (3.3). Follow system, Dark, Light or AMOLED black — a true #000000 background that
switches OLED pixels off rather than dimming them, with near-black surfaces separated by outlines
instead of by a lighter fill. Eight accent colours or one you pick yourself, applied across the app
and the overlay windows alike, with contrast checked rather than assumed.

Also from 3.3: one shared thermal classifier instead of eight independent call sites, which is what
fixed the HUD reporting "Normal" at 85 °C.

Under it

• Room schema 10 → 11. One hand-written migration, every statement an ALTER TABLE … ADD COLUMN,
  schema JSON checked in, no destructive fallback anywhere in the app.
• 1254 JVM unit tests across 97 classes, no failures and no errors. The four new features are four
  pure state machines with injected clocks, tested independently of Android.
• No new permissions, no new services, no new exported components. The manifest is byte-identical
  to 3.4's.
• No new network access. The network check reuses the existing latency probe — a payload-free TCP
  handshake to a host you choose — and reads everything else from the platform on the device.
• Still 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.
• No ads and no advertising SDK. The README paragraph that still described a banner has been removed;
  it had been stale since the ads came out.

Unchanged

Per-game profiles, automatic profile detection, the crosshair overlay and its eleven designs, the HUD
builder, monitoring, encrypted session tracking, the shareable session card, colour correction,
display size, game storage, the Aim Lab and its seven modes, fire modes, and the closed elevated
command set with no shell interpreter in it.

Untested on hardware

The build host is an aarch64 device with no working adb, so the instrumented suite was not run and
the on-device visual pass is not part of this build. What is covered is the pure seams: the samplers,
the aggregators, the capability reasoning, the wizard's entry and step logic, the thermal, network and
battery-saver state machines, the formatters, and the reachability of every overlay control.

Release 3.2

New in 3.2
Two additions to the Aim Lab, both about the weapon and the way you hold the phone.

Fire modes. A weapon now discharges in one of three ways — single, a fixed burst, or full auto — and the training loop honours it: a burst walks up the recoil pattern at the real fire-rate cadence rather than landing all at once, and the magazine and reload gate every mode the same. The weapon editor picks the mode and, for burst, the round count; a built-in Burst Carbine ships so the mode is there to try without building one. Older saved weapons read back as auto — exactly what they already did — so nothing changes under you.
On-screen controls on every mode. The saved control layouts (HUDs) you build in the editor can now be drawn over the arena during a run from any mode's setup screen, not just some — pick one, or leave it on "None" for a clean view. The choice is per run and never forced.
Also from 3.1: the Aim Lab runs in landscape with a real horizontal field-of-view setting, the gyro axes remap correctly per screen rotation, and control layouts are stored per orientation.

Gamecore 2.1

U can change the layout in the game pill
Ai agent is down so I'm doing this rn
And also media playback support
U can change media from the game pill
Drop suggestions for new feature if u need

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.

V2.3: Release 2.0: reach a setting without putting the game down

I might integrate ads but I doubt it
I'm just bored
drem0663_16012 my discord.
Quick-launch apps in the control panel

A row of up to six app icons, under the action tiles in the overlay panel. Tap one and
it opens — the same launch your home screen uses, so there's nothing extra to set up
and no elevated shell involved.

It's optional and off by default. Turn it on in Overlay → Control panel → "Show
quick-launch apps", then pick your apps. The row is empty until you fill it, and an
empty row draws nothing at all, so a panel you haven't configured looks exactly as it
did before.

• Works with either panel layout. Centred or Split edges — the row isn't a third
  shape to choose between, it appears in whichever one you're already using.
• Your order, not alphabetical. Six positions under a thumb: the first icon is the
  easiest one to reach, so you decide which app gets it.
• Uninstalled apps say so. An app that's gone is drawn dim and marked rather than
  vanishing from the row or failing silently when tapped.
• Opening an app doesn't end anything. The overlay stays up and game detection
  keeps running — it's the same as switching apps any other way, and the panel is where
  you left it when you come back.

Picked from your installed apps, stored as package names in the same encrypted settings
as everything else. No defaults, no bundled list, no suggestions.

Want a shorter one-liner for LinkedIn, or is this the one?

GameCore 1.3

GameCore 1.3 — a cache cleaner that reports what it actually freed, a per-session
latency log that refuses to call anything packet loss, a session card you can share, and the four
bugs reported against 1.1.1.

Download

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

size    12,294,165 bytes (11.7 MB)
sha256  7c66e86ca7d4baac39e20916d8458af299fc544c24e9464b9c3642e091fb10b3

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

Game storage

A screen under Settings that measures what every installed game is holding — cache, of which
clearable, and untouched — and clears one game's shared-storage cache on a tap.

The measurement is the feature. It reads the size, deletes, waits for the filesystem to settle,
reads again, and reports the difference between the two readings rather than the command's exit
code. A clear that freed nothing says nothing was freed, which is the opposite of what a booster app
does with the same situation. externalCacheBytes is API 31+, so on Android 11 and older the
clearable figure reads as needing a newer Android instead of a guessed fraction of the total.

The delete is one literal path — rm -rf /storage/emulated/<user>/Android/data/<package>/cache —
with the package name validated against the platform's own grammar, the user id derived from
GameCore's own uid, and the argv handed straight to exec. rm is the tenth program in the
closed elevated command set and it is reachable in exactly one form, asserted literally in the
command test so a second use cannot be added without that test failing. pm clear and
pm trim-caches stay forbidden. A game's private cache is out of reach at this privilege level and
the screen says so, offering Android's own storage page on every row rather than pretending
otherwise.

Measuring needs usage access; deleting needs Shizuku. Without either, the rows say which one is
missing.

What the connection did, across the whole session

A session now carries a latency log: probes that completed, probes that did not, the worst reply,
jitter, the longest unbroken run of failures, and a verdict — Stable, Spiky, Unreliable,
No reply or Not measured — with the figures behind the word in a sentence beside it.

A spike is twice the session's own running average and at least 40 ms above it, counted only
after three probes, so a fast link is not called spiky for one 12 ms wobble. "Stable" is withheld
until there is enough evidence for it, while one failed handshake is reported at once.

None of it is called packet loss. Android grants an app no raw sockets, so there is no ICMP ping
here; the probe is a timed TCP handshake, and a refused handshake is a probe that did not complete
rather than a dropped packet. There is no loss percentage anywhere in the app, and the wording is
deliberate at every read-out.

A card you can share

A finished session renders to a 1080×1260 PNG and goes out through your own share sheet, the way a
screenshot does.

Every string on the card is decided by a pure model that is unit-tested; the renderer only turns
those strings into pixels and holds no rule about an absent reading, so it cannot turn a dash into a
zero. A reading this device could not take is an em dash, and the caption says a dash is a reading
the device could not take rather than a zero. An interrupted recording prints its duration as a
lower bound. A per-hour battery figure appears only when the session was long enough to support one,
and falls back to the plain subtraction when it was not. The sample count travels with the averages,
and a handful of samples is not presented as an average at all.

The game's own label is the one string on the card GameCore did not write, so it is stripped of
control characters, collapsed, clamped, and kept out of the filename entirely. Cards are written to
the app's own files directory, at most four are kept, and the content:// URI never reaches a
composable — the ViewModel keeps it and hands the screen a boolean and an Intent. Nothing is
uploaded.

The four bugs

The crosshair drew the dot preset whatever you picked. Not a rendering fault. A request built
with crosshair = true and no preset id asks for a crosshair rather than the user's, and the
renderer cannot tell those apart, so it fell back to the lowest-numbered saved preset — which is the
dot. The id is now settled from the caller, the request already in hand, and the last preset picked,
in that order. The HUD had the identical bug and is fixed the same way, because a layout
somebody arranged is not "any layout".

A profile edited after leaving a game did nothing until GameCore was restarted. The profile is
re-read when a game starts and nowhere else, and a game returning after a real absence announced
nothing at all: the grace window that separates an interruption from a stop was applied to the game
going away but not to it coming back. A return after that window is now a stop dated when the game
left followed by a start dated now — stop first, so the previous sitting's values are restored
before the current profile is applied over them.

The resolution section stuck on "loading" after quitting a game. An unbounded pipe read while
holding the app-wide shell mutex: one command whose output never ended froze every later elevated
read behind it, and the display-size card is simply where a user notices first. The drain is bounded
now.

A Do Not Disturb popup put DND back on after you had turned it off by hand. Restore-on-exit had
no way to ask whether the value it was about to put back was still its own to put back. A write
ledger answers that: GameCore restores a device setting only when it made the write and nothing
outside GameCore has changed it since. Colour presets were the same bug in a second place, and are
fixed with the same ledger.

Under it

• Room schema 5, hand-written additive migration, schema JSON checked in — no destructive fallback.
• 293 JVM unit tests across 26 classes, no failures.
• The elevated command set is ten programs and still has no shell interpreter in it, so there is
  still no string to inject into. 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: the latency log reuses the existing TCP probe and its host setting, and
  the card is drawn on the device.

Unchanged

The floating overlay, the performance pill, the HUD builder, the crosshair, per-game profiles,
monitoring, encrypted session tracking, colour correction, display size, 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, no thermal-limit override, and nothing advertised
over a game.

Untested on hardware

The build host is an aarch64 device with no working adb, so the instrumented suite could not be
run and the overlay, Shizuku, colour-write, wm size, am kill and rm -rf 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 cache selection, the
latency fold, and every string the shareable card is allowed to print.

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.

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.

GameCore 1.0

GameCore 1.0 — an Android gaming overlay, performance monitor and per-game profile manager.

The rule the whole app is built on: no number reaches the screen unless the platform actually
reported it. Every reading is either a value that names its source and precision, or an
absence that names its reason — so some cards say "Not available on this device" or
"Requires Shizuku" instead of showing a figure. That is the feature.

Download

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

size    12,126,769 bytes (11.6 MB)
sha256  b3d4c075d28ebb223d992afce51d2fd70118c649ee18d8f0523cd1655a4102a8

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

8eef17e0163198517f765b91a29aa9414710a852281b5e6fdd6362442586d42b

With minSdk 26 the build omits the legacy v1 JAR signature entirely, 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.

What is in it

• Floating overlay — a draggable gaming button that snaps to the nearer edge, survives
  rotation and remembers where you left it. Tapping it opens a control panel directly below
  the button: brightness, media volume, screenshot, screen recording, Do Not Disturb,
  orientation lock, flashlight, and a shortcut back into the game.
• Performance pill and HUD builder — sixteen stats, drag-and-drop placement on a live
  preview, per-widget text size, opacity, colour and background, and saved layouts a game
  profile can raise by name.
• Crosshair — ten designs drawn with Compose primitives, plus an imported PNG, with size,
  thickness, centre gap, rotation, opacity, colour and position.
• Game profiles — refresh rate, brightness, orientation, screen timeout, volume, DND,
  overlays, HUD layout, crosshair preset and performance mode, per package. Every adjustable
  field is nullable and null means leave it alone, so a profile restores exactly what it
  changed and nothing else. Automatic detection applies on launch and unwinds on exit; you can
  also launch a game from its profile.
• Monitoring — per-core CPU load and frequency, memory, battery level/temperature/voltage/
  current and drain as percent per hour, thermal status, display mode, network type, latency
  and throughput, free storage. Live graphs, configurable interval, sampling that stops when
  nothing is watching.
• Sessions — written to a SQLCipher-encrypted Room database with reports, history,
  filtering, sorting and aggregate statistics. A session cut short by process death is
  repaired on the next launch rather than lost.

Honesty, specifically

Refresh rate. Only rates the panel advertises are offered, and a change is reported as
applied only after it has been read back. On several MediaTek and PowerVR devices the standard
preferredDisplayModeId call is accepted without error and then ignored; GameCore says
"accepted the request but stayed at 60 Hz" and offers the Shizuku path, which works there.

FPS. Reliable per-frame timing is generally unavailable through public APIs without root
or instrumentation and varies by OEM and GPU. It is detected per device and honestly absent
when no usable signal exists.

Not in this app at all: root, game-file modification, code injection, process memory
access, anti-cheat interference, fabricated statistics, background-app killing, thermal-limit
override.

Shizuku is optional

Everything works without it. With it, ADB-level authority reaches the device-wide
refresh-rate bounds, animation scales and a few dumpsys reads Android does not expose to
ordinary apps. The command surface is a closed set — id, cat, dumpsys, settings,
getprop, and pm grant / appops set aimed at this app only — with no shell interpreter
anywhere in it, and every externally-sourced argument validated against a form before a
command is built.

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 and Shizuku 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.