I’d like to add my vote regarding the camera—it’s the main limitation for me. From what I understand, this isn’t something that can be fixed simply by creating a new camera app, as the issue seems to run through multiple levels of the system. As far as I recall, the core limitation is already present in Halium: shots take too long, not all features are exposed, higher resolutions can easily overexpose, and overall the photos look far worse compared to what Android delivers.

Of course, this is likely a per-device issue, making a universal fix difficult. Still, there are numerous GCam tweaks available for different devices, and I wonder if a similar approach could be explored for Ubuntu Touch. Even the native AOSP camera tends to work more reliably, despite its own limitations.

Running Waydroid alongside UT isn’t a viable solution either, as it consumes a lot of battery and the two environments don’t integrate well.

@malditobastardo I used to have overexposed images on higher resolution - same device (not always, but usually shortly after I switched to the higher resolution). So when on UT I took photos in lower res and started relying on Waydroid and GCam even for photos

Unfortunately there is likely no way to improve this on the UT level. I looked into that (granted, with my poor understanding of things) and it looks like all the camera issues (slowness, no support for HDR etc) are already coming from Halium and perhaps the camera being non standard as the Halium/Android layer is already limiting what it can do on UT.

I wonder if there is something the Halium project can do to improve things? Perhaps similarly to what GCam does enable some per-device configs to actually support more of the stuff devices can do.

@peat_psuwit What could a device porter/maintainer do in this instance to make it work better? Thank you

@padraic Definitely not my work. Anyway, you can check GitLab to see who worked on this: https://gitlab.com/debclick/uFirefox

@arubislander That's a surprise. This is the first time I see that information. And I must say joyeuse is one of the best ports out there and is not lacking basically anything.

Contrary to what you say, any idea why OTA-5 has been released for it though?
https://system-image.ubports.com/20.04/arm64/android9plus/stable/miatoll

To verify the image from yesterday is indeed OTA-5 I just switched to that channel:
sudo system-image-cli -vvvv -p 0 --switch 20.04/arm64/android9plus/stable

@peat_psuwit Thank you so much. You just made my day brighter, as it scared me a lot. As much as I don't want to use Android there are occasions in which I can't choose and using Waydroid inside Ubuntu Touch for that is simply perfect.

Does Waydroid work for people? It has been broken on devel since March, so seems like the issues has propagated here now as well. The app appears to be running (Waydroid logo is visible in the taskbar), however no Android window appears on the screen.

Happens to me on Joyeuse, not sure if for others or elsewhere too. However, switching back to stable fortunately (I really need it for banking apps for instance) does recover this for me still.

@padraic Yes, builds are already in made by GitLab CI - on the link I shared. Download the archive for your architecture, extract, find a click package inside and install.

This one is probably more suited to be used on phones: https://gitlab.com/debclick/uFirefox/-/pipelines/1255486984
Either way this is a standard desktop app which is not well integrated into the system and also doesn't work properly unfortunately. Hopefully something that will improve with Mir updates, once UT/Lomiri is ready for those.

I haven't tried but wouldn't placing TextArea into Flickable work, making the TextArea the height of the max(main app window, its content) and making Flickable handle the scroll?

Albeit it is probably (and unfortunately) not going to automatically scroll down when inserting new lines in edit mode or just scrolling through with keyboard. Additional code to deal with that would be required, if at all possible

@randomusername I think any word for which the dictionary can't find more matches gets highlighted as such

As for the Google Keyboard, that doesn't seem related to UT at all, so why do you mix those two?

While I am in no way a security expert, how did you arrive to that conclusion? How is Android kernel related to OSK suggestions?

Don't worry too much about this, most of the time it's not a problem to run a tainted kernel; the information is mainly of interest once someone wants to investigate some problem ...

https://www.kernel.org/doc/Documentation/admin-guide/tainted-kernels.rst

My Ubuntu desktop also returned a non 0 value for me when I just tried.

That surprises me though, because I think even the old SDL2 version that used to support Mir before that extension was dropped did contain Wayland support. Can the current Mir version we have actually work with Wayland or is it all XMir? I thought the later but maybe not in which case we could then probably use every SDL version there is.

This SDL2 working with XMir vs SDL3 running directly though Wayland is a bit confusing to me.

@Dieter42 said in No video transmission with messengers:

Have Ubuntu Touch a special firewall-config for Waydroid ?

I don't think so. It should have pretty much a full access to hardware (or rather the Android firmware which UT is also using) with the exception of some things like networking as it doesn't have access to the telephony stack for instance. However I know little about this

