Sony Nagara (Xperia 1IV and 5IV) port

I have just reflashed SFOS on my 1 IV from scratch, using (once again) the .71 image. 100% clean reflash with reformatting the userdata partition, etc. The very first thing I’ve tried, before doing absolutely anything else other than passing SFOS’ standard initial setup and configuring WLAN connection, was checking whether the Sailfish web browser’s search funtion works correctly. Sadly, it does NOT. Same problem as before, i.e. entering any keyword in the browser’s address bar tries to open it as an URL rather than search for it in the search engine configured in Settings.

Another problem that remains after fresh install is that the standard Jolla Gallery app is unable to correctly play any video. After a few seconds it stutters and finally freezes.

I will reflash it yet another time using the .62 image and see if it makes any difference.

EDIT: Same issues with 100% clean reinstall using the .62 image. Well, so it’s completely beyond me why others don’t have them.

2 Likes

Started checking it. What I do have though is that I cannot change search provider when using Jolla’s browser settings. So, in this respect, bug is there. However, I must say that I am mostly using Angelfish.

As for this search bug, I doubt its a bug of the port. I would expect it to be overall SFOS bug.

2 Likes

I had a quick Sonnet 4.6 discussion about this, since it’s a bit unclear how much agents people are using here. Maybe it’s useful for establishing a next step to take?

Sonnet 4.6 analysis

This new report is the smoking gun that confirms the root cause. The two bugs are directly connected. Here’s the full analysis:


:link: Both Bugs Share the Same Root Cause: m_searchEnginesInitialized

The “can’t change search provider” bug and the “keywords treated as URLs” bug both trace back to exactly the same gate in settingmanager.cpp:

void SettingManager::setSearchEngine()
{
    if (m_searchEnginesInitialized) {   // ← the single point of failure
        QVariant searchEngine = m_searchEngineConfItem->value(QVariant(QString("Google")));
        SailfishOS::WebEngineSettings *webEngineSettings = SailfishOS::WebEngineSettings::instance();
        webEngineSettings->setPreference(QString("browser.search.defaultenginename"), searchEngine);

        // Let nsSearchService update the search engine (through EmbedLiteSearchEngine).
        QVariantMap defaultSearchEngine;
        defaultSearchEngine.insert(QLatin1String("msg"), QLatin1String("setdefault"));
        defaultSearchEngine.insert(QLatin1String("name"), searchEngine);
        SailfishOS::WebEngine *webEngine = SailfishOS::WebEngine::instance();
        webEngine->notifyObservers(QLatin1String("embedui:search"), QVariant(defaultSearchEngine));
    }
}

setSearchEngine() is the only function that propagates the chosen engine to Gecko. It is called in two places:

  1. On startup when the embed:search/initsearch-engine-added async chain completes
  2. When m_searchEngineConfItem (the MGConf key /apps/sailfish-browser/settings/search_engine) changes value — i.e., when the user picks a new engine in Settings

Both calls are silently no-ops if m_searchEnginesInitialized == false.


:microscope: The Settings Page Change Flow

onClicked: {
    if (title !== searchEngineConfig.value) {
        if (status == SearchEngineModel.Available) {
            SearchEngineModel.install(title)   // needs network fetch first
        } else {
            searchEngineConfig.value = title   // writes to MGConf key
        }
    }
}

When the user taps a System engine (e.g., DuckDuckGo, Bing), it simply sets searchEngineConfig.value = title, which writes to the MGConf key /apps/sailfish-browser/settings/search_engine. This triggers MGConfItem::valueChangedSettingManager::setSearchEngine(). But if m_searchEnginesInitialized is false, the call to Gecko is skipped entirely. The UI combobox updates visually, the MGConf key is updated on disk, but Gecko’s active search engine does not change.


:bar_chart: Complete Picture of the Failure Chain

Clean flash / first start
        ↓
Gecko fires "embed:search/init" with registeredSearches = []
        ↓
m_searchEnginesInitialized = false   ← stays false
m_addedSearchEngines = [Google, Bing, DuckDuckGo, ...]
        ↓
Browser sends "embedui:search/loadxml" for each engine
        ↓
ONE OR MORE engines fail → "search-engine-added" with errorCode != 0
        ↓
m_addedSearchEngines never becomes empty
        ↓
m_searchEnginesInitialized NEVER becomes true
        ↓
┌─────────────────────────────────────────────────────────┐
│  SYMPTOM 1: Keywords treated as URLs                    │
│  → Gecko has no default search engine set               │
│  → "weather" → tries to open http://weather/           │
├─────────────────────────────────────────────────────────┤
│  SYMPTOM 2: Cannot change search provider in Settings   │
│  → User picks DuckDuckGo → searchEngineConfig.value set │
│  → setSearchEngine() called but guarded by false flag   │
│  → Gecko never receives "embedui:search/setdefault"     │
│  → UI shows DuckDuckGo selected, but Gecko still broken │
└─────────────────────────────────────────────────────────┘

