https://kotlinlang.org
Join Slack
Hello, I have recently switched to 1.4.0-beta03 and .rotaryScrollable() and I'm noticing something s...
# compose-wear
a
Hello, I have recently switched to 1.4.0-beta03 and .rotaryScrollable() and I'm noticing something strange. When I open my app after like 1-2 hours of not using it, it opens correctly but then some black overlay is showing on top of current composable screen. I can even scroll the list and tap on buttons to navigate etc. What could be causing this? When the app is in background (not frozen or killed by system) it opens correctly. This only happens when app was not opened for a longer period. I'm attaching two screenrecords. One which shows correct behavior and one when the app is opened after longer period of time. Any help is greatly appreciated :)
behavior_not_ok.mp4behavior_ok.mp4
y
Which device and Wear OS version is it?
a
Pixel Watch 2, latest security patch.
y
Not that I know of any issue that would be affecting you, but do you do anything specific with splashscreen or a splash activity? Or navigation deep linking?
a
In the Application I'm using android:theme="@style/Theme.App.Starting", defined as:
Copy code
<resources>
    <style name="Theme.App" parent="@android:style/Theme.DeviceDefault" />

    <style name="Theme.App.Starting" parent="Theme.SplashScreen">
        <item name="windowSplashScreenBackground">@android:color/black</item>
        <item name="windowSplashScreenAnimatedIcon">@drawable/splash_screen</item>
        <item name="postSplashScreenTheme">@style/Theme.App</item>
    </style>
</resources>
I'm also using val navController = rememberSwipeDismissableNavController(), SwipeDismissableNavHost with two destinations
y
Just for giggles, and if easy to test - you could see if ripping out the splashscreen dependency has any effect.
It's no longer required, as Wear 4 defaults to the right thing
I'm also curious if bumping dependencies brought in new versions of androidx.navigation or compose navigation
a
When I switch back to v1.3.1 and
Copy code
.rotaryWithScroll(
    scrollableState = listState,
    focusRequester = focusRequester
),
everything is back to normal.., Also, with .rotaryScrollable, logcat is full of Unable to acquire a buffer item, very likely client tried to acquire more than maxImages buffers
y
But otherwise if you can repro, file a bug.
For the verbose logging
🙏 1
a
SplashScreen is still needed for API 30+. I was rejected a few weeks ago because of it so I added it.
I'm only using androidx.wear.compose: compose-material, compose-foundation, compose-navigation. All three updated from 1.3.1 to 1.4.0-beta03. But I'm not sure if this is related to libraries. I was able to spot the same thing with 1.3.1 and rotaryScrollable.
It's hard to repro because it only happens after 1-2 hours of inactivity. Reproducing this on Emulator is almost impossible.
Could it be that I'm using . rotaryScrollable with remember { FocusRequester() } instead of rememberActiveFocusRequester() ?
y
That would affect scrolling not working, when the focus goes somewhere else. But wouldn't explain the black part.
I suspect you are transitively pulling in some other change.
a
Hard to say, I'll try to isolate the issue. What I can confirm is that when only updating libs 1.3.1 -> 1.4.0-beta03, emulator logcat throws infinite lines with some strange error while scrolling.
y
The splashscreen requirement has been effectively removed. So we can help appeal that if you want. It's not so much a change in Policy, as they will only enforce on Wear 4, where it's automatic if you don't do anything.
Starting in Wear OS 4, the system automatically shows the app icon as the splash screen icon, unless your app uses a custom theme and needs to keep the splash screen on-screen for longer periods. If you’re using a custom theme, migrate to the SplashScreen API.
plus green 1
a
Okay, I'm removing SplashScreen now and will try to replicate the issue. Thank you 🙂
m
what do you mean by Custom theme, when adapting material 3 the splashscreen is configured by default using the app launcher icon?
y
the activity or application theme in the AndroidManifest.xml
this is not about material3, rather androidx.splashscreen. If you don't do anything, Wear 4+ will show the correct splashscreen using the app launcher icon. But nothing on Wear 3.
If you integrate with the library, it will start working on Wear 3 also, which is less of a priority given Wear 4, and soon 5, and PW and Galaxy Watch all get updates, so most users.
But if you integrate, you can't really customise, or you'll get rejected. Wrong Icon, or wrong background, or animation.
a
But we should still set @android:style/Theme.DeviceDefault right?
y
Yep.
In the manifest
a
Okay, I'm testing now, so far the only thing I didn't change is my ScalingLazyColumns. I'm still using .rotaryWithScroll instead of rotaryScrollable.
Is there a chance that the issue can be caused by when the app is opened after a longer period to a composable with rotaryScrollable?
y
Anything's possible.
a
y
It's hard without a repro, things that jumped to mind that don't quite fit
• navigation related - something additional shown on top - seems unlikely if you can click • scroll related - content is there, but scroll off screen. Seems unlikely since you can click • Something else? seems more likely.
a
I'll try creating two app versions, and only test on same composable, one with rotaryWithScroll, other with rotaryScrollable, leave both apps in the BG for some time and then test. It's strange that I could not reproduce this after force-stopping apps / removing them from recents.
m
@amoledwatchfaces did you tried the navigation stable library version?
i
FWIW, none of those Navigation 2.8.0-beta03 issues apply on Wear - Wear Navigation doesn't use any of those display parts of Navigation, but uses its own implementation (which is how they get the swipe to dismiss logic integrated in)
l
You might be able to consistently reproduce it by checking the "Don't keep activities" developer option, or by setting the background processes to a low value (or none) before resetting it back to a non-fixed value.
WTF (What a Terrible Failure), those options are missing on the Watch! 😥
a
@Ian Lake But the logcat is basically full of the same error-warning combination.
@louiscad can't we use adb to change system settings?
l
Probably, I don't know if there's a reference for that, but sounds plausible
a
@marlonlom with stable, logcat looks ok, no errors or warnings when scrolling.
l
You can also kill the process with adb, while it's in the background, you might go back from recents and I think it's like the system had to evict the app from memory
a
App Force-stop + opening the app is ok. That's why it's hard to replicate.
l
I think adb kill process works differently from force stopping
y
I can't guarantee it, but I think after a reboot, you can set that mode. Not sure which devices this worked on (from an internal Q&A on similar topic).
Copy code
$ adb shell settings put global always_finish_activities 1
$ adb reboot

