Post History
Context Name ≈ Implementation “Toast” Toast.makeText “Notification” NotificationCompat.Builder My Rationale I ask because: As android.stackexchange.com/revision...
#3: Post edited
- #### Context
- Name | ≈ Implementation
- -|-
- “Toast” |`Toast.makeText`
- “Notification” | `NotificationCompat.Builder`
- #### My Rationale
- I ask because:
- 1. As [`android.stackexchange.com/revisions/27612/1`](https://android.stackexchange.com/revisions/27612/1#:~:text=Sounds%20like%20there's%20an%20app,it%20to%20the%20offending%20app.) explains, when an activity or service posts a toast, the user cannot remove it. They must, instead, merely wait for it to disappear. This proves problematic when infinite amounts are posted, or the duration of them is manually increased, because the user cannot click through them.
- 1. As [`android.stackexchange.com/revisions/58288/1`](https://android.stackexchange.com/revisions/58288/1#:~:text=The%20values%20of%20LENGTH_SHORT%20and%20LENGTH_LONG%20are%200%20and%201.%20This%20means%20they%20are%20treated%20as%20flags%20rather%20than%20actual%20durations%20so%20I%20don't%20think%20it%20will%20be%20possible%20to%20set%20the%20duration%20to%20anything%20other%20than%20these%20values.) explains, for those with visual accessibility deficiencies, like myself, reading them before they disappear, when the duration of their appearance isn't sufficient to (I'm merely myopic, but without my glasses, can miss them), they are easily missed. Notifications, by contrast, always exist in `cmd statusbar expand-notifications` and `com.android.settings/.notification.history.NotificationHistoryActivity` if accidentally removed from even there. [^1]
- [^1]: [`android.stackexchange.com/revisions/260316/2`](https://android.stackexchange.com/revisions/260316/2#content:~:text=the%20content%20of%20com.android.settings/.notification.history.NotificationHistoryActivity)
- These are problems that I have frequently encountered, to severe extents. Therefore, I haven't posted this to rant; I want a solution, but if this is not remediable, I'll file an issue at [`issuetracker.google.com/issues/new?component=190923&template=845103`](https://issuetracker.google.com/issues/new?component=190923&template=845103).
- #### Potential Solutions
- 1. Obviously, one may modify AOSP's source. However, maintaining an OS is not a feasible endeavour for most, and no current distributions, that I know of, provide this. If the aforementioned potentially-to-be-filed ticket with Google is rejected, I'll file downstream instead.
- However, something that intercepts via `adb`, or even superuser permissions, would be applicable to more distributions.
- 1. Alternative OSes, like postmarketOS, do not provide similarly homogenous APIs, nor as comprehensive security. Therefore, although QWidgets and wxWidgets (etcetera) might not post any toasts, GTK 4 and KDE's Kirigami QML superset do, and are not configurable. It would also be a somewhat out-of-scope “solution”, if one at all.
- #### The Placement Of The Question
- See [`posts/294864/history#2`](https://linux.codidact.com/posts/294864/history#2:~:text=for%20that%20site.-,At%20%5B%60posts/293280/history%237,20make%2520no%2520mention%2520of%2520it.\).,-However:)'s citation.
- #### Context
- Name | ≈ Implementation
- -|-
- “Toast” |`Toast.makeText`
- “Notification” | `NotificationCompat.Builder`
- #### My Rationale
- I ask because:
- 1. As [`android.stackexchange.com/revisions/27612/1`](https://android.stackexchange.com/revisions/27612/1#:~:text=Sounds%20like%20there's%20an%20app,it%20to%20the%20offending%20app.) explains, when an activity or service posts a toast, the user cannot remove it. They must, instead, merely wait for it to disappear. This proves problematic when infinite amounts are posted, or the duration of them is manually increased, because the user cannot click through them.
- 1. As [`android.stackexchange.com/revisions/58288/1`](https://android.stackexchange.com/revisions/58288/1#:~:text=The%20values%20of%20LENGTH_SHORT%20and%20LENGTH_LONG%20are%200%20and%201.%20This%20means%20they%20are%20treated%20as%20flags%20rather%20than%20actual%20durations%20so%20I%20don't%20think%20it%20will%20be%20possible%20to%20set%20the%20duration%20to%20anything%20other%20than%20these%20values.) explains, for those with visual accessibility deficiencies, like myself, reading them before they disappear, when the duration of their appearance isn't sufficient to (I'm merely myopic, but without my glasses, can miss them), they are easily missed. Notifications, by contrast, always exist in `cmd statusbar expand-notifications` and `com.android.settings/.notification.history.NotificationHistoryActivity` if accidentally removed from even there. [^1]
- [^1]: [`android.stackexchange.com/revisions/260316/2`](https://android.stackexchange.com/revisions/260316/2#content:~:text=the%20content%20of%20com.android.settings/.notification.history.NotificationHistoryActivity)
- Similarly, acquiring diagnostic data for situations like [`github.com/tasks/tasks/issues/3952`](https://github.com/tasks/tasks/issues/3952#issue-3562709063)'s would be easier, because `dumpsys` doesn't include toast information, due to its ephemerality (although this applies to discarded notifications, too, per the aforecited).
- These are problems that I have frequently encountered, to severe extents. Therefore, I haven't posted this to rant; I want a solution, but if this is not remediable, I'll file an issue at [`issuetracker.google.com/issues/new?component=190923&template=845103`](https://issuetracker.google.com/issues/new?component=190923&template=845103).
- #### Potential Solutions
- 1. Obviously, one may modify AOSP's source. However, maintaining an OS is not a feasible endeavour for most, and no current distributions, that I know of, provide this. If the aforementioned potentially-to-be-filed ticket with Google is rejected, I'll file downstream instead.
- However, something that intercepts via `adb`, or even superuser permissions, would be applicable to more distributions.
- 1. Alternative OSes, like postmarketOS, do not provide similarly homogenous APIs, nor as comprehensive security. Therefore, although QWidgets and wxWidgets (etcetera) might not post any toasts, GTK 4 and KDE's Kirigami QML superset do, and are not configurable. It would also be a somewhat out-of-scope “solution”, if one at all.
- #### The Placement Of The Question
- See [`posts/294864/history#2`](https://linux.codidact.com/posts/294864/history#2:~:text=for%20that%20site.-,At%20%5B%60posts/293280/history%237,20make%2520no%2520mention%2520of%2520it.\).,-However:)'s citation.
#2: Post edited
Can one force toasts to render as notifications?
- [How] can one force toasts to render as notifications in AOSP?
#1: Initial revision
Can one force toasts to render as notifications?
#### Context Name | ≈ Implementation -|- “Toast” |`Toast.makeText` “Notification” | `NotificationCompat.Builder` #### My Rationale I ask because: 1. As [`android.stackexchange.com/revisions/27612/1`](https://android.stackexchange.com/revisions/27612/1#:~:text=Sounds%20like%20there's%20an%20app,it%20to%20the%20offending%20app.) explains, when an activity or service posts a toast, the user cannot remove it. They must, instead, merely wait for it to disappear. This proves problematic when infinite amounts are posted, or the duration of them is manually increased, because the user cannot click through them. 1. As [`android.stackexchange.com/revisions/58288/1`](https://android.stackexchange.com/revisions/58288/1#:~:text=The%20values%20of%20LENGTH_SHORT%20and%20LENGTH_LONG%20are%200%20and%201.%20This%20means%20they%20are%20treated%20as%20flags%20rather%20than%20actual%20durations%20so%20I%20don't%20think%20it%20will%20be%20possible%20to%20set%20the%20duration%20to%20anything%20other%20than%20these%20values.) explains, for those with visual accessibility deficiencies, like myself, reading them before they disappear, when the duration of their appearance isn't sufficient to (I'm merely myopic, but without my glasses, can miss them), they are easily missed. Notifications, by contrast, always exist in `cmd statusbar expand-notifications` and `com.android.settings/.notification.history.NotificationHistoryActivity` if accidentally removed from even there. [^1] [^1]: [`android.stackexchange.com/revisions/260316/2`](https://android.stackexchange.com/revisions/260316/2#content:~:text=the%20content%20of%20com.android.settings/.notification.history.NotificationHistoryActivity) These are problems that I have frequently encountered, to severe extents. Therefore, I haven't posted this to rant; I want a solution, but if this is not remediable, I'll file an issue at [`issuetracker.google.com/issues/new?component=190923&template=845103`](https://issuetracker.google.com/issues/new?component=190923&template=845103). #### Potential Solutions 1. Obviously, one may modify AOSP's source. However, maintaining an OS is not a feasible endeavour for most, and no current distributions, that I know of, provide this. If the aforementioned potentially-to-be-filed ticket with Google is rejected, I'll file downstream instead. However, something that intercepts via `adb`, or even superuser permissions, would be applicable to more distributions. 1. Alternative OSes, like postmarketOS, do not provide similarly homogenous APIs, nor as comprehensive security. Therefore, although QWidgets and wxWidgets (etcetera) might not post any toasts, GTK 4 and KDE's Kirigami QML superset do, and are not configurable. It would also be a somewhat out-of-scope “solution”, if one at all. #### The Placement Of The Question See [`posts/294864/history#2`](https://linux.codidact.com/posts/294864/history#2:~:text=for%20that%20site.-,At%20%5B%60posts/293280/history%237,20make%2520no%2520mention%2520of%2520it.\).,-However:)'s citation.
