World

ubuntu touch 24.04 on volla tablet with keyboard:mice buttons not working and pointer only moves on left half of screen.
Touchpad and typing is working

also : installing ubports on the tablet with ubports-installer results in black screen after installation

I need help bei Google Play Personalisierung steht bei Handy ist listet bei Google Play. I make on Boot Betriebssystem Way Droid Ubuntu Touch the Same Programmes WhatsApp and Ubuntu Touch. Can you give me the Telefonnummer vom Google play Personalisierungs Support techniker

Translation :

"I need some help with customising Google Play: my phone is listed on Google Play. I use the Droid Ubuntu Touch operating system when I start up my phone, and I’ve installed the same apps, WhatsApp and Ubuntu Touch. Could you give me the phone number for Google Play’s technical support team regarding customisation?"

Volla Quintus received with 20.04/OTA-8 and upgraded to 24.04-1.3.

The system clock / date is correctly set only when the phone connects on a WiFi network (via NTP, I suppose). Maybe it would also synch over mobile data, but I can't confirm that.

When the phone is power-cycled and restarted in offline mode (i.e. both SIMs "logged in" in VoLTE mode but no WiFi and no mobile data), the clock is off by several weeks.

So it looks as if, during shutdown, the kernel fails to save the system clock to the hardware clock.

Has anyone else noticed that behaviour?

Komend weekend (6-7 juni) is T-dose, een leuk Open Source evenementje in de Weeffabriek in Geldrop, dat gratis toegankelijk is. Je vindt er interessante sprekers, workshops en stands. En één van die standjes wordt bemensd door UBports!

Kom dus gerust langs om hallo te zeggen. Meer informatie over T-dose vind je hier: https://t-dose.org/2026/

I have experienced issues on my Quintus:

The bluetooth gui does not see my headsets when searching for devices. But I can directly pair them using bluetoothctl and their hardware identifier.
After having done this, they seem to stay saved in the list of paired devices, since they auto connect from then on.
Yet, the quintus does never show the headsets in the GUI (one are Volla buds, the other is no name).
The Pinetime in contrary works without issues and is always visible in the list.

I can't remember having these issues before which makes me think that is connected to Noble.
My phone is running UT natively, no dual boot.

Maybe this can be added to observations made on Noble that might be addresed at some point.

Hallo Forum, ich bin neu hier und möchte das "OnePlus Nord N100" kaufen um UT zu installieren. Doch OnePlus Nord N100 finde ich nicht ? Statt dessen gibt es das OnePlus Nord 5G ! Die Frage : Ist das auch möglich UT darauf zu Installieren ? Muß es das N100 sein ?

How can I get the required version of Android 10 to my phone?

How does it work for you at this point ?
What doesn't work (if) ?
What are the bugs (if) ?
Can we use as daily driver ?

After https://github.com/ubports/unity8/issues/121 was filed and we've had not one, but many sour discussions about this or related topics, I figure we should try to slow it down a bit.

People are getting antsy (read: livid) about the changes to Ubuntu Touch in upcoming releases. In this post I'll try to tackle the issue of "home." More specifically, Where is home in Ubuntu Touch now?

The case for going home

Home, in terms of an operating environment, is the first place where a user arrives and a place they can return to. It's taken many forms over the years of personal computing:

• 7000 BYTES FREE, READY.
• $ (or C:\>)
• Windows' Start menu (Then its Start screen, then its Start menu again)
• Screens which are actually called "Home" on Android and iOS

The concept of Home is slightly different for every operating environment, but it serves a few important purposes:

• It is used to start other interactions with the environment (applications, for example)
• It is "returnable," a user should always know how to get to it. Now that operating environments are used for multitasking, this shouldn't be by destroying all running activities.
• It is "safe," a user should always know what to do once they get there

Home serves as an anchor point for the environment's experience. If the user gets lost or stuck, returning home should help.

The Dash

We can currently assert the following things about Unity8 on a mobile handset:

• Long swiping from the left of the screen always returns you to the Dash.
• The Dash is a window and is shown in the app stack.
• Due to the last point, the Dash remains focused when the device is locked and unlocked.

