@developerbayman That's great! Do you mind if I tinker on it a bit? Then I can upload my copy (like on gitlab) so you can see the changes? Mainly working on adding content hub so the end user can pick roms that they have stored on their phone. With that said, yours comes with alot of roms built in, but aren't there license issues with distributing those roms? For the one I was tinkering on, I dropped all the roms and put in several open source home brew roms, like D Pad Hero I & II, which are GPLv3. I don't want to hijack your project though. Just thought I'd help out with this one, because it is interesting to me. Whatever you release is completely up to you.

@toniox if the phone is mediatek, use spflashtool. its a pain in the *** to do, i recommend using windows for rhis because otherwise you'll need a custom kernel and all the tutorials will use windows. the steps go like this: download drivers, and set them up use bootrom bypass tool flash with sp flash i recommemd dumping nvdata,nvram,nvcfg,protect1,protect2 from NAND using spflashtool before flashing anything at all (think of it like youre phones ID it is needed for service ,wifi ,bluetooth) there is also ways to regenerate the checksums so with lockee xiaomi bootloader you can run custom code but i dont really remember how i managed that one.

@pparent said in French ID app interoperability.: This is no longer relevant at this time: hmm, it did not take long for this beast to resurrect: https://www.lemonde.fr/pixels/article/2026/01/22/le-gouvernement-n-a-pas-renonce-a-acceder-au-contenu-des-discussions-sur-les-messageries-chiffrees_6663627_4408996.html

@tigermoth without being able to permanently unlock the bootloader this is a non-starter, anyone's feeling notwithstanding.

@klh said in My Ubuntu Touch devices participated in Thailand nationwide cell broadcast test: @peat_psuwit do you have a spec for the Thai EBS? Looks like they require a working SIM card? I have no idea where to look for that. I tried searching on web for it, but nothing that look like it. The only thing I can go by is Android's config file. I still maintain that we'll need a CB topic database from e.g. Android and should not not rely on hardcoded set of topics from a non-regional specification. In theory we should only need the table from 9.4.1.2.2 of 3GPP TS 23.041. Hmm interesting. That spec does indeed list all topics I've seen on my Android phone. I think I've seen a different spec cited earlier that doesn't include some of them. (For reference, I've seen the following topics: 4370, 4371, 4372, 4384, 4396) Still, it doesn't seem to provide a grouping of topics for settings (or maybe I miss something). And it would also be useful to have a database for notification heading (e.g. in US the title for 4370 should be "Presidential alert", but that obviously won't fly for Thailand). Unfortunately, the test today is inconclusive on whether we need to explicitly subscribe to topic "4370" or not. We don't already? According to the same table, 4370 is not supposed to be settable by the user and always subscribed (I'm kind of extending the 3GPP definition of MMI here) so this shouldn't be a question - since afaik it's not required to be implemented at modem level, we should check what ofono reports and subscribe to the missing ones. It's not supposed to be settable, but this doesn't seem to be enforced by oFono. Currently our settings pane doesn't subscribe to this topic, but apparently Fairphone 5 subscribes to this topic anyway. Still, I reckon that we should be on the safe side and always add 4370 to the list of subscribed topics. Also, currently there's no boot-time component which will subscribe to mandatory topics automatically (and on some region e.g. Thailand this doesn't seem to be limited to 4370 only; see the linked Android config). The settings pane is the only component which sets the topics. This is problematic because oFono don't have a set of initial topics (besides a small number of built-in ones from ETWS).

@kugiigi NDK is basically a set of C APIs Android exposes to applications, allowing apps written in native code to get access to certain functionalities without calling Java APIs through JNI (Java Native Interface). The good news is that these APIs should largely be usable on Halium-based UT devices as well. So the advantage is that we don't have to rely on bespoke APIs libhybris exposes, which allows us to share more code with upstream which already supports Android (in this case GStreamer). This is not relevant to mainline devices.

@Moem and four stickers Thanks

@Feynt That's only odd if you believe that UBports has a plan for which devices are going to supported. And such a plan could only happen in a different kind of organisation. You should keep in mind what UBports is, or rather what we are: a community, a loosely connected group of volunteers. Whether a certain device gets ported depends on there being someone who has the skills has the time has the wish has the device. If there is no such person around, then no port is going to happen. Maybe you could even be that person? To find out, you can start reading here: https://docs.ubports.com/en/latest/porting As is forum policy, your topic will now be moved to the Offtopic Area. Thank you for understanding.

@GabrielDistake Hello Gabriel! UBports does not take porting requests. You should keep in mind what it is, or rather what we are: a community, a loosely connected group of volunteers. Whether a certain device gets ported depends on there being someone who has the skills has the time has the wish has the device. If there is no such person around, then no port is going to happen. Maybe you could even be that person? To find out, you can start reading here: https://docs.ubports.com/en/latest/porting As is forum policy, your topic will now be moved to the Offtopic Area. Thank you for understanding.

Late to the discussion, but on desktop the Yubikey requires some packages installed. So integration would not be straightforward, but I guess something can be hacked if need be. To have the OS support it natively is another story as I doubt an app can bring Yubikey's features to other apps, the browser and wherever it is needed...

@Moem said ... most of us have full lives and don't read the forums every day. Me too, usually. I just focused to try to get something working, due to 30 day ebay seller return policy. Failed interaction with Oneplus support ate up 12 days of that.

A related project to look at: https://blog.mariofragnito.it/en-gb/posts/pitv-my-fire-tv-stick-clone/

@nwoo66 In English, please.

Best wishes to everyone for 2026! 🥳

@trynafindbhumik You just got your answer on the Telegram group, so just for completeness: No, each device needs its own port, and there is no port for that device. That means it's not supported. Supported devices are listed on https://devices.ubuntu-touch.io/ This topic will now be moved to off-topic.

Merry Xmas!

@gpatel-fr It's really as simple as, if set to English (Canada): Contact: +15145555555 will reliably be found by prediction once I type +151 Contact 15145554444 will not be found no matter what I type Contact (514)555333 will not be found no matter what I type Other contact formats (514) 555-5555, similarly won't be found. Nothing without the initial +. Anyhow, I'm quite happy about the T9! Many thanks to you for making me aware of it, and for your help in diagnosing things. And many thanks to Lionel for creating the function! My extensive (long-winded) testing was to try to be helpful, but I'm quite satisfied with how things function at present. If the phone number predictions get improved for databases as mangled as mine, and various weird international standards, all the better! But sadly, I don't think I'm the person who will succeed with that.

@Bolly Oh... look at that! And to think I never knew!!