Assigned
Status Update
Comments
vi...@google.com <vi...@google.com> #2
IMPORTANT! Please note that if you released your library to stable with these calls, the APIs must maintain binary compatibility moving forward.
That means the restricted APIs need to be made public or @RestrictTo(LIBRARY_GROUP_PREFIX) (e.g. effectively public for the purposes of compatibility).
You CANNOT simply remove the call to the restricted API.
That means the restricted APIs need to be made public or @RestrictTo(LIBRARY_GROUP_PREFIX) (e.g. effectively public for the purposes of compatibility).
You CANNOT simply remove the call to the restricted API.
an...@gmail.com <an...@gmail.com> #3
Sorry, additional point of clarification. These bugs have been filed against the call sites, but the issue really applies to both the restricted API and the call site.
For the call site: the call may be safely removed, however if the call went out in a stable release then that release will crash if the restricted API is removed.
If the restricted API should be maintained to ensure binary compatibility with your library, please forward this issue to the component for the restricted API and continue reading.
For the restricted API: this bug was filed because your API was used outside of your library group. The API must now be tracked for binary compatibility. You may make the API public or LIBRARY_GROUP_PREFIX visibility.
For the call site: the call may be safely removed, however if the call went out in a stable release then that release will crash if the restricted API is removed.
If the restricted API should be maintained to ensure binary compatibility with your library, please forward this issue to the component for the restricted API and continue reading.
For the restricted API: this bug was filed because your API was used outside of your library group. The API must now be tracked for binary compatibility. You may make the API public or LIBRARY_GROUP_PREFIX visibility.
vi...@google.com <vi...@google.com>
ad...@google.com <ad...@google.com>
an...@gmail.com <an...@gmail.com> #4
Can we make this to P1 and check on priority. Because our app requires this issue to be fixed for talkback users on android TV since it is blocked for them to be scrolling down in home screen.
an...@gmail.com <an...@gmail.com> #5
Any update on this issue ?
an...@gmail.com <an...@gmail.com> #7
Basically there is a restriction to use third parity library in our project for our client. Anyway i will try to use this in my POC and let you know. is there any other workaround available to fix this?
Description
Affected device: Android TV
As in the video from below drive link, you will notice the if I click down button the talkback focus from "Title 0" is jumping directly to "Title 2" in between skipping "Title 1". Even it is skipping in horizontal rail items as well.
Tried with many possibilities none of them works. Tried with onKeylistener to get the user key pad events for workaround but listener itself is not working in talkback mode.
Video:
Source code:
Is it an Android framework issue?
Any help will be much appreciated. Thanks