I think I've experienced something similar when I last tried, so not sure if it is still the case. But whenever any Android app (e.g. banking app) tried to use video recording it failed, while taking pictures was always fine.

@domubpkm One of the reasons upgrading Ubuntu Touch from Xenial to Focal was so hard was the change from the now discontinued init system called Upstart, to systemd.

Generally these logs are stored in /var/log/journal (which a quick Googling will reveal), however the whole toolkit is quite different to what we used to have before so unfortunately you can't even expect the same from it.

I would suggest trying this app: https://open-store.io/app/logviewer.ruditimmer, which simplifies the access to logs using kjournald as a backend.

Regarding the journal, this might come handy: https://wiki.archlinux.org/title/Systemd/Journal

Every device has a status of what is working or not on the device page, including your phone:
https://devices.ubuntu-touch.io/device/sargo

Of course it is possible there is an error on a device page or something is no longer true due to software updates/changes bringing in regressions. However, what you are describing should not be the standard experience and it is likely something is wrong with that particular installation.

For instance, if you look at this device: https://devices.ubuntu-touch.io/device/pinephone
it has many more issues and it specifically states "24+ hours battery lifetime" is an issue.

PS. Did you follow every step the instructions state? Like this:

If the device is running an Android version above 9.0, you have to downgrade to the last 9.0 release. Make sure to revert to factory image PQ3B.190801.002 before continuing.

Just to add to this. While I have not been able to actually process the QVideoFrame yet (meaning I have not been able to covert properly to QImage as all I have is a black image using the QVideoFrame::map or black image with some distortions using the alternate QOpenGLContext method outlined here - while it all says it is valid and not null :crying_face:), I have discovered that in order to use the OpenGL Context one can create QWindow and use its surface like so:

https://github.com/qt/qtmultimedia/blob/5.12/src/plugins/avfoundation/mediaplayer/avfvideoframerenderer.mm#L123

Took me a while to figure out how to use it though as it didn't work for me and was crashing the app right on start when the code was part of a plugin (QObject). Unfortunately I was not able to Google it properly (didn't bump into anything that would say that usage is incorect), however with some luck and a lot of trial and error I found out it works when one creates this in the main.cpp file and then simply replies on the QOpenGLContext::currentContext().

And then considering QVideoFrame::map works on UT as part of the Camera QML object I would presume both methods need to work somehow :(. I am just obviously not doing something properly as it is failing for me as described above ^.

https://github.com/qt/qtmultimedia/blob/5.12/src/multimedia/video/qvideoframe.cpp#L1094

@johndoe IIRC recent Network Manager does this automatically, hence why it works on desktop and upon connecting to such a network shows the login page. I am not sure if the necessary update was made though or in what state that effort ended. Maybe the Network Manager even got updated but it would probably require more to actually have it open a web browser with the correct url.

https://github.com/ubports/ubuntu-touch/issues/885

This is an interesting one. QVideoFrame::map is giving me these:

OpenGL context is not current, cannot map memory.

And when I try to use the QOpenGLContext::currentContext() is doesn't work either. What is more QOpenGLContext::functions() is killing my app (looks like bad memory access?) and that has probably something to do with the fact the context is not defined? I wish I knew more :(, but I also tried creating that context and it didn't have any impact.

This is the minimalistic example just added to the Clickable C++ template that crashes for me:

#include <QGuiApplication>
#include <QQmlApplicationEngine>

#include <QOpenGLContext>
#include <QOpenGLFunctions>

int main(int argc, char* argv[])
{
    QGuiApplication app(argc, argv);
    QQmlApplicationEngine engine(QUrl("qrc:///Main.qml"));

    QOpenGLContext *ctx = QOpenGLContext::currentContext();
    QOpenGLFunctions *f = ctx->functions();

    return app.exec();
}

Any ideas what could be causing that? My attempts were so far quite futile too
Thanks a mil!

EDIT:
I later found out where the QVideoFrame::map error is coming from:
https://gitlab.com/ubports/development/core/qtubuntu-camera/-/blob/main/src/aalvideorenderercontrol.cpp

As well as how to initialize the OpenGLContext - see per post bellow.

Fastboot should normally be available all the time. As already mentioned, UT is not locking anything so you should really be able to boot to fastboot and it is very weird that you can not.

Other than that, the first Google result for stock rom gave me this:
https://xiaomifirmwareupdater.com/miui/lavender/

which is the site I normally install stock roms for Xiaomi devices (works on Linux too). But basically (and while I know little about it) I believe you need to have either adb or fastboot working.

It is really hard to help you not knowing more information. I don't know how deep we should go.
E.g. How are you trying to access fastboot? Doesn't the usual key combination (probably volume down + power button) work?