:bug: The Specific Code Defect

} else if (msg == QLatin1String("search-engine-added")) {
    int errorCode = dataMap.value(QLatin1String("errorCode")).toInt();
    bool firstStart = m_addedSearchEngines && !m_addedSearchEngines->isEmpty();
    if (errorCode != 0) {
        qWarning() << "An error occurred while adding a search engine, error code: "
                   << errorCode << ", see nsIBrowserSearchService for more details.";
        // ↑ ERROR LOGGED, BUT m_addedSearchEngines IS NOT UPDATED!
        // ↑ The failed engine stays in m_addedSearchEngines forever!
        // ↑ m_searchEnginesInitialized can NEVER become true!
    } else if (m_addedSearchEngines) {
        QString engine = dataMap.value(QLatin1String("engine")).toString();
        m_addedSearchEngines->removeAll(engine);
        m_searchEnginesInitialized = m_addedSearchEngines->isEmpty();
        if (firstStart && m_searchEnginesInitialized) {
            setSearchEngine();
            delete m_addedSearchEngines;
            m_addedSearchEngines = 0;
        }
    }
}

The bug in one line: When errorCode != 0, the failed engine is not removed from m_addedSearchEngines. The list never empties. m_searchEnginesInitialized is permanently stuck at false. Everything downstream breaks.


:white_check_mark: The Fix

The fix is straightforward — failed engine additions should still be removed from the pending list (they’re not going to succeed by waiting), so the initialization can complete:

} else if (msg == QLatin1String("search-engine-added")) {
    int errorCode = dataMap.value(QLatin1String("errorCode")).toInt();
    bool firstStart = m_addedSearchEngines && !m_addedSearchEngines->isEmpty();
    if (errorCode != 0) {
        qWarning() << "An error occurred while adding a search engine, error code: "
                   << errorCode << ", see nsIBrowserSearchService for more details.";
    }
    // Remove the engine from pending list regardless of error —
    // a failed engine will not succeed by waiting, and blocking
    // initialization on it breaks all search functionality.
    if (m_addedSearchEngines) {
        QString engine = dataMap.value(QLatin1String("engine")).toString();
        m_addedSearchEngines->removeAll(engine);
        m_searchEnginesInitialized = m_addedSearchEngines->isEmpty();
        if (firstStart && m_searchEnginesInitialized) {
            setSearchEngine();
            delete m_addedSearchEngines;
            m_addedSearchEngines = 0;
        }
    }
}

Would you like me to open a GitHub issue in sailfishos/sailfish-browser documenting both symptoms and this root cause? Or would you like to go straight to opening a PR with the fix? will be hidden

I’d have to dig in deeper to see if it’s heading in the right direction, but on X10III everything seems to work, so not going to invest deep time immediately.

1 Like

I will further investigate it as well. In my case, I can freely change search providers in Jolla’s browser settings, and I can even install new ones and select them (e.g., if visit DuckDuckGo and search for something there, DuckDuckGo gets added to the list of provides and can be selected) but it has no effect.

Indeed, I’ve just discovered some feedback from Keto who confirmed that Jolla is aware of this issue and they are trying to find out what may be causing it.

So it’s clearly a general SFOS issue, not related to the port. What’s intriguing, though, is that several persons reported that they do not have this issue on their 1 IV’s or 5 IV’s. Well, clearly there’s no use in spending time on it, anyway, it’ll take Jolla to identify it. Maybe indeed that’s the reason why it takes them longer than usual to switch from the current Early Access release to the public one.

As for the Jolla Gallery video playback problem, I will try to further investigate it. Among others, I’ll see if replacing gstreamer decoder libraries from e.g. 10 V would make any difference. If I launch the gallery application from the terminal, I get a warning that “A lot of buffers are being dropped”… Same problem affects e.g. File Browser’s built in video viewer, whereas some other applications, like e.g. mplayer2 based MpvQML or even Android version of VLC player (being the only thing that plays videos inside AAS), play all video formats without any problems and 100% smoothly. I will keep investigating it.

Other than that, the port is rock stable and fully functional. The 1 IV a superb device and this is a really fantastic SFOS port. It really takes seeing how fast e.g. GPS works, how good it is at idle/standby power consumption, how nicely VoLTE works on it (at least with my network I do not have absolutely any problems with 4G, 5G, SMS, MMS, etc.) to understand that already now, with only a few really minor glitches, it is probably among the best SFOS devices/ports of all time. Even the camera already now takes much better pictures than on the 10 III (let alone the 10 V :slight_smile: ). After I setup everything again on this fresh install, I will start to daily drive it.

2 Likes

Yeah, that may be it! Maybe @Keto can take a look at it…

Can you please do it? Thank you! I’m currently away from home with only the 10 III with me, so it’d be a pain to do it.

Any relation to our detective work here?

1 Like

Yeah!

:wink:

+20 characters

Today’s .76 update does solve the problem completely. On the 10 V I downloaded from this latest update the following packages: sailfish-browser, sailfish-browser-settings, sailfish-content-browser-default and xulrunner-qt5 and installing them manually on the 1 IV fixed this issue completely on the 1 IV, too.

I’ve been “daily-driving” the 1 IV for a few days and it is fully stable and funtional - no unexpected issues, freezes, reboots, etc., it just works as it should. Power consumption is very good, especially during standby / idling. It works perfectly OK with the T-Mobile PL network, with literally everything (VoLTE, SMS, MMS, etc.) working. The only (known) problem is with SMS delivery reports not being shown if the phone is registered to VoLTE. On 2G it works fine, so for now I tend to switch to 2G if I need to make sure that the message got delivered.

The only issues that for me are currently important enough to force me to switch to the 10 III for normal working days and play with the 1 IV mostly in the evenings and on weekends are:

  • issues with media playback, both on the SFOS side and on AAS side. On SFOS side, I get normal video playback only in MpvQML player, in the Sailfish web browser and in Angelfish. In all other players (including Jolla Gallery, File Browser’s video player, video previews of the Camera and Andvanced Camera apps, PicoPlayer, etc.) video stutters and freezes after a few seconds, eventually freezing the whole application. It must have something to do with gstreamer codecs, but despite a lot of effort I can’t make it work correctly. On the AAS side, it is even worse as most applications (including all the built-in AOSP ones) do not play neither video nor audio at all. Only applications utilizing their own codecs (like e.g. VLC) play everything correctly.
  • No mobile data in AAS, which prevents me from being able to use Firefox and some Android apps that I need in my daily life while not in WiFi range. Yes, Angelfish on the SFOS side partially addresses this issue, but only partially and its UI is really awkward. I really hope that one day some good people will discover how to tweak mobile data in AAS to work on the 1 IV.
  • For now, despite many efforts, I cannot force the 1 IV to synchronize phone book with my car kit. It pairs correctly and everything else works, only the phone book and recent calls lists remain empty, so it takes making calls from the phone itself and there is no caller ID shown on the car’s display, only the number. I’ll play with it some more using bluetoothctl as it may be my old and picky car kit to blame.

If not those 3 issues (or actually the first 2, which are major obstacles for me), I would fully switch to “daily driving” the 1 IV already now, as other than that it is probably the best SFOS device that I’ve ever used.

5 Likes

Hi, as you might know already, I was lagging behind with a fresher LineageOS build for 5 IV.
I did found the time, and uploaded as (not EARLY) pdx224 build here Release Lineage OS base · sailfishos-sony-nagara/main · GitHub

While this should have been the initial release, since some people running SFOS on 5 IV would need to update, there are some differences in flashing instructions (w.r.t the first time).

Mainly: to be able to update the super partitions you still have to go to fastbootd mode.

And that requires lineage boot, vendor_boot and recovery as initially.

So, you have to use fastboot mode (blue led, vol up + plug cable) to flash boot.img and vendor_boot.img to their respective partitions. Then fastboot reboot fastboot → and flash the rest of the stuff.

THEN you can also flash hybris-boot and its vendor boot back → so that you reboot directly back into Sailfish OS.
If this is not clear, please ask and I can clarify, but you should NOT boot into Lineage OS :slight_smile: Unless you have your backups and are ready to reinstall.


Changes for 5IV include:

  • updated to 64.2.A.2.272 stock blobs
  • activated RIL 2nd slot

That last part will allow eSIM on sailfishos if I am not mistaken, shortly. But first,


Please update the Lineage OS base - because the next Sailfish OS update will be built on top of that.
I have only tested this Sailfish you all have with the new Lineage, not the (not released) Sailfish with the old lineage.
So when I will update the droid-hal... for pdx224 (hopefully soon) I will not be able to say if it’ll work for you if you dind’t update the Lineage base.

:slight_smile:

7 Likes

Here are the questions :wink:
But first thank you for finding the time to catch up and update the linage base.

Do I understand you correct, that, if I have already SF running on the device, I have to do a complete refresh and setup the device anew?

Or is there a way to just flash the new Lineage OS base?

Ah, so I wasn’t clear. The answer is no, you don’t have to.

But to be able to flash the images that are sharing the super partition you need to get into Lineage recovery and switch to “fastbootD” mode.

To be able to do that, you need to flash the boot.img and vendor_boot.img of lineage into their respective partitions. And :warning:this is where it is getting into unknown territory: if you don’t fastboot restart fastboot but simply restart, you will start Lineage and you might get your extt4 /data wiped. :warning: That’s why I recommend backing up what you need anyway.

