Skip to content

[WIP] Version 0.2.1 Release#97

Draft
aahiltn wants to merge 4 commits into
masterfrom
rel/0.2.1
Draft

[WIP] Version 0.2.1 Release#97
aahiltn wants to merge 4 commits into
masterfrom
rel/0.2.1

Conversation

@aahiltn
Copy link
Copy Markdown
Member

@aahiltn aahiltn commented May 7, 2026

Description

Due Diligence

  • I have tested this on a simulator/emulator or a physical device, on iOS and Android (if applicable).
  • I have added sufficient unit/integration tests of my changes.
  • I have adjusted or added new test cases to team test docs, if applicable.
  • I am confident these changes are implemented with feature parity across iOS and Android (if applicable).

Release/Versioning Considerations

  • Patch Contains internal changes or backwards-compatible bug fixes.
  • Minor Contains changes to the public API.
  • Major Contains breaking changes.
  • Contains readme or migration guide changes.
    • If so, please merge to a feature branch so documentation updates only go live upon official release.
  • This is planned work for an upcoming release.
    • If no, author or reviewer should account for this in a release plan, or describe why not below.

Changelog / Code Overview

Test Plan

Related Issues/Tickets

aahiltn and others added 4 commits May 7, 2026 15:55
…[MAGE-551] (#87)

* feat(android): forward Klaviyo silent pushes to Flutter event stream [MAGE-551]

Adds KlaviyoFlutterPushService (open subclass of KlaviyoPushService) that
forwards silent Klaviyo pushes — with or without key_value_pairs — to the
Flutter EventChannel as `{type: 'silent_push_received', data: <RemoteMessage.data>}`,
mirroring the existing iOS handleSilentPush path.

The plugin's manifest auto-registers the service at intent-filter priority 100
so it wins FCM resolution against firebase_messaging's FlutterFirebaseMessagingService.
Hosts that need a custom subclass can opt out via tools:node="remove" — see
README "Silent Push → Android" Option A.

Cold-start case (FCM wakes the app process while Flutter is asleep) is handled
via SilentPushCache, which persists the pending event to SharedPreferences and
replays it on the next engine attach.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

* chore: remove optional client subclassing + override onMessageReceived

* chore: modify manifest logic

switch to including only the priority, and keeping KlaviyoPushService without an explicit removal

* fix: replay all silent push events on flutter engine start

* chore: removes priority in AndroidManifest

* chore: change doc to remove KlaviyoPushService

* fix: clean up SilentPushCache type safety

* chore: kt styling + silent push err handling

---------

Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Several transitive AARs from klaviyo-android-sdk 4.4.0 (notably
androidx.webkit:1.9.0 via the forms module) declare minCompileSdk=34
in their AAR metadata. With the plugin pinned at compileSdkVersion 33,
AGP's library-level CheckAarMetadata fails on host projects using
AGP 8.13+, which now registers the check on library main variants.

Switch the plugin's compileSdk to flutter.compileSdkVersion (the
extension Flutter's plugin loader vends to all plugin projects).
This matches what the host app uses by default, scales forward as
Flutter's default advances, and is the same pattern Flutter's own
first-party plugins (e.g. shared_preferences_android) follow.

Our minimum supported Flutter is 3.24, where flutter.compileSdkVersion
is already 34 — so this satisfies every transitive AAR requirement
without introducing a hard floor of our own. targetSdk and minSdk
are unchanged.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
AGP 8.13.0 added CheckAarMetadata registration for library main
variants (LibraryTaskManager.createCheckAarMetadataTask). On 8.11.x
that check only ran on application modules and androidTest variants,
so AAR-metadata mismatches in plugin dependencies could ship without
the example flagging them.

Bumping the example's AGP brings the library-level check into our own
build path, so future regressions in plugin compileSdk vs. transitive
minCompileSdk requirements surface locally instead of only at consumer
build time.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
fix(android): track flutter.compileSdkVersion in plugin module
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants