[How] can one force toasts to render as notifications in AOSP?

−0

Name	≈ Implementation
“Toast”	`Toast.makeText`
“Notification”	`NotificationCompat.Builder`

I ask because:

As android.stackexchange.com/revisions/27612/1 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.
As android.stackexchange.com/revisions/58288/1 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]

Similarly, acquiring diagnostic data for situations like github.com/tasks/tasks/issues/3952'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.

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.
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.