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.
Add support to build on SDK 37 #6590
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: develop
Are you sure you want to change the base?
Uh oh!
There was an error while loading. Please reload this page.
Add support to build on SDK 37 #6590
Changes from all commits
c3df7705f51cf4f1c07ca48daee0b898334574a73ae7dcdb9c3ac3a07ecf8e1db85ab417f789fdc80a1e98800e7256438e7dc54cfe8402485eb3e6033ca5df11884338a59e91a7475109e387f2beda41304d7c978f9b979609d8bfc1c64846077daddc92d1c9b5ee630ec3602File filter
Filter by extension
Conversations
Uh oh!
There was an error while loading. Please reload this page.
Jump to
Uh oh!
There was an error while loading. Please reload this page.
There are no files selected for viewing
Check failure on line 16 in .github/workflows/pr-checks.yml
Use full commit SHA hash for this dependency.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can't we regenerate them locally like today? I checked on my machine and:
I'd avoid having to rely on CI for regenerating snapshots if possible, as it will slow us down compared to today.
Also one less workflow + script to maintain.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes — and your measurements match what I'd expect: Paparazzi's cross-platform rendering diff is currently tiny, so locally-recorded goldens pass. Local recording is fine as the default.
The one caveat: Paparazzi renders via a native layoutlib, and native text/anti-aliasing can differ slightly by OS + CPU arch (macOS/arm64 vs the Ubuntu/x86_64 CI). Today that difference is ~0, but a complex snapshot — or a future toolchain bump — could push a diff above maxPercentDifference, and then CI verify (which runs on Ubuntu) would fail against Mac-recorded goldens. If that ever happens, the fix is to bump the tolerance or re-record on the same OS as CI
Separately: I need to re-record the goldens now regardless, because the newer layoutlib changed its color output — so this re-record has to happen either way.
I'm happy to drop the record-paparazzi workflow + pull script once the PR is approved (one less thing to maintain). We can always re-add CI recording if a cross-platform diff ever exceeds tolerance.
Check failure on line 42 in .github/workflows/record-paparazzi.yml
Use full commit SHA hash for this dependency.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🎯 Functional Correctness | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
Repository: GetStream/stream-chat-android
Length of output: 1944
🌐 Web query:
Google Developer Android 17 API 37 large screen resize orientation activity recreation targetSdk behavior💡 Result:
For apps targeting Android 17 (API level 37) or higher, significant changes to orientation, resizability, and activity recreation behavior take effect, particularly on large screen devices (smallest width >= 600dp) [1][2][3]. Key behavioral changes and targetSdk requirements for API 37: 1. Mandatory Adaptive Behavior: On large screens (sw >= 600dp), apps targeting API 37 or higher can no longer restrict orientation, resizability, or aspect ratio [1][2][3]. Restrictions such as android:screenOrientation, android:resizableActivity, and fixed aspect ratio attributes are ignored [1]. The system no longer uses pillarboxing for these apps; they are required to fill the available display window [1]. 2. Activity Recreation and Configuration Changes: Because these apps must adapt to frequent changes in window size, orientation, and aspect ratio, the system will, by default, trigger an Activity recreation during these events [2][4]. To maintain user state and avoid data loss, developers are strongly encouraged to implement robust state preservation (e.g., ViewModel, savedInstanceState) [2][4]. 3. Opt-in for Handling Changes: If you prefer to handle these configuration changes yourself rather than letting the system recreate the activity, you must update your manifest to include the relevant configuration changes [5][4]. Specifically, adding android:configChanges="orientation|screenSize|smallestScreenSize|screenLayout" to your activity declaration will prevent the activity from restarting during these transitions [5][4]. In this case, the activity will instead receive a callback to onConfigurationChanged [5]. 4. New Default for Specific Configuration Changes: Note that starting in API 37, the system no longer restarts activities by default for several configuration changes that typically do not require full UI recreation, such as keyboard, navigation, and touch screen updates [5]. In summary, targeting API 37 mandates that your app be fully adaptive on large screens, removing previously available opt-outs for fixed orientations or aspect ratios [1][3]. Developers should focus on state preservation or explicit configuration handling to ensure a smooth user experience during the frequent resizing and rotation common in modern large-screen and multi-window environments [2][4].
Citations:
🌐 Web query:
Google Developer Android 17 SDK 37 behavior changes targetSdk compatibility💡 Result:
Android 17 (API level 37) was released in June 2026 [1][2]. Apps targeting this version are subject to several significant behavior changes aimed at improving performance, security, and consistent UI behavior across device form factors [3][4][5]. Key behavior changes for apps targeting Android 17 (SDK 37) include: Large Screen Constraints: Apps can no longer opt out of orientation, resizability, or aspect ratio constraints on large screens (sw >= 600dp) [4][6][5]. Legacy manifest attributes (e.g., screenOrientation, resizeableActivity) and runtime APIs (e.g., setRequestedOrientation) are ignored, though games are exempt [6][5]. MessageQueue Performance: Android 17 introduces a lock-free implementation of android.os.MessageQueue [3][5]. This may break applications that use reflection to access private fields or methods within MessageQueue [3][5]. Static Field Restrictions: Apps targeting API 37 cannot modify static final fields using reflection [3]. Attempts to do so via reflection will result in an IllegalAccessException, and using JNI APIs (such as SetStaticLongField) will cause the application to crash [3]. Dynamic Code Loading (DCL): Safer DCL protections are extended to native libraries [5]. All native files loaded via System.load must be marked as read-only, or the system will throw an UnsatisfiedLinkError [5]. SMS OTP Protection: The system extends SMS OTP protection to standard SMS messages (those not using WebOTP or SMS Retriever formats) [3]. These messages are withheld from the SMS provider database and the SMS_RECEIVED_ACTION broadcast for three hours after receipt to prevent OTP hijacking [3]. Bluetooth and Keystore Limits: BluetoothSocket RFCOMM implementations now align with standard Java InputStream behavior [4]. Additionally, the system enforces a limit of 50,000 keys per app in the Android Keystore for non-system apps targeting API 37 [7]. For compatibility, developers should use the Android 17 SDK [8]. Google Play requirements mandate that new apps and updates must target at least Android 16 (API 36) by August 31, 2026 [9][10]. While migrating to API 37 is not yet a Play Store requirement as of August 2026, it is recommended for leveraging new features like the standardized Android Contact Picker [11]. Developers are encouraged to use the Android SDK Upgrade Assistant in Android Studio for assistance with these transitions [8].
Citations:
Cover Android 17 behavior changes before merging the SDK bump.
targetSdk = "37"makes apps expose Android 17 runtime changes on API 37, including large-screen resize/orientation handling, manifest restrictions being ignored, activity recreation for size changes, and changes to SMS, DCL, reflection, and socket behavior. Existing smoke testing is not enough. Add API 37 device or emulator coverage for affected flows.🤖 Prompt for AI Agents
Sources: Coding guidelines, MCP tools
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I assume there were no behavioural changes caused by the targetSdk bump? - Should we maybe do thorough manual testing before releasing this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🧩 Analysis chain
🏁 Script executed:
Length of output: 126039
🏁 Script executed:
Length of output: 4958
@VelikovPetar, confirmed: the visible CI configuration does not run on Android 17/API 37.Current emulator coverage is:
The remaining recommendation is focused manual testing before release. Test the two sample applications on an Android 17/API 37 tablet or foldable emulator. Verify rotation, split-screen resizing, activity recreation, and the main chat and composer flows. This is relevant because both sample manifests set
android:screenOrientation="portrait", which Android 17 can ignore on large screens.You are interacting with an AI system.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I understand that this is necessary - but could this be a potential breaking change - breaking customer builds?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Snapshots are pruned after some time, so this commit will start failing once that happens.
I'd publish a stable conventions version. We can use a version suffix if we want to keep the version separated from the regular ones for now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Correct.
The reason I’m still using a snapshot is that I’m finalizing the changes needed for the Android 37 build support, and I won’t know the final stream-conventions requirements until both the Video and Chat PRs are approved.
My plan is:
Step 1 — Get the build-support PRs approved
Step 2 — Roll out stream-conventions
Once both PRs are finalized, I’ll make the required changes to stream-conventions and publish a stable conventions version.
Step 3 — Switch to the stable version
Update the Chat and Video Android 37 PRs to use the stable stream-conventions version instead of the snapshot.
This way, we avoid publishing a stable version prematurely while the required conventions are still changing.
Does it sound good to you? I am happy to change anything you suggest
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems Gradle 9 silently disables our Gradle Enterprise plugin. The build on this branch prints:
We should likely bump it (I think it's called Develocity now).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
After mutual discussion, we are removing gradle enterprise for now. We will revisit it later when needed
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.