WAI
Status Update
No update yet.
Comments
ra...@google.com
ra...@google.com
bo...@google.com
ms...@google.com
re...@gmail.com
Thanks for reporting this and providing some code snippets! Additionally, if you have a project I would be able to clone that reproduces the issue it would definitely help as well!
ma...@gmail.com
You can clone this:
Run the Main Activity, scroll to the end of the list: I join a screen of the issue.
ma...@gmail.com
Thanks for providing a sample project! Looks like this is an issue with how we conflate item accesses when triggering prefetch.
ma...@gmail.com
Project: platform/frameworks/support
Branch: androidx-master-dev
commit 190a76ec743552627310e024976fd5896e989acb
Author: Dustin Lam <dustinlam@google.com>
Date: Mon Sep 28 13:54:08 2020
Prioritize hints from more recent presenter state
Currently we only use itemsPresentedAfter, which only accounts for the
placeholderOffset from the last page, but this value is insufficient to
determine which hint loads more items in cases where the last/first
pageOffset changes on presenter side.
As a result, we'll drop hints that would load more items in favor of
hints that came from a past presenter state that was scroll further into
placeholders.
This change fixes the above by always prioritizing new incoming hints if
the first/last pageOffset of presenter state changes.
RelNote: "N/A"
Fixes: 169259468
Test: ./gradlew paging:paging-common:test
Change-Id: Iffda3a0eb7abe162045893367b4781daf75adb01
M paging/common/api/current.txt
M paging/common/api/public_plus_experimental_current.txt
M paging/common/api/restricted_current.txt
M paging/common/src/main/kotlin/androidx/paging/PageFetcherSnapshot.kt
M paging/common/src/test/kotlin/androidx/paging/PageFetcherSnapshotTest.kt
https://android-review.googlesource.com/1441095
Branch: androidx-master-dev
commit 190a76ec743552627310e024976fd5896e989acb
Author: Dustin Lam <dustinlam@google.com>
Date: Mon Sep 28 13:54:08 2020
Prioritize hints from more recent presenter state
Currently we only use itemsPresentedAfter, which only accounts for the
placeholderOffset from the last page, but this value is insufficient to
determine which hint loads more items in cases where the last/first
pageOffset changes on presenter side.
As a result, we'll drop hints that would load more items in favor of
hints that came from a past presenter state that was scroll further into
placeholders.
This change fixes the above by always prioritizing new incoming hints if
the first/last pageOffset of presenter state changes.
RelNote: "N/A"
Fixes: 169259468
Test: ./gradlew paging:paging-common:test
Change-Id: Iffda3a0eb7abe162045893367b4781daf75adb01
M paging/common/api/current.txt
M paging/common/api/public_plus_experimental_current.txt
M paging/common/api/restricted_current.txt
M paging/common/src/main/kotlin/androidx/paging/PageFetcherSnapshot.kt
M paging/common/src/test/kotlin/androidx/paging/PageFetcherSnapshotTest.kt
ju...@gmail.com
I have this problem too, did you find a workaround guys?
bi...@gmail.com
Me too
il...@gmail.com
startActivity(new Intent(Settings.ACTION_MANAGE_OVERLAY_PERMISSION)) worked perfectly on the Galaxy Watch 4 (Wear OS 3), but on the Galaxy Watch 6 (Wear OS 4) I'm getting "Not Available The System Overlay Permission is not available".
On a smartphone running Android 13, the user has to first enable "Allow screen overlays on Settings" in Developer Options, but that setting is also missing on Wear OS 4.
My apps rely on this feature, so I really hope they bring it back.
On a smartphone running Android 13, the user has to first enable "Allow screen overlays on Settings" in Developer Options, but that setting is also missing on Wear OS 4.
My apps rely on this feature, so I really hope they bring it back.
kh...@google.com
Thanks for the feedback. To give users more control over the content that appears on a relatively small screen, Wear OS 4 has removed the UI that allowed for granting the SYSTEM_ALERT_WINDOW permission. Only system-level apps should rely on this permission.
We've
pe...@gmail.com
When the user activates the screen when an alarm clock goes off, it's not convenient for the user to scroll up the notifications. I feel it's best when the alarm app can show itself immediately to snooze or stop the alarm. Is there a non system-level app permission to achieve such a behaviour?
th...@gmail.com
There is a way of launching an activity directly when a notifications is shown such as when a phone call is received or when an alarm goes off using full screen intents: https://developer.android.com/develop/ui/views/notifications/time-sensitive
This however seems to be broken on all watches except the galaxy watch 4, 5 and 6. See:https://issuetracker.google.com/issues/264598572 and https://issuetracker.google.com/issues/263963117
This however seems to be broken on all watches except the galaxy watch 4, 5 and 6. See:
fe...@gmail.com
It's broken on samsung watches too (i tried on galaxy watch 5 pro, wear os 3.5...still have to try on wear os 4)
th...@gmail.com
Full screen intents work on my galaxy watch 4 and I have tested it using samsung's remote test lab on a galaxy watch 6. Have you checked that you have notifications enabled for the app? If the notifications are disabled it does not work.
fe...@gmail.com
I will check again later, thanks for the suggestion.
fe...@gmail.com
ok, it does work when the screen is on...but the high priority notification doesn't turn on the screen with the full screen intent, even if the associated activity has android:showOnLockScreen="true" and android:turnScreenOn="true" and temp disable keyguard...any suggestion?
th...@gmail.com
Yeah, I had a similar problem. Just create a wake lock with the flags ACQUIRE_CAUSES_WAKEUP and ON_AFTER_RELEASE and acquire the wake lock when you launch your activity from the fullScreenIntent.
fe...@gmail.com
ACQUIRE_CAUSES_WAKEUP seems deprecated...do you have any samples btw?
fe...@gmail.com
i fixed by setting PRIORITY_MAX in notification builder...and the following wakelock (despite 2 of 3 flag are deprecated, but i didn't find another solution):
val powerManager = context.getSystemService(POWER_SERVICE) as PowerManager
if (!powerManager.isInteractive) {
val wl = powerManager.newWakeLock(
PowerManager.ACQUIRE_CAUSES_WAKEUP or //deprecated
PowerManager.ON_AFTER_RELEASE or
PowerManager.SCREEN_BRIGHT_WAKE_LOCK, //deprecated
"id:wakeupscreen"
)
wl.acquire(1000)
}
Now the screen turns on and shows my full screen intent.
val powerManager = context.getSystemService(POWER_SERVICE) as PowerManager
if (!powerManager.isInteractive) {
val wl = powerManager.newWakeLock(
PowerManager.ACQUIRE_CAUSES_WAKEUP or //deprecated
PowerManager.ON_AFTER_RELEASE or
PowerManager.SCREEN_BRIGHT_WAKE_LOCK, //deprecated
"id:wakeupscreen"
)
wl.acquire(1000)
}
Now the screen turns on and shows my full screen intent.
Description
An earlier version of Wear OS was missing the UI to add the permission SYSTEM_ALERT_WINDOW and it was added via issue request
Wear v3 when requesting this permission via the emulator displays
"Not Available The System Overlay Permission is not available"
The Samsung Watch Wear OS models have UI to handle the SYSTEM_ALERT_WINDOW permission. On the Android Studio emulator while the UI is not available and the associated permission "canDrawOverlays" returns false the emulator allows some overlays that only appear to work only with this permission enabled.
Can toggle UI be added to grant the SYSTEM_ALERT_WINDOW permission by starting an activity for the Intent target?
Settings.ACTION_MANAGE_OVERLAY_PERMISSIONsimmilar to
startActivity(new Intent(Settings.ACTION_MANAGE_OVERLAY_PERMISSION));