The dash is home.

The Drawer

The following things about those assertions have changed:

• We no longer have the Dash. Long swiping from the left of the screen opens the App Drawer.
• The Drawer is not a window and does not appear in the app switcher.
• The Drawer does not remain focused when the device is locked and unlocked.

It is consistent with our desktop experience.

But it's got everyone up in arms.

Where is home now?

By far, the most important question I see us asking ourselves (indirectly) is, "where is home now?" The answer... isn't straightforward.

Is the Background home?

Users will land in the Ubuntu Touch experience at the Background (NOT the desktop, which implies you may put things on it):

When arriving at the Background, the Launcher (some call it the dock) appears to greet them. The user may arrive at the background by booting the device or closing all their apps. By offering the Launcher, the background can be used to start other interactions AND it is safe. However, it breaks one of our main rules: There is no way to return to the background without destroying all of your activities.

Is the Drawer home?

The Drawer may be opened by long-swiping from the left of the screen or tapping on the big ol' orange button:

This can be done at any time. This makes the Drawer returnable. It is very simple, so I assert it is safe. And, well, it starts new interactions.

Something about it has people really uncomfortable, though. Maybe it's the fact that, unlike the Dash (or iOS' home, or Android's home), the Drawer is dismissed when you lock the device. This resonates with me a bit, a serial home-presser before locking my device. I like to start at square one whenever I pick up my phone.

Can we find home?

Does this add a new requirement to home? Does home also need to be durable (or comfortable?), lasting through transitions to lock states or other huge events?

Or, is this okay? Is this a case of a different design being more efficient? The ideal use of Unity8 is pinning applications to the Launcher, where they can be managed and switched between (even on the lock screen).

(Maybe the Launcher is home, or the lock screen!)

Home must be durable

If home must be durable, the Background is close to being home. The only problem is we can't return to it easily. There are an infinite number of ways to solve this, here are a couple I've thought of:

Go to background as an app

Hide apps appears as another window in the app switcher. It is always located behind the most recently used app, as shown here.

Go to background as an action

We discussed having Go to background as a specific action you perform on the app switcher. It could also go somewhere else, but there's nowhere to put it. This issue proposes having it be the "Cancel" action of the app switcher, when you tap in the blank space. That caused a lot of upset since it changes the current behavior (tapping in the blank space goes to the app you were just using, today you learned) and is not explicit (as a Python developer, I agree). Here's a way to make it explicit:

(It took me twenty minutes to make that, don't judge me)

Nah, this is more efficient

If home doesn't need to be durable to be home, maybe there is a way to offer an olive branch to people who think it does?

What do you think?

Does home need to be durable? If so, is the Background a good place to have that interaction? Is there a good way to get there?

How do we keep the home interaction consistent between phone, tablet, laptop, and desktop?

Note that "just add another setting to..." is not an acceptable compromise. More customization means more development overhead, makes it more difficult to support users (you might have to do this, or you might have to do that), and takes away from a consistent experience. (If you want to discuss this metatopic, please make another thread.)

Addendum: ground rules

You're talking about a bunch of colorful rectangles, remember. Take your time when replying and keep it respectful and on-topic. This is a good place to brainstorm, but make your ideas concrete with mockups rather than talking about them abstractly.

The click on notification bubble doesn't work - is it a bug or a feature?

• I mean was it never intended to work?
• or was it not programmed yet to work?
• or it was working and now it's broken?

This is something that I find it would be very helpful - to be able to open the app imediately when I click on the bubble.

Right now I have to wait for the bubble to dissapear, I open to top scroll-down menu and I click on the notification to open the specific app: eg. Dekko, Greenline.

Hi everyone! I've been working on a qml Whatsapp client for Ubuntu Touch for a few weeks, now I think its good enough for its alpha release.

The app is not complete, there's still a ton of work to do, and probably many bugs. If you want to test it out, feel free to install in your device, and get back here if you find any bug so I can look at it. The Whatsapp protocol is awful to work with, I'm posting this early to gather feedback about edge cases.

Consider this app as Alpha, don't use it expecting to be 100% functional or complete, but use it to give feedback and help with the development.

Also the app runs unconfined to setup a background daemon, more on the architecture bellow.

Releases here: https://github.com/brennoflavio/greenline/releases

Once its stable, I'll publish to the store. Now more details about it.

Architecture

This app is composed of 3 parts:

1. Golang Daemon

This daemon managed by Systemd connects to Whatsapp servers and runs continuously in the background, gathering events and pre processing them. Also:

• Manages your encryption keys
• Serialize whatsapp events, stores in a queue
• Expose a JSON RPC endpoint to read and send messages, among other operations
• Syncs users avatars, media, and other data
• Sends notifications

2. Python Backend

Event driven backend that pulls events from the daemon and acts on them, building a chat room and message database. It also sends events to the frontend, updating the message list in real time

3. QML

The frontend is entirely written in qml and communicates with python using pyotherside

In order to pull messages in the background, it needs to run unconfined.

Device Boot Loop Issue While Porting to Ubuntu Touch (Halium 13)

I am trying to port my device to Ubuntu Touch, using Halium 13. I have flashed the images to the right partitions, but I encountered a boot loop with the following behavior:

Boot Loop Sequence

1. The device shows the Motorola start-up logo for one second.
2. The device shows the unlocked bootloader warning screen for 6 seconds.
3. It shows the Motorola logo again for 6 to 10 seconds, but now with a horizontal pixelated line on the screen.
4. It then shows a blank screen for 5 to 10 seconds.
5. The cycle repeats, but the line gradually moves down on each reboot.

Troubleshooting Performed

At this stage, I entered the fastboot bootloader and tried:

fastboot boot twrp.img

However, the device immediately started boot looping.

I then replaced dtbo.img with the one from the latest LineageOS 20 build available for my device.

After this change, the horizontal line disappeared.

I was able to successfully boot TWRP using:

fastboot boot twrp.img

Logging Investigation

I attempted to read the pstore logs but couldn't find any useful output.

I suspected the kernel might not have been built with the required logging options enabled.

To address this, I:

• Created a separate logging.config file with the right kernel flags.
• Added it to deviceinfo.
• Verified that the options were correctly applied to the generated .config file located at:

workdir/downloads/KERNELOBJ

• Added the appropriate kernel command-line parameters to the vendor cmdline in the deviceinfo file.

Current Status

Despite these changes:

• The device still does not boot properly.
• USB does not become available.
• The pstore directory remains empty even after enabling all relevant logging flags and kernel parameters.

Source Tree

For debugging and error analysis, the device source tree is available at:

• https://gitlab.com/systemmaniac2010/motorola-rhode

Please help me out with this.

Re: Nord N10 5 G

Hi guys!

I'm kind of a newbie trying to get through an installation of Ubuntu Touch to a OnePlus Nord N10 5 G, and it's not as straightforward as I thought. I've now installed bleedin Windows on my old desktop machine and am trying to find the Qualcomm USB drivers for it. There's a link on this page

https://community.oneplus.com/thread/1541327

but when I try to download there's an error message that Google can't scan the file for viruses which feels a bit dodgy. Also, when I click "Download anyway" there's an error and no download. If I go to Qualcomm's pages and search for "usb drivers for Windows 10" I get 5,119 results...

I'm pretty new to fiddling with phones, I've only installed Linux OSes to the PinePhone a couple of times. Can anyone point me to a safe place to download the drivers please?

I used the firehose and installed OnePlus_Nord_N100_EU_OxygenOS_10.5.2.zip unlocked bootloader, used the installer. I got dumped into recovery. do i need to install firehose to both slots first?

Has anyone figured out a way to get more recent lineage os images featuring Android 15/16 onto waydroid yet? The 'official' images seem to be stuck on lineage os 20 (android 13). I've stumbled upon https://github.com/WayDroid-ATV/waydroid-builds but it only appears to support x86_64.

Wrote up a complete BE2012 → Ubuntu Touch 24.04 install path that runs entirely from macOS — no MSMDownloadTool, no borrowed Windows box, no VM.

Repo: https://github.com/dcherrera/n100-be2012-crossflash

What it covers:

EDL cross-flash from macOS via bkerler/edl driven by an XML-based partition plan generator. Sidesteps the patched-MSM project-ID guard by never implementing it. Uses OnePlus's own signed Firehose loader, vendored via the bkerler/Loaders submodule.

Bootloader unlock via the OnePlus carrier-shim app removal trick (the five packages holding sys.oem_unlock_allowed=0). No SWID hex-edit required for the unlock itself; the param exploit is documented in the repo as Plan B if the carrier-shim approach ever stops working.

UBports recovery patching on-device via magiskboot from the Magisk APK, because the rubencarneiro recovery's gpg 1.4.13 can't verify the SHA512 sigs on modern system-image files. No firmware rebuild needed.

A SIM-init binary patch on /usr/sbin/ofonod that fixes a silent blocker leaving Modem.Features stuck at ['sim'] on first boot. Disassembly + offset table in the README.

Reproducible from a fresh clone — 7 shell scripts, ~230 KB of source. Tested on a single unit. Brick risk is the usual EDL-low.

Carrier caveats (T-Mobile bands only, Verizon SIMs read but won't sustain attach) in the README's cellular section.

Standing on the shoulders of the BE2015 install-success thread for the unlock approach, and rubencarneiro/billie2 for the bootstrap images.

Bonjour,
Je viens à vous aujourd'hui car je me suis lancé, il y a peu, dans une petite quête, c'est à dire que je souhaiterai, avec mes maigres connaissances mais qui ne demande qu'a s'étoffer, pouvoir comprendre comment pouvoir réutiliser du vieux matériel mobile en installer linux, en commençant par UB Touch. Je débute dans le monde du libre, ai quelques maigres connaissances en informatique mais une méga grosse motivation d'apprendre!!! Voyant le potentiel immense, je souhaiterai être utile dans la bataille contre l'obsolescence programmé de tout ce matériel que l'on peut voir finir sa vie, loin d'être terminé pourtant, au fond des placard ou dans des bennes, par méconnaissance du champs des possibles. Je ne remarque que trop de cas autour de moi de personnes qui, facilement, change d'appareils car ne connaissant pas les alternatives aux solutions propriétaires imposés, n'ayant pas la connaissance pour le faire.
Par exemple, pour se faire, j'ai acquis d'occasion une tablette Lenovo M10 2nd gen, ayant vu sur la page matériel compatible d'UB Touch que celle-ci pouvait fonctionner sans probléme. Une fois acquise et lancé dans la réinstallation du système je me suis aperçu, assez vite malheureusement, que le modèle indiqué sur la page était la X306F/L et que la mienne est une X606F.... bonheur
De ce fait j'ai commencé par installer CrDroid, qui à l'air de fonctionner mais encore trop googlisé à mon goût, car toujours sous Android.
Arrivé à ce stade de ma quête une foultitude de question se pose à moi et je me permet donc de venir vous les poser:
1- Il y a t'il des sites ou structures asso vers qui je pourrais me rapprocher afin de pouvoir échanger sur cette idée de faire renaître du vieux matériel mobile, afin de ne pas encombrer des pages de forum inutilement pour ça?
2- Je souhaiterai pouvoir comprendre le processus de fonctionnement de ces appareils afin de pouvoir saisir également les différentes étapes qui permettrait de pouvoir faire ce genre d'adaptation avec tout types de d'appareil mobile de toute marque, si la possibilité existe bien entendu, ne sachant pas trop par où commencer ma recherche... ayant déjà passé pas mal de temps dans les méandres de la toile sans trop trop de succés... par exemple pour adaptater UB Touch sur ma tablette...
Bref, j'espère être à peu prêt clair dans l'explication de ma requette ( et pas trop ennuyeux ) et que certains-es d'entre-vous accepterons d'éclairer ma lanterne.
Un grand merci par avance!
Une belle journée!

Probably a dumb question but are the n100 and the n200 the same as far as ubuntu touch goes? I can't seem to find anything specific to the n200 and am looking for a 5g phone that I could put Ubuntu touch on. I've got an n10 on order but just waiting for it right now....just curious if the n200 was an option as it's notably cheaper as well as supporting 5g.

Thanks.

I'm looking to learn the Ubuntu Touch app stack properly, and the best way I know to do that is reading clean code from people who know what they're doing.

Can anyone point me to apps (with public repos) that the community would consider well-architected? I'm interested in:

• Clear project structure and separation of concerns
• Good use of QML/Qt and the UT SDK / Lomiri components
• Sensible handling of confinement, permissions, and the click/snap packaging
• Any C/C++ backend integration done well

Doesn't need to be big, just clean and idiomatic. Happy to hear about your own apps too if you think they're good examples.

Thanks!

Source / install: https://github.com/TeamIDE/HomeSpikev1 · License: GPL-2.0-or-later

What it is

HomeSpike is a fullscreen home surface for Ubuntu Touch (Lomiri) that replaces "drawer-as-default" with what most people actually expect from a phone: a wallpapered home grid you land on after unlock, swipeable pages of icons, an iOS-style dock, and an edit mode where you long-press to drag icons around or remove them. New apps you install auto-add to your last page. The Lomiri drawer is still there (the patched long-press inside it gives you an "Add to HomeSpike?" prompt), but it's no longer the first thing you see.

It ships three placement modes so you can lay icons out the way you actually want: auto-fill (icons reflow with no gaps), snap-to-grid (place on any cell, gaps allowed), or place-anywhere (drop wherever, overlaps OK). Each mode keeps its own saved layout — switching modes never destroys the previous arrangement.

It also fixes a fundamental gap in Lomiri's staged mode (the phone form factor): there was no "show desktop" concept at all — Lomiri's design assumed one app always fills the screen. Tapping the Ubuntu logo (BFB) or the new spread home button now reliably returns you to HomeSpike, with the running apps still alive in the background. Real multitasking with a real home screen.

I built it because Ubuntu Touch in 2014 made a bet on "scopes as cards" replacing home screens with widgets, and that bet hasn't aged well. Every other mobile Linux shell since (Plasma Mobile, Phosh, even Android-via-Halium) has done the opposite. After daily-driving UT on a OnePlus Nord N100 and finding myself wanting somewhere to put apps in an order I chose, I stopped wishing for it and wrote it.

How it works

It's all QML on top of stock Lomiri — no shell fork. HomeSpike loads as a Loader inside Lomiri's own Stage.qml, replacing the original Wallpaper element. Because it lives in the lomiri process and isn't a separate application surface, it never appears in the app spread, never needs autostart, and never has a .desktop file.

The four Lomiri files we touch (Shell.qml, Stage.qml, Stage/Spread/Spread.qml, Launcher/Drawer.qml) are shipped as full replacement copies under app/lomiri-overrides/ — install is plain backup-and-replace, no sed. Original files are kept as .orig and uninstall.sh cleanly reverts. Installer is idempotent and OTA-survivable (re-run after a system update).

For "go home" to actually work, HomeSpike teaches the stage a new concept: a homeShown flag that promotes the HomeSpike Loader above the app delegates on demand (BFB / spread home button) and demotes it again when an app gains focus. Without this, Lomiri's staged appDelegate state insisted on rendering the focused app full-size even when minimised, hiding HomeSpike. There's a small Mir-focus-echo grace window so the previous app's lingering focus state doesn't immediately flip the overlay back off.

HomeSpike itself reuses Lomiri's own primitives instead of reinventing: app inventory comes from AppDrawerModel (the same model the drawer uses), wallpaper comes from AccountsService.backgroundFile (the same one Settings writes when you change wallpaper), icons render with LomiriShape (same rounded-rect tile primitive). State (per-mode layouts, dock contents, hidden apps, page count, dock settings) persists to ~/.config/home-spike/home-spike.conf via Qt.labs.Settings. The Drawer→HomeSpike "add" is a file-inbox the running HomeSpike polls every 1.5 seconds — no D-Bus dance, just a file.

Features

Multi-page swipeable home (1–5 pages, configurable)

Optional iOS-style dock at the bottom (max 5 apps, persistent across pages, adjustable plate height). When the dock is on, Lomiri's left launcher panel auto-collapses so HomeSpike owns the full screen.

Three placement modes with independent saved layouts:

Auto-fill (reflow, no gaps)

Snap to grid (place on cells, gaps allowed, swap on collision)

Place anywhere (drop anywhere on the page, overlaps allowed)

Edit mode (long-press): drag-to-reorder, drag-to-edge auto-flips page, X-badge removes an icon (stays installed, just hidden from home)

Drag between dock and grid in both directions

True multitasking + reliable home: BFB or the spread home button always returns to HomeSpike; running apps stay alive in the background and resume instantly when re-tapped

Home button in the right-swipe app spread — tap to return to HomeSpike without minimising each app individually

Wallpaper inherits whatever you set in Settings → Background

New installs auto-append to the last page (snap → first free cell; place-anywhere skips, since it's intentionally manual)

Long-press an app in the swipe-left drawer → "Add to HomeSpike?" prompt → it appears on your home within ~2 seconds

Per-arch portable — no qmlscene wrapper script, no arch-specific paths; HomeSpike runs inside lomiri so it picks up whatever Lomiri sees

Tested on

OnePlus Nord N100 (billie2), Ubuntu Touch 24.04 noble. The design is generic to Lomiri 24.04 — should work on every device on that channel. If you try it on something else, please let me know.

How to install

Currently distributed as a self-hosted installer (not OpenStore — see "Why not OpenStore" below). Phone connected via adb, developer mode on:

git clone https://github.com/TeamIDE/HomeSpikev1.git
cd HomeSpikev1
PIN=<your-phablet-sudo-pin> ./deploy/install.sh

To revert:

PIN=<your-phablet-sudo-pin> ./deploy/uninstall.sh

Why not OpenStore

OpenStore ships Click packages, which are AppArmor-sandboxed and explicitly cannot modify system files, remount / rw, or hook into Lomiri's shell QML — i.e., every single thing that makes HomeSpike the home rather than an app you open. A confined Click version would just be "HomeSpike Launcher: an app drawer you have to tap to enter," which loses 90% of the value. So this ships as a self-hosted installer for now. A clean long-term answer is upstreaming the home-surface mechanism into Lomiri proper — I'd like to do that once the design has settled in real-world use.

Caveats up front

Modifies four Lomiri shell files. Read install.sh before running. Backups are made for each (.orig next to the live file); uninstall.sh restores them.

OTA wipes overrides. Re-run install.sh after any system update. Takes a couple seconds.

Iterating on the overrides logs you out to the greeter. Lomiri caches QML aggressively, so the dev refresh path pkills lomiri — you'll see the greeter, unlock to continue. Normal use (just running HomeSpike) doesn't restart anything.

Removes the OpenStore-link long-press in the drawer. That gesture now goes to "Add to HomeSpike?" instead. Can be restored as a different gesture later if there's demand.

No widget API yet. This release is the home surface itself. A widget system (with a real provider API) is the next milestone — the current QML is the scaffolding for an eventual ImGui+Lua reimplementation that'll host third-party widgets behind the same load-point.

Source + issues

GitHub: https://github.com/TeamIDE/HomeSpikev1

License: GPL-2.0-or-later. No warranty. PRs welcome — especially "tested on <your device>" confirmations and Lomiri-version-drift fixes for the override copies.

TL;DR

"I wanted a home screen on Ubuntu Touch. UT doesn't really have one — the drawer is the default surface and there's no place to arrange icons how you want. So I wrote one. It's a QML tree loaded inside Lomiri's own Stage.qml + four small Lomiri shell-file overrides. Multi-page, dock, drag-to-reorder, three layout modes (auto-fill / snap-to-grid / place-anywhere — each with its own saved layout), long-press in the system drawer adds apps to it, spread gets a home button, BFB minimises any open app and reveals HomeSpike — true multitasking with a real home screen. Backups + uninstaller included. Source linked below."