Android

1.6.5 — October 30, 2026

Fixed

• An aid passed to initialize with capital letters, such as MyTravelApp, no longer makes the SDK reject its partner configuration with partner_config_aid_mismatch. Before this fix the SDK scheduled no notifications for that app.

1.6.4 — October 13, 2026

Fixed

• Allez links generated by the SDK now put the partner ID first and the destination second when present.

1.6.2 — October 2, 2026

Fixed

• If the SDK fails to report to Stay22 that it showed a notification, it now retries several times, starting each attempt only when the device is online. Before, the SDK could lose that report after one failed attempt, after a few minutes offline, or when your app called Stay22.setTravelContext or Stay22.clearTravelContext before the report went out. The SDK still drops the report if the user opts out after seeing the notification. No change is needed in your app.
• If you set Stay22.testing.baseURL, the SDK's background work now uses it too, for example when it shows a scheduled notification or reports that it could not show one. Before, that work always called Stay22's production server. Apps that do not set it see no change. Set it at app startup, for example in Application.onCreate, so it also applies when Android starts your app only to run that work.

1.6.1 — October 2, 2026

Fixed

• If your app sets its own StrictMode policy, it no longer sees a main-thread network violation when the SDK reports to Stay22 that it could not schedule a notification, for example because the travel context has no usable destination. These reports can come from Stay22.setTravelContext, Stay22.advanced.scheduleNotification or your app moving to the background, and the SDK used to send them on the calling thread. On the main thread, Android's default policy threw NetworkOnMainThreadException; the SDK caught it, so your app kept running, but the report never reached Stay22. Reports raised on the main thread are now sent from a background thread. No change is needed in your app.

1.6.0 — October 1, 2026

Added

• Support can inspect a recent notification decision and posting history from device logs when testing your app, without adding logging code to your integration.

1.5.0 — September 28, 2026

Added

• Stay22.advanced.setErrorListener(listener) and setErrorHandler { error -> ... } report SDK failures to your app as a Stay22Error, so you can forward them into the crash reporter you already use and see at a glance when a problem is Stay22's rather than yours. The SDK bundles no crash reporter of its own, which would fight yours for the same handlers. Callbacks arrive on the main thread.
• Errors raised before your app registers an error listener are held and delivered as soon as it does, so a partner configuration that fails during initialize still reaches you. A listener you remove on the main thread is not called again, even for an error already on its way.
• SDK errors are now written to Logcat at error level under the Stay22 tag whether or not Stay22.testing.showLogs is on. Failures in the SDK's own background work, previously visible only with that flag on, are now reported the same way and through setErrorListener.
• An unexpected failure in a call into the SDK, or in its own foreground and background handling, is caught instead of crashing your app. Calls return a safe value; in both cases the SDK logs the problem and reports it through setErrorListener and Stay22.diagnostics. A blank aid passed to initialize still fails fast, because that is an integration mistake rather than a device problem.
• After Stay22.initialize, Stay22.isEnabled now answers false, rather than true, when reading the stored setting fails. An app using com.stay22.sdk.RequiresConsent could previously be told the SDK was enabled on a device whose preference store had become unreadable. Before initialize there is no stored setting to read and Stay22.isEnabled still answers true; a consent-gated app should call Stay22.readEnabled(application) there instead.

1.4.0 — September 25, 2026

Added

• Built-in notification text now follows the device's French or English language when a notification is scheduled. Custom notification text is unchanged.
• Apps that set com.stay22.sdk.RequiresConsent in AndroidManifest.xml keep the SDK disabled until they explicitly enable it after consent.
• Stay22.setEnabled(application, enabled) and Stay22.readEnabled(application) let Android apps save and read the SDK enabled setting before initialization.

Fixed

• Calling Stay22.setEnabled(application, false) or Stay22.clearTravelContext() now prevents a scheduled Stay22 notification from appearing and removes one already displayed on Android.

1.3.0 — September 22, 2026

Added

• Stay22.advanced.noteCurrentActivity(activity) for hosts that start the SDK after the current screen is already in front. Without it, a permission prompt in that same session has no Activity to launch from.

Changed

• The SDK now supports Android 7.0 (API 24). It previously required Android 8.0 (API 26).

Fixed

• Tapping a notification after the app was killed now delivers the click event when the SDK starts again, matching shown and blocked events.

1.2.0 — September 8, 2026

Changed

• Documented that the SDK installs no cookie handler. Stay22's responses set a session22 cookie carrying the same session id the SDK already sends as a parameter. Android's HttpURLConnection defers to the process-wide CookieHandler.getDefault(), which is your app's to set, so the SDK cannot opt out per connection the way the iOS SDK now does and will not install one on your behalf. If your app has a cookie handler it will keep that cookie; the SDK never reads it either way.

Documentation

• Event handling now documents, and the sample now demonstrates, that a when over Stay22Event needs an else branch. The sealed class ships in a separately compiled binary, so a when covering only today's subclasses throws NoWhenBranchMatchedException once a new event is added. Matches the iOS change.

Fixed

• Partner config is now fetched from /ext/partner/settings instead of /ext/partner. The old path is blocked by an unrestricted rule on AdGuard's spyware filter list, so on a device running a system-wide URL filter the SDK never received its config, never scheduled a notification, and retried on every foreground forever. /ext/partner/settings was added for exactly this reason and the web moved to it in April; both paths are registered to the same handler and return the same payload.

1.1.0 — August 31, 2026

Added

• Integration self-check via Stay22.diagnostics, reporting each prerequisite as pass/warn/fail with the remedy for anything that fails.
• Stay22.requestNotificationPermission { granted -> }, which reports the user's actual answer. The existing no-argument overload returns the state before the prompt is answered and is now documented as such.
• Stay22.advanced.scheduleNotification(force:) for verifying an integration without waiting out the normal delay. Defaults to false and never bypasses partner settings.

Changed

• Android and iOS now share a version number.

Fixed

• A transient failure no longer loses that trip's notification permanently.
• Repeated travel-context updates no longer defer a notification indefinitely.
• A notification can no longer be delivered twice after an interrupted network call.
• Notification events raised while the app is not running now reach the host app on next launch.
• The SDK can no longer crash the host app on unexpected internal errors, or in apps with a custom background-work setup.
• Release builds no longer strip classes the SDK needs; minified builds are covered by CI.
• Notification permission is no longer requested when the system cannot show a prompt.

Documentation

• Device-context detection now lists every app checked, with an opt-out.

1.0.13 — August 21, 2026

Added

• Notification impression reporting when a Stay22 notification is displayed.
• A notification_channel_blocked skip reason, so a blocked channel is distinguishable from a missing runtime permission.

Changed

• SDK activity reporting now includes the installed SDK version for release-level diagnostics.

Fixed

• Treat a blocked notification channel as unavailable. Notifications are no longer scheduled or posted when the user has turned off the destination-suggestions channel while leaving notifications enabled for the app.

1.0.12 — July 16, 2026

Fixed

• The locally built fallback notification link now applies device-context provider exclusions, matching the link the server builds.

Changed

• Aligned the notification link and failure-event source to direct.

1.0.11 — July 2, 2026

Fixed

• Retry loading partner configuration when the app returns to the foreground, so a failed or interrupted initial fetch no longer blocks notifications for the rest of the session.

1.0.10 — July 2, 2026

Changed

• Notification frequency is now recorded when a notification is shown instead of on the next app launch, so suppression windows start on time and undelivered notifications never count as shown.
• Travel context is cleared once its notification is shown; set travel context again to schedule the next one.

1.0.9 — July 2, 2026

Fixed

• A scheduled notification that never appears (for example when the system cancels or defers the background work) is no longer recorded as shown. This prevents an undelivered notification from starting the post-notification cooldown and suppressing later notifications.

1.0.8 — June 30, 2026

Added

• Initial binary distribution of the Stay22 Android SDK (.aar) via a Maven repository.

Full release notes and downloads: Android releases