Just an update, I gave up on trying the KDEConnect workaround. I did some deep investigation on resolving the issue within Waydroid itself, and documented my progress. It's definitely a feature-request in Waydroid. https://github.com/waydroid/waydroid/issues/211

I haven't done any more work on it for a while, since my last post on github. There are a few libs being used in Waydroid, which I linked to, which have sparse documentation.
I don't have deep enough knowledge of these languages and platforms to be able to fix this easily - not to mention android's workflow for builds. Wasn't able to do a build of LineageOS on my PC; some incompatibility with package versions.

It'd be nice to resolve this for everybody who uses Waydroid, but IRL is taking priority for now.

Researching this more, I found this issue on WayDroid's github, so they're at least aware this is a restriction.
https://github.com/waydroid/waydroid/issues/211

Someone there mentioned using KDEConnect as a workaround. I might look into that next.

Pretty sure the UT system, Linux, is inherently different from Android, and so will never be fully compatible without the use of containers like Waydroid.

You can containerize+run GooglePlay apps under waydroid, with a GAPPS image. I followed this guide for enabling that, as well as enabling Google Play Services, which many first party apps will not work correctly because they require DRM to run.
But its worth noting that enabling Google Play Services will decrease your privacy/security, which is probably why it's not the default "guided" way to install waydroid on UT.

I'd like to think that running GooglePlay/Services in a container is more secure than just a vanilla android OS, but honestly I'm not entirely sure. It probably depends on what device settings/features you restrict app access to in waydroid?

UT's "guided" way of installing waydroid can let you access some GooglePlay apps via AuroraStore apk (a redistributor) without google services. In my experience however, this leads to some android apps needing those services, crashing and causing other problems with Waydroid. It's fiddly.

Sad. I am getting very discouraged how much disconnect there is from containerized apps in Waydroid, and the main Ubuntu Touch system.

