Repository navigation
Releases: igorcv88/WaEnhancerXCommunity
Release list
WaEnhancer Community 0.0.29
WaEnhancer Community 0.0.29
SHA-256: 6ceb9be48a2ae8000eff4968e7d67468cfe2c27261e6a775800e3c7819bc60d9
Changes since v0.0.28.
What's changed
- #101 Separate navbar, bubble and app-chrome glass calibration
Full changelog
This section compiles the descriptions of the pull requests included in this release.
#101 — Separate navbar, bubble and app-chrome glass calibration
Merged by contribution from @igorcv88.
Physical screenshot review shows recognizable stickers behind the composer and weak surface boundaries. A subsequent 6.28s recording shows the expanded tab bubble has a much brighter contour than the navbar body. Source inspection confirms separate recipes: bar via LiquidLens/GlassSurface, app chrome via LiveBackdrop, bubble via LiquidBubble/KyantLens.bubble. The prior body edits were not accidentally wired only to the bubble; its original stronger rim remained.
Changes:
- Navbar/GlassSurface: keep 10dp blur and neutral body; strengthen contour gain to 1.6 and width to 1.15dp. Scroll button shares this view route.
- Composer/header and drawable app surfaces: 30dp blur, contour gain 1.8 and width 1.25dp. Capture and admission budget use matching larger padding.
- Animated bubble: scale highlight to 0.45 of glass progress, preserving motion, refraction/chroma and shadow.
Contour gain is part of effect caching and uploaded as a uniform. Colour/opacity/saturation remain unchanged. No new passes, sampling sources or budget capacity. Larger app blur/padding may increase GPU cost; large-scale colour fields can remain visible.
Validation: six source-extracted numerical shader tests pass; diff whitespace passes. Added/updated Java parameter cases for independent blur/padding, bar/app contours and bubble highlight (not executed). Default uniform gain=1 exactly matches old rim arithmetic across 1000 numerical cases; the new navbar gain intentionally changes output. Android/JUnit compilation, AGSL compilation, APK and device visual/performance validation remain pending because the toolchain is unavailable. No workflow dispatch.
Other changes
These commits reached master without an associated merged pull request:
bf513f9Fix glass contour contrast on white backdrops after PR 100 review
WaEnhancer Community 0.0.28
WaEnhancer Community 0.0.28
SHA-256: 298da72a585d1aba84feef3e7aef21f88b8878a1a426a38576871fb48f02d3e7
Changes since v0.0.27.
What's changed
- #100 Restore a persistent integrated rim without changing glass colour or blur
Full changelog
This section compiles the descriptions of the pull requests included in this release.
#100 — Restore a persistent integrated rim without changing glass colour or blur
Merged by contribution from @igorcv88.
Physical review after #99 approved the glass body and blur but showed the contour disappearing on dark backgrounds, particularly around the composer. The previous reflection vanished at the outline and could also vanish on back-facing edges.
Add a narrow grazing reflection with a nonzero all-angle floor, joined to the softer directional bevel through the same reflected colour. Local backdrop luminance increases the contour strength. Gaussian falloff starts at the actual outline and fades into the material, avoiding an inset stroke or detached second border. The existing directional bevel contribution is reduced to avoid a strong second band.
Reference: OneUILiquidGlass@2b278cd4cb7dda8e9562d360033fbdbb9320de89, LiquidGlassShader COMMON/edge and sfhook/refract.h. Adopt the persistent-contour-plus-directional-light principle; no shader code, hooks, tint, blur or RGB fringe imported. Its popup overlay cannot sample compositor backdrop pixels; WaE already has local live samples and uses those for modulation.
Preserved exactly: approved body colour/opacity/saturation, 10dp blur, refraction, capture/recovery, selected-tab bubble, classic/fallback paths. No new samples or drawing passes.
Validation: git diff --check; source comparison confirms all post-shader parameter/effect code and pre-lighting shader code are unchanged. Numerical checks cover persistent black-background contour at all light values, luminance response, interior falloff and 10000 premultiplied-colour cases. No Java/AGSL compilation or APK: local Gradle/Android tooling and glslangValidator remain unavailable. Physical verification pending, especially composer corners and dark/bright backgrounds. No merge or workflow dispatch.
WaEnhancer Community 0.0.27
WaEnhancer Community 0.0.27
SHA-256: 15d5cf55981efe65b1e0ed3b4be81b037d9f925c5149a16908700e6d9b51c2c7
Changes since v0.0.26.
What's changed
- #99 Neutralize Liquid Glass and integrate backdrop-responsive edge lighting
Full changelog
This section compiles the descriptions of the pull requests included in this release.
#99 — Neutralize Liquid Glass and integrate backdrop-responsive edge lighting
Merged by contribution from @igorcv88.
The floating bar and composer show a blue-grey wash and a bright continuous outline. The OneMate surface path currently boosts backdrop saturation to 1.5 and applies a theme-coloured wash at 40% default opacity.
This change uses unchanged backdrop saturation and a neutral wash at 18% recommended opacity. Surface edges retain illumination through a smooth directional bevel reflection whose colour and strength follow the live refracted backdrop. It removes the constant white stroke, not the illuminated edge. The selected-tab bubble keeps its existing treatment and motion.
The 10dp blur, radius conversion, padding, refraction, capture and recovery paths are unchanged. Classic rendering and fallback are unchanged. Settings explanation, architecture, handoff and existing material parameter tests are updated.
Validation: git diff --check passed; numerical reflection-envelope and premultiplied-colour checks passed. Java/JUnit and Android build were not run successfully: Gradle 8.14.5 is not cached and download is network-blocked; Android SDK/compiler unavailable. The shader checker is blocked by missing glslangValidator. No APK, workflow dispatch or device validation.
Physical acceptance pending: compare composer and floating bar over neutral and coloured moving content, check hint/icon readability in both themes, verify soft integrated edge lighting and unchanged blur. 18% wash and 0.32 reflection strength require visual review; no claim of physical acceptance.
WaEnhancer Community 0.0.26
WaEnhancer Community 0.0.26
SHA-256: afe1e20a9a90a369b99f6fedccec7f82e0484d5a3edf206d4da33bb832cb0ccc
Changes since v0.0.25.
What's changed
- #98 fix: restore WhatsApp emoji font rendering and Lite Mode loading
Full changelog
This section compiles the descriptions of the pull requests included in this release.
#98 — fix: restore WhatsApp emoji font rendering and Lite Mode loading
Merged by contribution from @igorcv88.
Context
PR #97 was already merged at 92242056f46f3e8ca33bb9b15904c239f98d6e36. This follow-up PR is based on that merge, on branch fix/emoji-span-rendering-lite-20261022.
Changes
- WhatsApp rendering path: physical One UI 9 logs showed
fontLoaded=trueon three starts and 16 draw hooks installed, but no draw interception. A guardedSpannableStringBuilder/SpannableStringsetSpanhook now recognizes emoji-onlyReplacementSpanranges and substitutesTypefaceSpanfor the user-imported TTF once available. Regular text and unrelated spans remain unchanged. - Review P2 fixed (async font load): spans created before the TTF is ready no longer remain permanently overlooked. The original WhatsApp span renders during the load; the hook tracks up to 256 pending text/span pairs via weak references. On successful load, a main-thread pass revalidates live emoji ranges, inserts a typeface span and removes the original bitmap span. This handles the insertion/load race; if loading fails, the original WhatsApp spans remain. Diagnostics distinguish
First emoji replacement span deferred,First emoji replacement span bypassedanddeferredEmojiSpansApplied=N. The 256-entry cap and WhatsApp text copies remain physical-test limitations. - Earlier P2 on #97 (Lite Mode): when
WppCore.initBridge()is intentionally skipped, use a temporary independentProviderClientonly for asynchronous read-onlyopenEmojiFont(), without initializing the global bridge. - Update architecture and handoff documentation. Never bundle the user's Apple artwork or touch system fonts/OverlayFS, GMS or system_server.
Validation
- 8 Java TTF/classifier JUnit tests passed, including validation with user's 42 MB TTF sample in the local suite.
- 4 repository runtime/IPC host checks passed;
git diff --checkclean. - Full Android APK compilation and on-device acceptance are not yet verified; no workflow dispatch or merge.
Device gate
Build the full app-only release APK pinned to the current PR head (stable channel for the intended user test). Import the TTF, enable Disable Default Emojis, restart WhatsApp, then check composer text, existing bubbles, new messages, captions and reactions against 😍 ❤️ 🇧🇷 🧑🏽⚕️. Inspect [WAEX][EmojiFont] logs: fontLoaded=true, installedSpanHooks=2, replacementSpanCandidate=... and First emoji replacement span bypassed. When startup is slower, expect First emoji replacement span deferred followed by deferredEmojiSpansApplied=N. Check ordinary words/numbers are unaffected. A successful span marker alone does not prove full compatibility.
WaEnhancer Community 0.0.25
WaEnhancer Community 0.0.25
SHA-256: 9e29e0f6fef31cb3b555bb8ae2222ef12636548dbf1da79dd5f4f8aa58b9ffb9
Changes since v0.0.24.
What's changed
- #97 feat: import a user-selected emoji TTF for WhatsApp rendering
Full changelog
This section compiles the descriptions of the pull requests included in this release.
#97 — feat: import a user-selected emoji TTF for WhatsApp rendering
Merged by contribution from @igorcv88.
Why
On One UI 9, FlipFont can apply a user-selected iOS-style emoji font in most apps, while WhatsApp's own emoji spans continue to render another style. The existing Disable Default Emojis hook calls Canvas.drawText() using WhatsApp's original Paint; it never selects the user's custom typeface, and a checked switch does not prove that hooks were installed.
Changes
- Adds Custom WhatsApp emoji font to standalone and embedded Conversation settings. The user selects any compatible color emoji TTF through Android's document picker; the companion app validates SFNT tables, limits size to 128 MB, checks Android Typeface loading, and atomically stores one private copy. Users can remove the copy at any time. No Apple/proprietary font is bundled or committed.
- Adds a dedicated, UID-authenticated, read-only
openEmojiFont()Binder capability with no user-controlled path. Existing private-file access restrictions remain intact. - Loads the selected font asynchronously once within the WhatsApp process, intercepts emoji-only span draws, clones
Paint, applies the chosenTypeface, and preserves non-emoji spans and the original draw path on failures. Includes a fallback hook for inheritedDynamicDrawableSpan.draw, even when DexKit fails to resolve WhatsApp's obfuscated spans. - Logs only hook counts, font readiness, and the first emoji draw for device diagnosis; never logs message text. Updates English/Portuguese strings, architecture and handoff.
Validation
- Passed: 8 host-side JUnit tests (emoji-sequence classifier, SFNT validator, actual supplied 42 MB
iOS18.4.ttf), all 4 repository IPC/runtime harness tests (authenticated, read-only font FD, symlink/missing-file rejection), 5 XML parser checks, embedded settings JSON check,git diff --check. - Not run: full Android Gradle test/build (no Android SDK installed in this container; JDK 21 and Gradle 8.14.5 work). No APK or physical One UI 9/WhatsApp test is claimed.
- No systemless modules, Google Play Services changes,
system_serverhooks, workflow dispatch, merge, or phone changes.
Device verification after compiling
- Install the updated WaEnhancer APK and keep its LSPosed scope limited to WhatsApp.
- Conversation settings → Custom WhatsApp emoji font → import the user's own compatible TTF; keep Disable Default Emojis enabled.
- Force-stop/reopen WhatsApp; compare
😍 ❤️ 🇧🇷 🧑🏽⚕️before sending and in bubbles/captions, and check typography/non-emoji spans. - Read
[WAEX][EmojiFont]logs.fontLoaded=true+ a first intercepted draw proves font transport and hook execution; neither guarantees exact visual matching. No intercepted draw suggests a version-specific renderer not covered by these hooks.
This is a focused implementation for review; runtime compatibility remains pending a physical test.
WaEnhancer Community 0.0.24
WaEnhancer Community 0.0.24
SHA-256: 399b5cc720a60ce5b3919cad35c213f97a98bd515f675f51f7d9fcfc5b6810a5
Changes since v0.0.23.
What's changed
- #96 Remove system hooks and confine authenticated file/preferences IPC
Full changelog
This section compiles the descriptions of the pull requests included in this release.
#96 — Remove system hooks and confine authenticated file/preferences IPC
Merged by contribution from @igorcv88.
Result
Keep WhatsApp, Business and Community companion as the only Xposed processes; remove system_server/SettingsProvider/PackageManager hooks, downgrade/update interception and optional spoof runtime. No merge or public release.
Security fixes
- Replace arbitrary file paths with canonical primary shared-storage capabilities: seven actual media output categories with supported extensions, read-only theme/selected-wallpaper images and write-only media outputs. Reject private files, shared_prefs, databases, traversal, Android app storage, sibling-prefix paths and symlink escapes. Use O_NOFOLLOW and revalidate the opened regular-file descriptor before returning it or truncating an output. Deny generic enumeration; no production consumer uses listFiles.
- Keep UID authentication at provider acquisition and every Binder transaction. Configured download/wallpaper paths cannot authorize module-private storage.
- Restrict preference write/remove to known non-secret Store.PUBLIC keys; validate the type tag and actual Bundle value against PreferenceSchema before editing. No private-write exceptions. Embedded private settings use the existing open-in-companion editor row. Existing named transcription/Tasker secret operations remain; generic reads/file access cannot expose private storage.
- Remove all three obsolete spoof controls from the raw injected settings map as well as prior XML/search removal.
- Retry failed preference hydration/observer registration on subsequent reads with a monotonic 500 ms limit. Preserve throttled invalidation and cached data during outages. Startup-only hooks can still require a host restart after an initial configuration outage.
Evidence and remaining build
Four local test methods pass. Actual entrypoint, auth, file Binder, provider, schema/policies, client and deferred/provider preferences are compiled/executed against host Android stubs. Coverage includes all 26 private keys, valid/malformed public values, canonical paths, private files/DBs, traversal/symlink/prefix attacks, access modes, rejection before truncate, cold-start failure/retry, settings changes and companion loss/recovery. Real host temporary files exercise canonical/symlink behavior; Android Binder/Os/provider behavior is substituted. This is not a complete Android build or physical API-37 security/functionality validation.
Full LAB compilation, existing JVM suite, signed APK and packaged Manifest/scope/DEX gates remain required before merge/installation. No phone changes or browser use in this follow-up. Audit and current handoff updated.
Manual LAB execution
Workflow: Build APK Release (build-apk-release.yml)
Branch: review/app-only-no-system-server-20261022
Inputs: mode=lab, channel=beta, expected_sha=f726edc852bd11aa1932c4e30275f111468eb533.
The previous 887b659... expected_sha/APK no longer represents the current security fixes. LAB uploads signed APK + SHA-256 + source SHA without tagging or creating a GitHub Release.
See docs/APP_ONLY_REVIEW_2026-10-22.md for capabilities, remaining device tests and rollback.
WaEnhancer Community 0.0.23
WaEnhancer Community 0.0.23
SHA-256: d902d7d4d3ce0bc0f5c3be96d91476fc939af42c1752de8c4cf74408a7fb8bc6
Changes since v0.0.22.
What's changed
- #95 fix(glass): keep Hidden FABs hidden through page swipes; stronger OneMate blur
Full changelog
This section compiles the descriptions of the pull requests included in this release.
#95 — fix(glass): keep Hidden FABs hidden through page swipes; stronger OneMate blur
Merged by contribution from @igorcv88.
Problem (ninth device recording)
-
The Calls tab's "Start a call" FAB appeared behind the floating bar during page swipes, even with the bar's FAB mode set to Hidden. Hidden was only enforced in a few places:
- when a FAB of a known class attached or re-laid out;
- in a sweep 500 ms after the bar was installed;
- on list-scroll events.
None of these runs when WhatsApp shows a FAB during a page swipe.
-
The glass read as low resolution. The OneMate capture is 1:1 (no downsampling). The cause is miuix's 4dp blur (sigma 1.8dp, ~5 px): the FAB's edge stayed hard inside the bar, and the 24dp rim lens smeared it into streaks.
Change
FloatingBottomBar.keepFabsHidden: in Hidden mode, a global-layout listener on the home root sets any visible FAB to GONE after every layout pass. Showing a GONE view always requests a layout, and the listener runs before that frame is drawn, so the FAB is never drawn.KyantLens.BLUR_DP: raised from 4 to 10 dp (sigma 4.5dp).- The blur uses CLAMP edges, so the bar's edges are not darkened.
- The capture padding and the budget margin scale with it automatically.
- ARCHITECTURE.md, the Liquid Glass page caption and the audit doc are updated.
Validation
:app:testWhatsappDebugUnitTest: 463 tests, 0 failures. The blur test now derives fromBLUR_DP.tools/agsl_check.py: all three shaders pass.:app:assembleWhatsappDebugbuilds.- Not device-validated.
🤖 Generated with Claude Code
https://claude.ai/code/session_0157emnK4gGDtGGT282rGFw8
Generated by Claude Code
WaEnhancer Community 0.0.22
WaEnhancer Community 0.0.22
SHA-256: 3d9ef3abd5de35685c761b062d0d8a5d1d219a815169df50d57ea712edd001d3
Changes since v0.0.21.
What's changed
- #94 fix(glass): tap grows the bubble while it travels; pager follow cannot hijack it
Full changelog
This section compiles the descriptions of the pull requests included in this release.
#94 — fix(glass): tap grows the bubble while it travels; pager follow cannot hijack it
Merged by contribution from @igorcv88.
Problem (eighth device recording)
- The tap glide from #93 did not run as designed. Its pager hold cleared after 80 ms of stillness, before WhatsApp started scrolling the page.
- The pager-follow took over instead. It snapped the bubble to the new tab along with the page and held it fully inflated for ~300 ms (0.83–1.12 s) before it shrank.
- The stepped design (rise, travel, land) felt halting to the user. They proposed one motion instead: grow from the origin toward the tapped tab, arrive large, collapse a little more slowly.
Change
BubbleMotionglide is one gesture.- Travel takes 0–300 ms on
1-(1-x)^4(1+4x): it starts from rest and eases in. - The bubble grows over 0–180 ms, overlapping the travel, so it arrives full size.
- It collapses over 270–500 ms, slower than it grew.
- A redirect continues from the current position and height.
- Travel takes 0–300 ms on
LiquidBubbletap hold.tapHoldUntillasts 700 ms from the finger lifting and is not cleared by stillness.pollPageralso never follows while a glide runs. The drag-commit hold (expect) is unchanged.
Validation
:app:testWhatsappDebugUnitTest: 463 tests, 0 failures. Tests for the continuous-gesture timing and the travel curve are new or rewritten.:app:assembleWhatsappDebugbuilds.- Not device-validated.
🤖 Generated with Claude Code
https://claude.ai/code/session_0157emnK4gGDtGGT282rGFw8
Generated by Claude Code
WaEnhancer Community 0.0.21
WaEnhancer Community 0.0.21
SHA-256: cc7da7f336056d3d07334a7dddaf3ef70571d9eaa2d7aabb3544809e5e240984
Changes since v0.0.20.
What's changed
- #93 fix(glass): tap glides between tabs in a fixed 450 ms; icon stays full size on landing
Full changelog
This section compiles the descriptions of the pull requests included in this release.
#93 — fix(glass): tap glides between tabs in a fixed 450 ms; icon stays full size on landing
Merged by contribution from @igorcv88.
Problem (seventh device recording, animator scale 0.33×)
- A tab tap never travelled. WhatsApp's click jumps the pager to the new page in about one frame. The bubble followed that jump, then swelled and collapsed in place in about 200–270 ms ("explodes and compresses at once").
- A page swipe took about 480 ms visible. The user judged this one right.
- On landing, the selected icon was small and dim for about 100 ms. Two causes:
- the morph scaled the canvas, so the content was about 60% of its size;
- the pill copy was drawn over the icon, because the bubble's Z is above the tab row.
Change
-
BubbleMotionglide. When no finger holds the bubble,animateToruns a deterministic timeline:- rise 0–120 ms;
- travel 120–300 ms, with analytic velocity, so the squash still applies;
- land 300–450 ms.
The timing is fixed and does not follow the animator duration scale, except that scale 0 still snaps; this was agreed with the user. A redirect mid-glide is continuous. A press, a swipe follow or a snap cancels the glide.
-
LiquidBubble.holdPagerFollow().BubbleTouchcalls it on ACTION_UP over a non-selected tab, so the selection report starts the glide instead of the bubble following the pager jump.- The hold ends when the pager rests on a page, or after 700 ms.
setTabsno longer snaps a glide that is already heading to the selected tab.
-
Landing.
- The morph sizes the shape, not its content.
settleScalebrings the spring scale to exactly 1 before the hand-off.drawIconsredraws the tab row inside the pill at the pill copy's opacity.
Validation
:app:testWhatsappDebugUnitTest: 461 tests, 0 failures. Four new tests cover the glide timing, redirect continuity, interruption andsettleScale.:app:assembleWhatsappDebugbuilds.- Not device-validated. Visual change to confirm: during the rise, the bubble's content starts at 1:1 instead of zooming up from about 60%.
Details are in handoff.md and docs/ONEMATE_MATERIAL_2026-10-12.md.
🤖 Generated with Claude Code
https://claude.ai/code/session_0157emnK4gGDtGGT282rGFw8
Generated by Claude Code
WaEnhancer Community 0.0.20
WaEnhancer Community 0.0.20
SHA-256: 03835a5ff9b1c64824927ea0a5b9538d84128f083f745c1a5f520029d7ee29fd
Changes since v0.0.19.
What's changed
- #92 fix(glass): bubble keeps its rise mid-swipe, hides and becomes the native pill
Full changelog
This section compiles the descriptions of the pull requests included in this release.
#92 — fix(glass): bubble keeps its rise mid-swipe, hides and becomes the native pill
Merged by contribution from @igorcv88.
Follow-up to #91. Fixes the defects in the user's fifth device recording and the Codex P2 finding on #91.
| Symptom | Cause | Fix |
|---|---|---|
| Bubble shrinks mid-swipe and re-grows when the finger pauses between pages | "Pager still for 80 ms" ended the follow | A follow ends only when the pager is still and within 0.01 of a whole page (PAGE_SETTLED_EPSILON) |
| Two indicators during motion (Codex P2 on #91) | WhatsApp's pill stayed on the old tab and was recorded in the lens | The bar listener hides the native indicator views (INVISIBLE) while the bubble is visible and shows them once it has shrunk back. The state is re-applied after layouts and restored when the glass host is removed. |
| Light-green flash on landing | The morph wash was the theme accent at 45%, lighter than WhatsApp's dark-green pill | The bubble morphs from and into a mutated copy of the native indicator's background drawable, faded by (1−p)². At zero progress it is the native pill, so the hand-off has no colour jump. The accent wash remains only as a fallback. |
Validation
:app:testWhatsappDebugUnitTest :app:assembleWhatsappDebug: 457 tests, 0 failures.- Not tested on a device. Known approximation: the copied drawable is canvas-scaled, so an absolute corner radius scales with it. This is noted in
handoff.md.
🤖 Generated with Claude Code
https://claude.ai/code/session_0157emnK4gGDtGGT282rGFw8
Generated by Claude Code