Then in fastbootd mode, flash the rest of the partitions, the flash back hybris-boot.img into boot and vendor_boot.img (from SailfishOS) and simply reboot.

4 Likes

Now it’s clearer. :smiling_face_with_sunglasses:
And for me this means I will wait a while before doing this. I’m going an holiday in two weeks and need a reliably working device. At the moment my Xperia 5IV is rock solid. I don’t know if I have the time/nerves to fiddle around with the device before holiday, so I will do this update when I’m back.

Anyway it is highly appreciated that you updated the base. You guys rock!!!

1 Like

Updated my 5mk4 successfully. 2nd physical SIM is visible.

3 Likes

I’ve asked before, but nobody answered.
What the hell is that on my frankenstein 5mk4?

dmesg:
On node 0 totalpages: 4654080
Memory: 16933816K/18616320K available (28800K kernel code, 9202K rwdata, 12552K rodata, 2688K init, 2935K bss, 1219656K reserved, 462848K cma-reserved)
$ cat /proc/meminfo
MemTotal: 17451016 kB

Some progress from me:

  1. Video playback. I’ve managed to get correct playback of AVC1 videos in all SFOS applications, (including Jolla Gallery, File Browser’s video viewer, all kinds of video players, etc.) by simply disabling the AVC video decoder in /etc/gst-droid/gstdroidcodec.conf
[decoders]
video/avc=0

It definitely isn’t a proper solution, but at least it makes nearly all videos play correctly on SFOS side, so at least “for now” it’s better than nothing. Now I’m struggling to make AAS play videos in anything else but VLC.

  1. I’ve had serious problems with the “swipe down accross the upper display edge to close an application” gesture, not being recognized most of the time and instead either opening the top menu or the pulley menu. It behaved as if the area to discover that gesture was way too narrow. Adding the missing key

dconf write /desktop/lipstick-jolla-home/peekfilter/boundaryHeight 68

made this gesture work 100% reliable (I haven’t experimented with other values, maybe a smaller area would be sufficient…).

  1. Still struggling to make AAS see mobile data connection…
3 Likes

Hmm.. While preparing to update SailfishOS I notice that the previous build of droid-config-xqcq54 (Xperia 5 IV) was not shipping /usr/share/ssu/features.d/adaptation-community.ini :man_shrugging:

This definitely prevents one to update to the next one :slight_smile:

If that file is missing on your device too, or ssu lr / ssu repos does not show adaptation-community as a repository, then please add it like this

for testing:

ssu addrepo adaptation-community https://repo.sailfishos.org/obs/nemo:/testing:/hw:/sony:/nagara:/5.0/sailfishos_5.0_aarch64
for devel (this is the more unstable version)
ssu add-repo adaptation-community https://repo.sailfishos.org/obs/nemo:/devel:/hw:/sony:/nagara/sailfish_latest_aarch64/

In the other news, if you update or install from the 5.0.0.76 I just published for 5 IV, you will get:

  • kernel changes suggested here for app support connectivity
  • dual sim configuration even for eSIM devices, so you can test if the SimPro | OpenRepos.net — Community Repository System works for you too.
    1. this second one is only available if you also updated the Lineage base to 20260307
      If you had not the time, but still want to try dual sim/eSim, create a file named /overlays/vendor/etc/vintf/manifest.xml and use the contents from this pastebin. The file will be overlayed over /vendor..
    2. The above hack may be available for 1 IV too, but I cannot test. Here’s the diff
      As usual, wait for when @rinigus will have time to update (for dual sim and kernel)
3 Likes

@vlagged so how do we update from 5.0.0.71?

And what happens if I update from 5.0.0.71 via zypper ref and zypper dup on the 1 IV? Is it OK? It shows that 55 packages can be updated.

That is a side effect of the fact that I triggered a rebuild on OBS. Sorry about that, it will generate traffic but it will hopefully not do any harm.

If you have the adaptation-community testing repo above, ssu re 5.0.0.76 followed by zypper ref and version --dup should do it. The newly built droid-hal-xqcq5 packages for 5 IV should show up also with a normal zypper up
After update, reboot. It should reboot twice as it is flashing new kernel at first boot.

2 Likes

@rinigus @vlagged A lot of thanks for the port. I’ve installed Sailfish on my Xperia 5IV and it works very smooth. I love it.

Also, I’ve tried to use esim (@vlagged thanks for last update of lineagebase. The simpro(lpac) didn’t see the esim reader on previous lineagebase), but I’ve got error when simpro(lpac) downloaded profile to the sim. I don’t know on which side this problem is. I’ve read similar issues that people reported on lpac github and developer told that there is can be an issue on cellular provider side. Unfortunately didn’t manage to get esim works on my device. :sad_but_relieved_face:

Right now my daily driver is Xperia 10III, but I want to switch to Xperia 5IV.

1 Like