-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
Dependency updates for v2024.3 #6252
Dependency updates for v2024.3 #6252
Conversation
1a049c9
to
7f488eb
Compare
9412925
to
3603afc
Compare
@@ -230,7 +230,7 @@ jobs: | |||
command: ./gradlew assembleSelfSignedRelease | |||
|
|||
- run: | |||
name: Check APK size isn't larger than 11.5MB | |||
name: Check APK size isn't larger than 11.7MB |
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.
Is Mapbox responsible for 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.
Yes but I'm not sure if it's only because of Mapbox, the difference (0.2MB) wasn't big enough to make me do that.
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 think it's worth double-checking so we know before merging.
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've just checked and it's not only Mapbox however to check which other dependencies affected the build size I would need to revert the updates one by one and build apks. It's also possible that it's not just one but a few so I think it's not worth it.
ktlint_standard_binary-expression-wrapping = disabled | ||
ktlint_standard_condition-wrapping = disabled | ||
ktlint_standard_function-literal = disabled | ||
ktlint_standard_backing-property-naming = disabled |
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 feel like function-literal
and backing-property-naming
are nice improvements, actually. Could we fix them instead of disabling? Agreed the other feel unneeded.
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 didn't analyze which of those rules are worth enabling. I was thinking that maybe it would be a good task for me while you are off in September? It would be something easier to review for @lognaturel.
@@ -26,10 +26,13 @@ | |||
<exclude name="JUnitUseExpected" /> <!-- Favor using fail explicitly to test correct exception --> |
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'm not going to both inspecting these changes as most code will be Kotlin going forward anyway.
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.
a17eefc
to
3603afc
Compare
@grzesiek2010 probably makes sense to let testing happen before merging here! |
ANRs occur while opening maps on all devices. Most likely it's just Google maps. The issue doesn't occur on the master version apk build with and without tokens (Google maps or OSM open first).
|
Performance in the Myanmar calendar is very poor. XRecorder_16072024_104633.mp4 |
This reverts commit 1b786e3.
I've reverted that change in the Myanmar question type. It seems to be a problem in the newest version of the library which I've reported here: chanmratekoko/mmcalendar#4 (comment). In this case, there is no need to test it. |
I've downgraded the dependency that was responsible for that to the version we used in v2024.2 and everything should be fine now. Upgrading it so that it works without ANRs will require some more changes so I will file a separate issue for that. |
Tested with Success! Verified on a device with Android 10 Verified Cases:
|
Tested with Success! Verified on a device with Android 14 |
Why is this the best possible solution? Were any other approaches considered?
As usual, I've updated the dependencies for the next release. Nothing special to discuss here.
How does this change affect users? Describe intentional changes to behavior and behavior that could have accidentally been affected by code changes. In other words, what are the regression risks?
Usually, we don't test dependency updates but this time there are some changes that need testing in my opinion:
Myanmar calendar - I wanted to update it at the beginning of the last cycle but I found some bugs that I reported (see Problems with month names in 1.0.8.RELEASE chanmratekoko/mmcalendar#4). The problems should be fixed now but we can't be sure there are no more similar issues. Please test it like it was a new question type - carefully.Do we need any specific form for testing your changes? If so, please attach one.
No.
Does this change require updates to documentation? If so, please file an issue here and include the link below.
No.
Before submitting this PR, please make sure you have:
./gradlew connectedAndroidTest
(or./gradlew testLab
) and confirmed all checks still passDateFormatsTest