YouTube for example, while playing video, is letting the system enter lock/sleep, as I just discovered a few minutes ago. (which the google play version has more features I'd prefer to have (incl. premium), and is not simply a web browser like the OpenStore version)

There's lots more android apps I'm not even mentioning here, that I was led to believe would fully run as expected in containers. I mean I guess that's more or less the case, but damn am I giving up a lot in the name of security/privacy.

Surely it'd be easy to implement it so the UT system reads the raw memory of the waydroid instance, to retrieve notifications, then pass those along? /sarcasm

At the very least, it seems the two systems have enough things in common that they could be linked somehow, much like how their audio and video systems have been.
Then again maybe the UT devs don't want to go full hog on support of waydroid containers, which seems to be its own project. Or like most things FOSS, it's a time restriction.

I think yall have made a nice mobile OS with compatibility for a wide range of devices, but I'd like to express some UX things I think could be improved, at least for consistency. These are listed in no particular order, and obviously, are my opinion, and I realize some of these changes I'm listing would take limited dev time to implement.

1. Long-Pressing applications in "Pinned Applications" & "The Drawer" menus should do the same things: Open a context menu, or enable dragging
   
   Right now, long-pressing applications in the pinned applications sidebar on the left, will bring up a context menu of additional actions you can do with it, including unpinning. It also allows you to rearrange the order of the icons by dragging.
   However doing the same in the Drawer menu on the larger right side, will only attempt to open the app in OpenStore - often failing if the app was not installed from OpenStore. As far as I can tell, there's no way to pin an application from here? (It's likely I just have not figured out how to do it.) Most OS's give multiple routes of doing the same thing. As an end user, I would expect no different from the UX of Ubuntu Touch.
   Even if you do not plan to actually allow users to rearrange their icons in the Drawer menu, enabling the ability to visually drag the icons, then snap back to original position when released, can give useful usage-context clues to the user. For example, I did not realize the icons on the left side could be reordered at all, until I read on this forum it could be done. (Because I first had tried with the Drawer menu, and it didn't work)
   Doubling back to application-specific context menus, I think these kinds of menus are quite useful for fast shortcuts to frequent tasks (Uninstalling, viewing info, app-settings, app-administration, etc), and expandable from a programming perspective. Google phones/APIs went further with this idea and let apps add their own context menu entries, which may be a bit too much overhead work for this project, at this point. Just thought I'd mention - context menus are versatile from both sides.

2. The top "Notification Menu" ...at first I did not understand the nature of its gesture, but after a few hours I got the hang of it, with its single swipe down, then left or right. It's something I could get very used to, but honestly I'd really appreciate the ability to customize the sub-menus that are shown when you swipe down, in the system settings or something. I'm never going to use that "Keyboard" sub-menu on my device; it just takes longer to scroll past it. Likewise, I feel many sub-menus on my phone are just very blank; the "Files" sub-menu is literally blank for me. Does "Rotation Lock" toggle need its own entire sub-menu to scroll past?
   Coming from vanilla Google Pixel 3a (Android 12) I feel they made a good balance of making everything you could need accessible and visible, in a short amount of time. If it couldn't be shown there, it was a single tap to take you to a different page to configure it (eg, wifi settings).
   Things like enabling flashlight (sometimes useful in dark emergencies!) were right there. Now its hidden under... "Battery"?
   I think you are on to something new and innovative with your current Notfication menu, but at the same time you might consider reorganizing some things, such that you borrow what's good from competitors' UX in this area. A hybrid, if you will. Especially, I think your actual notifications need to be on display in this menu, not hidden off to the far side in a sub-menu.
   Maybe make it so if you do a partial swipe-down+left/right, it will show you something closer to what you have implemented currently, vs if you do a full swipe-down and release, it would show you an overview of everything, with frequently-used shortcut buttons, like flashlight.
   I do like the current menu, how it does not take up the entire screen when the device is in landscape rotation, which segways to my next topic...

3. Screen Rotation Logic... I don't know what's up with it, but I find my screen will rotate when I do not want it to do so, like at slight diagonals. Maybe it needs the gyro thresholds adjusted, or add a delay before it applies the rotation?
   Something fancier like "floating gyro thresholds", so the more noise in gyro values, the more the system will be likely to try and rotate the screen from where it currently is? No idea if that math would even work in practice tbh.
   Additionally, I can't get the screen to rotate to reverse-portrait. Oversight in the code maybe? It hasn't been a big deal, just something I noticed. It might be a bigger deal for someone else. All other screen orientations are working for me.

Honestly, the rest of my feedback is down to specific apps, battery usage on an already well-worn battery, or has already been expressed by myself or others elsewhere.

I only just now realized this workaround is a menu feature in "Waydroid Helper" app from OpenStore.

Just sharing, and maybe bringing awareness to an issue I had with WayDroid.

Basically, the result of this issue, is that all waydroid sessions will become entirely unresponsive after an app running under waydroid crashes, with a low rate of recovery.
Ending any/all waydroid's apps shown as running in UT would not work, nor would tapping waydroid's icon or any apps running under waydroid in UT. The latter would not do anything.

Before finding the below workaround, the only solution I found to get back into waydroid's UI was to reboot my phone.

I noticed this problem was especially rampant when attempting to run child apps that had Google Play Services dependencies, but then failed to find those services, like YouTube. (resulting in an app crash)

Session Crash Workaround

If this happens to you, open your terminal app in UT or via ADB/SSH and enter the following two commands:

waydroid session stop
waydroid show-full-ui

The first command will terminate all (broken) waydroid instances running, and the second will restart the waydroid app and bring it into focus.
Hope this helps someone.

Not sure if this is intended behavior.
When apps in waydroid trigger a push notification, my phone will trigger a sound, but the Ubuntu Touch system will not register the notification or message - which can be very confusing.

Many apps I use for communication, such as Signal, are not available in UT via OpenStore. Others require Google Play Services (Which I have now set up correctly in waydroid). So it seems my only option is to run these android apps in WayDroid.

Is there a way to route Waydroid's notifications to UT's notification manager, so they are all in the same place, including accessible from the lock screen?

@kuuga What OS are you using for your host PC in the installation?
If ADB cannot see the device, especially when the phone is in "fastboot" mode, with a windows host, this is probably because of missing google android drivers.
On a Linux host, the command line tools from google should just work as-is after extraction. (In my bumbling around I used both.)

Windows google-android driver: https://developer.android.com/studio/run/win-usb

This guide below was extremely helpful for me, specifically the sections "Prerequisites" and "Unlocking Bootloader" since google's developer pages have so many dead 404 links. The other sections can be ignored if using UBPorts installer.
https://xdaforums.com/t/guide-pixel-3a-sargo-unlock-bootloader-update-root-pass-safetynet.4443459/
Don't forget to downgrade your Pixel3a to Android 9 before running UBPorts installer.