Bump googleapis/release-please-action from 4 to 5 - #10
Closed
dependabot[bot] wants to merge 25 commits into
Closed
Conversation
Privacy-first, FOSS document scanner built with Flutter. Captures pages via camera, compiles them into a PDF, and shares it — all on-device, with no persistent storage of scanned content and no backend of its own.
Replaces the default Flutter logo with a document/scan-beam icon matching the app's Material 3 deepPurple theme. Generated via flutter_launcher_icons across Android (including a proper adaptive icon), iOS, web, Windows, and macOS from a single source image in assets/icon/. Also fills in the web manifest/index.html branding (name, description, theme color), which were still Flutter's generic placeholders.
Replaces the plain photo-to-PDF flow with a proper scanner pipeline: detect the document's corners in the captured photo, let the user drag them into place, then perspective-correct (dewarp) into a clean, upright page before it goes into the PDF. - opencv_dart (native OpenCV bindings) powers detection (Canny -> contour search -> approxPolyDP epsilon sweep) and the perspective warp (getPerspectiveTransform/warpPerspective). Everything stays in-memory (bytes in, bytes out via imdecode/imencode) - no temp files. - New CornerAdjustScreen + CornerOverlay give a fully custom, on-brand draggable-corner UI rather than handing off to a third-party plugin's own screen. - No web support (opencv_dart is FFI-based): gated behind a document_processor_native.dart / document_processor_web.dart conditional export, so web keeps working via a pass-through stub. - Split the old single-file lib/main.dart into models/services/screens/ widgets. ScannedPage replaces the bare XFile list. - Dockerfile now installs cmake/build-essential, required by opencv_dart's native build hooks at `pub get` time. Known tradeoff: release APK grew from ~49.5MB to ~83.6MB from the bundled OpenCV native libs. --split-per-abi and module trimming are candidates for a later pass. See /home/lor/.claude/plans/precious-stargazing-charm.md for the full phased plan (filters and re-edit support are next).
Filters (Phase 2 of the scanning plan): - applyFilter now does real work: grayscale via cvtColor, black-and-white via grayscale + adaptiveThreshold (the classic crisp "scanned page" look), auto-enhance via CLAHE on the L channel in Lab space. - CornerAdjustScreen gets a filter chip row (Original/Enhance/Gray/B&W) with live thumbnail previews, generated on corner-drag-end (not every frame) via a new CornerOverlay.onChangeEnd callback, and cached/reused at confirm time instead of recomputed. Crash fix: "the app just closes when I take a photo" traced to a native double-free in detectCorners. findContours() returns a VecVecPoint whose individual contour elements are views into the parent's buffer, not independent allocations - disposing them one-by-one corrupts the heap and crashes later (SEGV_MAPERR in __libc_free), reproducing reliably on realistic multi-megapixel photos but not on the small synthetic image used during earlier development. Fixed by disposing the container itself. Also fixed a smaller getStructuringElement kernel leak in the same function. Full bisection notes and the (reverted, red-herring) isolate theory are in CLAUDE.md.
- Tapping a page thumbnail (distinct from the delete button) reopens
CornerAdjustScreen pre-populated with its saved corners/filter, and
replaces the entry on confirm. No-op on web (nothing to edit there).
- CornerAdjustScreen now adapts its title/button wording when reused for
editing ("Edit page"/"Cancel") vs. a fresh capture ("Adjust
corners"/"Retake").
- Update README/CHANGELOG now that all three planned phases (detect+warp,
filters, re-edit) are done.
CornerOverlay called onChanged on every pointer-move during a drag, which made CornerAdjustScreen setState (and rebuild the full-size photo, filter preview row, and buttons) 60+ times a second for a single corner drag — visibly stuttering and making precise placement hard. CornerOverlay now owns the live drag position as local state and only calls onChanged once, when the drag ends. The parent screen (and the expensive preview regeneration it triggers) only updates once per drag instead of continuously. Also wrapped the displayed photo in a RepaintBoundary so its paint layer doesn't get touched by the quad/handles repainting during a drag.
Root cause was in _generateAndSharePdf, not the crop: pages used a fixed PdfPageFormat.a4, which has a hard-coded ~2cm margin baked into the format itself, and the scanned image (whatever aspect ratio the real document happens to be) was centered inside it with BoxFit.contain - letterboxing it whenever it didn't match A4's proportions exactly, which is most of the time. The corner selection itself was already correct. Each page is now sized to match its own image's aspect ratio (derived from pw.MemoryImage's width/height at an assumed 150 DPI, just to keep the physical page size reasonable) with margin: pw.EdgeInsets.zero.
…bnail Split CornerAdjustScreen into two steps: adjust corners on the raw photo (as before), then a dedicated preview step showing the actual warped+filtered result full-size. Tapping a filter chip swaps which cached preview is shown, so what you see is exactly what Confirm saves, instead of only the small 56x56 chip reflecting the choice.
Feature/scan filters
Picked up by flutter pub get; the previously-locked 2.2.1+4 native build cache no longer matches the fetched dartcv4 source, so building against the old lock fails with a CMake source-mismatch error.
Bump opencv_dart to 2.2.2 (pubspec.lock)
Universal release APKs ballooned to ~83MB after adding opencv_dart (bundled native libs for every ABI). Building with --split-per-abi instead produces one APK per ABI, so a real device only downloads the ~28MB it actually needs. Applied to both the release GitHub Actions workflow and the local Docker build-apk service. Also bumps the app version and moves the changelog's Unreleased entries under 1.1.0 ahead of tagging the release.
…ADME Rename the Android package from the placeholder com.example.fosscanner to com.fosscanner.app (namespace, applicationId, and the Kotlin source path). Release builds now sign with a real upload keystore instead of the debug one, read from android/key.properties (gitignored) locally and reconstituted from repo secrets in the release workflow, falling back to debug signing when no keystore is configured so local/CI analyze+test still work with zero secrets. Also rewrites the README with badges and a direct-download button pointing at GitHub Releases, and documents both changes plus a real, unresolved blocker for an eventual F-Droid submission (opencv_dart fetches OpenCV source over the network mid-build, which F-Droid's sandboxed builders don't allow).
Release/prep public
Captured from a real run of the web build (Playwright + headless Chromium against the Docker-served release build) rather than mocked up: the empty "Ready to Scan" state, and the page list after adding a few captures. Web skips the corner-adjustment/filter screens entirely (no OpenCV there), so the README caption says so rather than implying these show the full native flow.
Add screenshots and a direct-download badge to the README
The APK build itself succeeded this run; softprops/action-gh-release then failed with 403 "Resource not accessible by integration" trying to create the release. The default GITHUB_TOKEN for this repo/org is read-only unless a workflow explicitly requests more, so grant the job contents:write permission.
Grant contents:write to the release workflow
The org's Actions settings lock default GITHUB_TOKEN permissions to read-only for this repo, with no repo-level override available (the "Read and write permissions" radio is disabled in the repo's own settings) — so the contents:write job permission added in the previous commit isn't sufficient by itself. Point action-gh-release at a RELEASE_TOKEN secret (a fine-grained PAT scoped to just this repo, Contents: Read and write) instead.
Use a repo-scoped PAT for the release token
CONTRIBUTING.md documents the dev workflow and the Conventional Commits convention the new Release Please automation (next commit) depends on. SECURITY.md points reporters at GitHub's private vulnerability reporting instead of public issues. Structured issue forms ask for platform/Flutter version up front, since so much of this app's bug surface is native-only. Dependabot watches both pub and GitHub Actions dependencies weekly.
release-please.yml runs on every push to main, keeping an up-to-date "chore: release X.Y.Z" PR whose version bump and CHANGELOG.md entry are computed from Conventional Commits since the last release. Nothing publishes from a normal merge — merging that specific PR is what creates the tag/release, which release.yml then builds signed split-APKs for and attaches. Uses the same RELEASE_TOKEN PAT as release.yml, since the org's default GITHUB_TOKEN is read-only here with no repo-level override. release.yml no longer sets generate_release_notes, since the release it's attaching files to was already created by release-please with better, changelog-based notes.
Title, short/full description, and a 512x512 icon under the standard fastlane/metadata/android/en-US/ layout F-Droid (and Play Store tooling) both read. This is prep only, not a submission — the real blocker (opencv_dart fetches OpenCV source over the network mid-build, which F-Droid's sandboxed builders disallow) is still unresolved and documented in CLAUDE.md's "F-Droid readiness" section.
Chore/repo tooling
Bumps [googleapis/release-please-action](https://github.com/googleapis/release-please-action) from 4 to 5. - [Release notes](https://github.com/googleapis/release-please-action/releases) - [Changelog](https://github.com/googleapis/release-please-action/blob/main/CHANGELOG.md) - [Commits](googleapis/release-please-action@v4...v5) --- updated-dependencies: - dependency-name: googleapis/release-please-action dependency-version: '5' dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <support@github.com>
dependabot
Bot
added
dependencies
Author
|
OK, I won't notify you again about this release, but will get in touch when a new version is available. If you'd rather skip all updates until the next major or minor version, let me know by commenting If you change your mind, just re-open this PR and I'll resolve any conflicts on it. |
dependabot
Bot
deleted the
dependabot/github_actions/googleapis/release-please-action-5
branch
August 22, 2026 19:54
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
1 participant
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 googleapis/release-please-action from 4 to 5.
Release notes
Sourced from googleapis/release-please-action's releases.
... (truncated)
Changelog
Sourced from googleapis/release-please-action's changelog.
... (truncated)
Commits
45996edchore(main): release 5.0.0 (#1200)a8121b9chore: build dist (#1201)f533c26fix: bump release-please from 17.3.0 to 17.6.0 (#1199)46dfc01feat!: upgrade to node24 (#1188)Dependabot 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 this major versionwill close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this minor versionwill close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this dependencywill close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)