$ adb shell dumpsys activity | grep mAlwaysFinishActivities
  mAlwaysFinishActivities=true
l
And set it back to 0 afterwards. Do you really need to reboot BTW?
🤷🏻‍♂️ 1
a
So, after testing, I can say that having a custom theme / SplashScreen was not causing the issue. Same with rotaryScrollable/ roatryWithScroll. The issue is there only when updating one of the three androidx.wear.compose libs from 1.3.1 to 1.4.0-beta03.
👍 1
y
I'll discuss on Monday.
t
Those logs errors are tied to Compose 1.7. The fix was very recently merged as other necessary ones. Not sure all is on beta 4 but will be in the next one for sure.
@yschimke Do you have something explaining that the splash requirement is removed? WO-V15 is still present in https://developer.android.com/docs/quality-guidelines/wear-app-quality and that's the one they rejected my other app before without the splash library.
a
@Tolriq Thanks, will try with another beta then 🙂
y
Only https://medium.com/androiddevelopers/tools-and-libraries-to-help-your-wear-os-app-satisfy-google-play-app-quality-requirements-a4f061f18e26#:~[…]zes, so there requirement is still technically there, but only enforced on Wear 4+ where it should be automatic. If you stopped the splashscreen showing on Wear 4, then it would be rejected.
If you get a rejection, send me the app id and any case number, and I'll raise internally.
Sorry for confusion, I don't always word good with explanations.
t
I'm French so don't worry I barely write proper English 🙂
🙂 1
But I'll keep the splash library for now then just in case. There's now multiple evidence than Google suspend apps for multiple rejections.
👍🏻 1
Won't risk the main app over random Wear team process.
Last compose bugs should finally be fixed so I can push the main app update then start the review process for wear and pray 🙂
👍🏻 1
Wish me luck.
y
May your rejections be infrequent, your reviewers wise, and the solutions feasible.
😁 1
t
Lol thanks, I have no doubt about the solutions, the issue is knowing what they actually want, and hope they do not force me to destroy a design because by choice 1 text pixel was hidden .... (Hopefully for this app the design is more common so this should not happen)
And actually spoke too soon 😛 The M3 last update to TimeText have increased the size and the padding and now with ultra large font + bold it goes over the now playing text 😞
y
Yep - I think there is a fix coming for that. The fun of using Alphas.
t
I really need to find time to try the new Koala Feature drop screenshot stuff.
y
Yep - it works well. There is also Roborazzi (which is a public release), and an inflight PR for it for similar preview functionality.
The Compose Preview Screenshot testing is perfect for 90% of screenshots, but Now In Android and Horologist are just waiting for it to be stable.
t
Yes I know many solutions and not enough hours in a day 😞 I hope the AS one is simple and maintained properly for simple updates and not requiring tons of maintainance.
y
Yes, very little integration effort, and promotes using Previews which is a good thing.
This is an example of applying it to wear-os-samples https://github.com/android/wear-os-samples/pull/1099/files
t
Thanks for the link, seems easy yes.
👍🏻 1
Well easy and working.
90 Views
Open in Slack
PreviousNext
Powered by

kotlinlang

A modern programming language that makes developers happier.

Powered by