Repository navigation
chore(deps): bump the android-gradle-plugin group in /android with 2 updates - #635
Closed
dependabot[bot] wants to merge 1 commit into
Closed
dependabot[bot] wants to merge 1 commit into
dependabot[bot] wants to merge 1 commit into
Conversation
Bumps the android-gradle-plugin group in /android with 2 updates: com.android.application and com.android.test. Updates `com.android.application` from 9.4.1 to 9.5.0 Updates `com.android.test` from 9.4.1 to 9.5.0 --- updated-dependencies: - dependency-name: com.android.application dependency-version: 9.5.0 dependency-type: direct:production update-type: version-update:semver-minor dependency-group: android-gradle-plugin - dependency-name: com.android.test dependency-version: 9.5.0 dependency-type: direct:production update-type: version-update:semver-minor dependency-group: android-gradle-plugin ... Signed-off-by: dependabot[bot] <support@github.com>
Contributor
Author
LabelsThe following labels could not be found: Please fix the above issues or remove invalid values from |
|
Important Review skippedBot user detected. To trigger a single review, invoke the
 |
Antigravity review (Gemini via Ultra)Bumps the Blocking issuesNone found. Suggestions
Nitpicks
Automated first-pass review by |
doublegate
added a commit
that referenced
this pull request
Nov 5, 2026
* build(deps): every ecosystem at its newest compatible release One consolidated change for v3.6.1 in place of the seven open Dependabot PRs (#627, #629, #632, #633, #635, #636, #637), widened past what they carried to every manifest in the repository. Cargo (workspace): `cargo upgrade --incompatible` found five requirements behind; all five moved. rmcp 3.5.1 -> 3.8.0 (rustynes-mcp), rusqlite 0.40 -> 0.41 (script-sqlite, still `bundled`), toml 1.1 -> 1.2, and the wasm-bindgen family 0.2.129 -> 0.2.130 with js-sys / web-sys 0.3.107 and wasm-bindgen-futures 0.4.80. The Trunk.toml wasm-bindgen CLI pin moved to 0.2.130 in the same change: a mismatch with the locked library fails `trunk build` and the Pages deploy while wasm clippy still passes. The mobile bridge's `getrandom` moved 0.2 -> 0.4; its only call, `getrandom::getrandom`, is `getrandom::fill` there. `cargo update` then refreshed the lock (tokio 1.54.1, zip 9.3.0, ureq 3.5.1, uuid 1.29, the icu 2.4 family and others). Deliberately not moved: the frontend's two optional getrandom shims (0.2 `js`, 0.3 `wasm_js`) behind `script-wasm`. They exist only to select a browser backend for the majors piccolo's own tree (rand, ahash) pulls, so moving them to 0.4 would add a third getrandom and select nothing. The excluded workspaces were refreshed too: fuzz/ (7 lock lines; its lock is gitignored), rustynes-cosim (nothing to move), enhanced-validator (nothing). Android: AGP 9.4.1 -> 9.5.0 (application + test plugins, as one group), the Gradle wrapper 9.8.1 -> 9.8.2 (distribution URL and checksum, taken from Dependabot's branch), play-services-cast-framework 22.3.1 -> 23.0.0. #627 also rewrote every line of gradlew.bat; that was CRLF only. Normalised to LF (the mixed-line-ending hook's `--fix=lf`), it is byte-identical to the 9.8.1 file, so it is not in this commit. Dependabot's gradle limit is 5 and 4 PRs were open, so it was not capped and nothing else on that side is behind. Not built locally (no Android SDK here); the android workflow builds it on the PR. Hosted services: wrangler 4.151.1 -> 4.157.0, vitest 5.0.5 -> 5.1.0, @cloudflare/vitest-plugin 1.4.4 -> 1.5.1, workers-types 5.20261104.1, all still exact pins. undici (#636's security group) resolves to 7.30.1 through miniflare. `npm audit`: 0 vulnerabilities. CI: taiki-e/install-action v2.88.1 (ci, feature-powerset, security), gradle/actions/setup-gradle v6.4.1 (android, ci). Pre-commit: markdownlint-cli v0.49.1 -> v0.50.0, ruff v0.17.1 -> v0.17.3, shellcheck-py v0.11.0.1 -> v0.11.0.1-1. A linter that gains a rule turns unchanged documents red (v0.39 -> v0.49 brought MD060 and 1,936 findings), so each was run over the whole corpus before the pin moved: markdownlint, ruff check and shellcheck all pass with no file changed. Found on the way: `cargo clippy -p rustynes-script --all-targets --features script-sqlite -- -D warnings` fails on clippy 1.99's assert_is_empty in userdata_sqlite.rs's test. CI runs those tests but never lints them with that feature, so it was never reported. Fixed by asserting equality with an empty Vec, which also prints the rows on failure. Checked: cargo fmt; clippy -D warnings for the workspace, frontend `full` and `retroachievements`, rustynes-script with script-sqlite + script-ipc, and all three wasm32 frontend builds (default, wasm-canvas, script-wasm); the thumbv7em no_std core build; rustynes-script tests 80 passed; cargo deny check; trunk build --release; services/hosted `npm run check` (tsc + 132 vitest tests passed). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014qfTKi2M3swo7qnwvYCkDj * fix(tastudio): bound a project's decoded size, not only its file size T-TAS-PROJECT-DECODE-BOUND (CodeRabbit on #630). v3.5.1 capped a .rnmproj at 1 GiB on read and write (bounded_read::MAX_TAS_PROJECT), but the file is not what TasEditor::load_rnmproj allocates. A version-2 frame is a 5-byte record on disk and a whole FrameInput in memory (four pads, the expansion byte, an Option<ExtraInput>), and every branch carries its own copy of the input log plus its own markers. So a valid project near the file cap could decode to several GiB. Not a regression: before v3.5.1 the file was read unbounded. The existing per-Vec guards (with_capacity capped by remaining bytes) stop a single lying count from reserving more than the blob could hold; they do not stop an honest-looking blob from expanding. What changed: - Reader carries a decoded-bytes budget (RNMPROJ_DECODE_BUDGET, 1 GiB) and charges it from each declared count BEFORE the records are read: a version-2 log's own frame count (the first u32 of its encode_log blob, peeked before decode_log builds anything), a version-1 log's count, each marker list's count (usize key + String header per marker) and each label's length. The charge accumulates across the main log and every branch, and saturates rather than overflowing. - Over budget is RnmProjError::DecodeBudget { needed, budget }, raised from the counts alone. load_rnmproj still commits nothing on any error. - load_rnmproj_within(bytes, budget) is the private seam the tests use to reach the refusal without gigabyte fixtures. Sizing: at size_of::<FrameInput>() per frame, 1 GiB holds tens of millions of frames across all branches, more than a hundred hours at 60 fps, so no real project is refused. Tests (both new, 44 tastudio tests pass): - rnmproj_counts_past_the_decode_budget_are_refused_before_decoding: a version-2 log claiming u32::MAX frames and carrying none. Without the budget it reaches decode_log and is refused as BadInputLog; with it the refusal is DecodeBudget, which only the count can raise, so the variant shows the order. The same for a u32::MAX marker count. Editor unmutated. - rnmproj_decode_budget_counts_every_branch: 1,000 frames and three branches (4,000 decoded frames plus four copies of one marker). A budget one frame short is refused, though no single log comes near it; the exact budget loads and re-serialises byte for byte; a 1,000,000-frame project opens under the shipped budget. Mutation-checked: dropping the version-2 count charge fails both tests (the first gets BadInputLog, the second loads past the short budget); making the budget per-log instead of cumulative fails the second. docs/creator-tools.md states both bounds. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014qfTKi2M3swo7qnwvYCkDj * fix(mmc5): end the fetch window with rendering; the split's pre-render row T-MMC5-WINDOW-END (CodeRabbit on #630), and an oracle defect the MiSTer sibling's new stimulus found on the way. 1. The background-fetch window (`render_window`) ended only at `notify_vblank`. Since v3.5.1 the split's bank and an extended attribute's bank apply only inside it with rendering on, so: - on post-render line 240, rendering on and nothing fetched, a $2007 CHR read still took the split's bank; - a $2002 read on the race dot suppresses the VBL flag and the NMI, and `Ppu` also skipped `bus.notify_vblank()` then, because the call sat inside the flag's branch: the window stayed open through that blank. `Mmc5::notify_cpu_cycle` now also closes the window on the in-frame flag's idle rule (three M2 cycles with no PPU read, the page's own end-of-frame signal, a few dots into line 240), but only while `ppu_rendering`: an idle run that a $2001 disable caused leaves it, so a mid-frame re-enable fetches with the same CHR set as before. And the PPU calls `notify_vblank` at the vertical-blank dot on every frame, independent of the CPU-visible flag. The MMC5 is the only implementer. 2. `Ppu::fetch_nt` passes the MMC5 split the scanline of the fetch, and meant to pass 0 for the pre-render line, whose last two fetch groups are line 0's first two tiles. It tested `self.scanline < 0`, which never holds: `scanline` counts the pre-render line as the region's last (`PpuRegion::prerender_line`, 261 / 311). So those tiles took row ($5201 + 261) % 240 (or + 311). It now compares with `prerender_line()`. The page's v-split counter "resets to the vertical scrolling value in $5201 each v-blank". docs/ppu-2c02.md's own interface sketch said the pre-render line was -1; corrected. How it was found: the sibling's `mapper5window491` frame gate differed from this oracle at line 0 only (4 pixels, x 1-2 and 9-10), and the DUT's line 0 matched its own line 1, as a row-4 tile at $5201 = $23 must on both lines. Decoding the oracle's pixels (CHR-RAM there labels each 1 KiB bank and tile) gave tile $C1 in bank 7: ExRAM row 7, which is (35 + 261) % 240 = 56 -> row 7. Tests, each mutation-checked (the mutant fails it): - `line_240_closes_the_fetch_window_with_rendering_on` (mappers): two idle cycles keep the window, the third closes it, and a $2007 read then gets the A set; the split's bank likewise. Mutant: no idle close. - `an_idle_run_with_rendering_off_keeps_the_fetch_window`: mutant: close regardless of `ppu_rendering`. - `vblank_reaches_the_mapper_when_a_status_read_suppresses_the_flag` (ppu): a dot-0 $2002 read still yields one notification, and the flag stays suppressed. Mutant: the old `!suppress_vbl_this_frame` gate. - `the_pre_render_lines_split_queries_pass_scanline_zero` (ppu), NTSC, PAL and Dendy, and line 1 passes 1. Mutant: `scanline < 0`. The epoch is unchanged (8). The whole of `cargo test --workspace --features test-roms,commercial-roms` passes 4,048 / 0 / 20 (v3.6.0's cut: 4,030 / 0 / 20), with the 1,116-dump boot coverage and every commercial snapshot, Uchuu Keibitai SDF (the one commercial split user) included: no committed frame, sample or golden moved. A game that reads CHR through $2007 on line 240, or splits the first two columns with $5201 set, now behaves differently; none is in the corpus. Provenance: ppu.rs carries a header for the sprite-evaluation, OAM-decay and ALE regions; `fetch_nt`'s split query is none of them. Docs: docs/mappers.md (where the window ends; the split's pre-render row), docs/ppu-2c02.md (the scanline range; the every-frame notice), CHANGELOG (with the two MiSTer entries, sibling efaf14a / b6a62ac), ROADMAP (three tickets DONE), and to-dos/plans/v3.6.1-plan.md, this release's plan. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014qfTKi2M3swo7qnwvYCkDj * chore(release): cut v3.6.1 "Threshold"; emulation epoch 9 The version bump, the anchors, the epoch and the release notes for v3.6.1, a patch release on v3.6.0 "Octave": the dependency sweep (06654d2), the TAStudio decode bound (884b1f4), the MMC5 window end and the split's pre-render row (875e824), and the MiSTer core's region-tied save states and PAL / Dendy MMC5 (sibling efaf14a, b6a62ac). The codename "Threshold" is PROVISIONAL: the maintainer chooses codenames at the cut, and the cut was made at 03:00 without asking (the instruction was to work the release through). It names the release's subject, the edges of things: where the MMC5's fetch window ends, a frame's first line, the region boundary a save state may not cross. Checked unused as a quoted codename in CHANGELOG.md. Renaming it is the CHANGELOG header, the notes' title, the VERSION-PLAN row, the ROADMAP sentence and the anchors bump_release.py wrote. EMULATION_EPOCH 8 -> 9. 875e824 said the epoch stays 8, because no golden, snapshot or fingerprint moved (the full test-roms + commercial suite passes 4,048 / 0 / 20, Uchuu Keibitai SDF, the one commercial split user, included). That was the wrong reading of the rule, which is "anything that alters a frame, a sample or a bus cycle against the last release", not "anything the corpus happens to observe": the split-row fix changes the frame of any game that splits the first two columns with $5201 set, and the window end changes what a $2007 CHR read on line 240 returns. v3.5.1 raised epoch 7 by the maintainer's call for exactly that shape (no recorded output moved, a bus value did). The table row in hardware_options.rs says so; the fingerprint table was re-blessed and only its `# epoch` line changed (every row identical); `last_release_epoch` stays 8, the last release's. The plan's record is corrected beside the original sentence rather than replacing it. bump_release.py --apply moved every anchor it owns (Cargo.toml and both lockfiles, the cosim crate, the libretro .info, Android's versionCode, the iOS project, the hosted Worker's package files, and the prose anchors in AGENTS, ARCHITECTURE, OVERVIEW, README, ROADMAP, SECURITY, SUPPORT and STATUS). Its first dry run refused, rightly: the ROADMAP release-line chain ended "v3.6.0, the current release", owed a written v3.6.1 clause, which is added. And the first --apply doubled the lead: I passed a --lead that began with the version and date the anchors already print, giving `v3.6.1 "Threshold" (2026-11-05) -- v3.6.1 "Threshold" (2026-11-05) -- every...` in eight files; the duplicated prefix was removed and the anchors re-checked. By hand: the CHANGELOG [3.6.1] header and its Breaking section (the [Unreleased] heading kept, empty), the VERSION-PLAN row, .github/release-notes/v3.6.1.md. Two traps recorded in docs/agents/: markdownlint-cli 0.50.0 reads a bare `$` in prose as inline math, which shifts every later code span on the line (found writing 875e824's docs); and a hand-run RTL mutant whose build fails silently reruns the old binary and reads as NOT CAUGHT (found in the sibling's region save-state work). Checked: the release audits (anchors 14, state prose 6, notes render 18, contribution checklist 4, libretro .info 9: 51 passed); `cargo test --workspace` 3,430 passed under epoch 9; `epoch_fingerprint` 2 passed after the re-bless; the skill's pre-release checker clean (notes reflowed, 1,345 words, both repos' commits covered); markdownlint on every changed document. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014qfTKi2M3swo7qnwvYCkDj * fix(tastudio, mmc5): charge every decoded allocation; save what loads Review round 1 on #639 (Copilot 4, CodeRabbit 6 inline + 1 outside the diff + 1 additional). Each finding checked against the code first. TAStudio decode budget, rebuilt as a pre-pass (Copilot x3, CodeRabbit x2). 884b1f4 charged frame and marker counts inside the decoders. The review found what that missed, and each was confirmed by reading the code: - branches were never charged (Copilot): a version-1 project of 20 M empty branches charged nothing while its branch vector alone passed 1 GiB; - branch states were copied uncharged (Copilot); - a version-2 log's blob was copied (`self.bytes()`) before its count was charged (CodeRabbit), and the decoder's per-frame Option<ExtraInput> vector, live beside the frames, was uncharged (CodeRabbit); - the INPUT EVENTS list was uncharged (Copilot). Its reservation is bounded by the block's bytes (`remaining / MIN_EVENT_LEN`), so the claim of "multiple GiB from a declared u32::MAX" overstates it; the real gap is the expansion of each 5-byte event into a decoded tuple. Now `rnmproj_decoded_cost_within(bytes, budget)` walks the whole file first, allocating nothing, and charges every log through a new core function, `FrameInput::decode_log_cost` (frames x (FrameInput + Option<ExtraInput>), plus the event list from the block's declared count bounded as the decoder bounds it), every marker (key + String + label bytes), and each branch's own `Branch` and its state bytes. The load runs it before decoding anything; the version-2 decoder now borrows the log slice instead of copying it. The cost belongs in the core because the core owns the log format and the decoder's allocations. Saving refuses what loading would (Copilot): `App::save_tas_project` runs the same pre-pass on the bytes it is about to write and refuses, on screen, before the file dialog, so a project the app cannot reopen never replaces a loadable one. Tests: `rnmproj_decode_budget_counts_every_branch` now asserts the pre-pass's cost EXACTLY (4,000 frames x per-frame cost + four marker maps + three Branch structs + three state lengths), refuses at cost - 1, loads at cost; new `rnmproj_empty_branches_are_charged` (1,000 empty branches, version 1), `rnmproj_input_events_are_charged` (zero frames, u32::MAX events over 50,000 bytes), `rnmproj_save_and_load_share_the_budget`. Mutants, each CAUGHT: no branch charge (2 tests), no event charge, no Option<ExtraInput> in the per-frame cost, no pre-pass in the load (4 tests). 47 tastudio tests pass; core movie tests 77 pass; the thumbv7em no_std core builds. MMC5, a corner in 875e824's rule (CodeRabbit, marked unverified; the reading below confirms it). The window's idle close is gated on rendering, so a long rendering-off run saturates `det_idle_cycles` at 3 with the window kept open. Re-enabled on post-render line 240, where nothing is fetched, the count could never reach 3 again and the window stayed open to vertical blank. The off-to-on $2001 transition now restarts the count; in-frame is already clear and the matcher was reset by the disable, so nothing else the count drives can change. New test `a_re_enable_without_fetches_still_closes_the_fetch_window`; mutant (no restart): CAUGHT. 90 MMC5 tests pass. The MiSTer core mirrors it (sibling #72), and re-exporting the MMC5 stems' goldens with this oracle moves nothing but the manifests' version line. Epoch (Copilot): `last_release_epoch` 8 -> 9 at the cut, as the table's own header requires, so a later release cannot move output under the already-shipped 9. `epoch_fingerprint` 2 passed. Docs (CodeRabbit): AGENTS.md named markdownlint-cli v0.49.1 (now v0.50.0 with the history kept); the Gradle checksum comment named 9.8.1's file, and the 9.8.2 checksum was verified against services.gradle.org before the comment changed (21bd5da2...); my own trap bullet carried the bare `$5201` it warns about (escaped); to-dos/ROADMAP.md's release chain said the epoch stayed 8 (it is 9); SECURITY.md's table still made 3.5.x the current line (3.6.x now; 3.5.x partial). CHANGELOG and the notes describe the wider budget, the save check and the re-enable restart. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014qfTKi2M3swo7qnwvYCkDj * ci: lint rustynes-script's tests with script-sqlite and script-ipc Antigravity on #639. `cargo clippy -p rustynes-frontend --all-targets --features full` lints the frontend's own test targets; rustynes-script is compiled as a library dependency there, so its #[cfg(test)] modules with script-sqlite were never linted. The v3.6.1 dependency sweep ran `cargo clippy -p rustynes-script --all-targets --features script-sqlite,script-ipc -- -D warnings` by hand and found a real failure (clippy 1.99's assert_is_empty, fixed in 06654d2); this makes CI run it. The suggested `--features scripting,script-sqlite` would not resolve: `scripting` is the frontend's feature, and rustynes-script's are mlua-backend (default), script-wasm, script-ipc and script-sqlite. Checked: the command passes locally on this tree; actionlint clean. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014qfTKi2M3swo7qnwvYCkDj * fix(tastudio): show a refused project in the status bar; charge before slicing Antigravity's second round on #639 (no blocking issues; it reviewed f41d68c, so its CI-step suggestion is 3c74b20, already pushed). - A refused load was reported on stderr only. The v3.6.1 notes say a project over the decode budget "is refused with a message", and a desktop launch has no terminal, so a GUI user saw nothing happen. `App::load_tas_project` now puts both refusals, the bounded read's and the parse's (malformed, or past `RNMPROJ_DECODE_BUDGET`), in the status bar as errors, as the save path has since 35f81aa, and still logs them. - The pre-pass charged a marker label's and a branch state's declared length after slicing it, so an oversized declared length in a truncated file came back `Truncated` instead of `DecodeBudget`. Charge first, as `cost_input_log` already did. Neither order allocates; the change is in which refusal a hostile file gets. - `Reader`'s `charged` / `budget` are documented as the pre-pass's: the decoders run after it has passed and charge nothing. Checked: tastudio tests 47 passed; clippy -D warnings for the frontend's default and `full` feature sets; fmt. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014qfTKi2M3swo7qnwvYCkDj --------- Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
Owner
Contributor
Author
|
This pull request was built based on a group rule. Closing it will not ignore any of these versions in future pull requests. To ignore these dependencies, configure ignore rules in dependabot.yml |
dependabot
Bot
deleted the
dependabot/gradle/android/android-gradle-plugin-db31d912e9
branch
November 5, 2026 09:52
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Bumps the android-gradle-plugin group in /android with 2 updates: com.android.application and com.android.test.
Updates
com.android.applicationfrom 9.4.1 to 9.5.0Updates
com.android.testfrom 9.4.1 to 9.5.0Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting
@dependabot rebase.Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR:
@dependabot rebasewill rebase this PR@dependabot recreatewill recreate this PR, overwriting any edits that have been made to it@dependabot show <dependency name> ignore conditionswill show all of the ignore conditions of the specified dependency@dependabot ignore <dependency name> major versionwill close this group update PR and stop Dependabot creating any more for the specific dependency's major version (unless you unignore this specific dependency's major version or upgrade to it yourself)@dependabot ignore <dependency name> minor versionwill close this group update PR and stop Dependabot creating any more for the specific dependency's minor version (unless you unignore this specific dependency's minor version or upgrade to it yourself)@dependabot ignore <dependency name>will close this group update PR and stop Dependabot creating any more for the specific dependency (unless you unignore this specific dependency or upgrade to it yourself)@dependabot unignore <dependency name>will remove all of the ignore conditions of the specified dependency@dependabot unignore <dependency name> <ignore condition>will remove the ignore condition of the specified dependency and ignore conditions