I created the fork of the UBSync with included arm64 support - It works, but it definitely needs a revision. I believe, that most of the steps are correct, but especially, the 32bit build needs a re-revision - it should be principally equal as the forked one - the same binaries (I only changed paths to enable multiarch).

Changes are described in README.

I had no luck with including the build process into the package itself because it went me into the dependency hell in the container (given probably by mixed repos in the default container - I'm not experienced enough with clickable and docker to deal with in reasonable time). I also experienced errors (Access Forbidden) with the ubports binaries of owncloudcmd extracted from deb packages. The same I experienced for some of older self-compiled owncloud versions. I finally build v2.5.3 in libertine, extracted binaries and it works.

The fork is now on my GitHub
The 64-bit click package is also there for testing

I found some time for further study, so I have the minimal working example, as I requested several days ago:

.....
        if (QString::compare(service.displayName(), "Owncloud", Qt::CaseInsensitive)) {
            // Initialize SignOn
            QPointer<SignOn::AuthSession> authSession;
            SignOn::IdentityInfo identityInfo;
            identityInfo.setId(ad.credentialsId());
            SignOn::Identity * identity = SignOn::Identity::newIdentity(identityInfo);
            authSession = identity->createSession(ad.method());
            SignOn::SessionData sessionData(ad.parameters());

            // connect response and error signals
            connect(authSession, SIGNAL(response(SignOn::SessionData)), SLOT(signOnResponse(SignOn::SessionData)));
            connect(authSession, SIGNAL(error(SignOn::Error)), SLOT(signOnError(SignOn::Error)));

            // request secret and wait for response signal
            authSession->request(sessionData, ad.method());
        }
.....

/**
 * @brief Accounts reponse
 *
 */
void OwncloudSyncd::signOnResponse(const SignOn::SessionData &sessionData) {
    qDebug() << "Online Accounts response()";

    qDebug() << "  -> login: " << sessionData.UserName();
    qDebug() << "  -> password: "  << sessionData.Secret();
}

/**
 * @brief Accounts reponse
 *
 */
void OwncloudSyncd::signOnError(const SignOn::Error &error) {
    qDebug() << "Online Accounts response()";
}

I'm currently working on the redesign of the Ubsync app to bring multi-user support and improve the application architecture. The QML part is almost done, however, an important subtask is to remove plain passwords from the config file. The current version of the application stores the username/password to the config file to provide it to the backend (online accounts are only implemented in QML), however, this is not a very good approach.

I was able to access account details using libaccounts-qt5, but I'm stuck with authentication with signond to get username/password.

I'm not very experienced in QT and my knowledge about signond is limited (causing great confusion even I tried to learn from the poor docs and accounts-qml-module code ).

Working code snippet is below:

#include <Accounts/Account>
#include <Accounts/Application>
#include <Accounts/Manager>
#include <Accounts/AccountService>

...

#include <SignOn/AuthSession>
#include <SignOn/Identity>

...

    Accounts::Manager *manager = new Accounts::Manager();
    Accounts::Account * account = manager->account(accountID);
    qDebug() << "  - Account: " << account->displayName();
    qDebug() << "  - Keys: " << account->allKeys();
    qDebug() << "  - Host: " << account->value("host");
    qDebug() << "  - CredentialsId: " << account->value("CredentialsId");
    qDebug() << "  - enabled: " << account->value("enabled");
    qDebug() << "  - name: " << account->value("name");
    qDebug() << "  - auth/method: " << account->value("auth/method");
    qDebug() << "  - auth/mechanism: " << account->value("auth/mechanism");
    qDebug() << "  - ChildKeys: " << account->childKeys();

    Accounts::ServiceList services =  account->enabledServices();
        foreach (Accounts::Service service, services) {
            qDebug() << "  - Service: " << service.displayName();
            if (QString::compare(service.displayName(), "Owncloud", Qt::CaseInsensitive)) {
                qDebug() << "    -> owncloud ";
                Accounts::AccountService * as = new Accounts::AccountService(account, service);
                Accounts::AuthData ad = as->authData();
                qDebug() << "    -> authData " << ad.parameters().keys();
                qDebug() << "    -> cID " << ad.credentialsId();
                qDebug() << "    -> DOM: " << service.domDocument().toString();
                // TODO - get username and password from libsignond using ad.credentialsId()

            } else if (QString::compare(service.displayName(), "Nextcloud", Qt::CaseInsensitive)) {
                qDebug() << "    -> nextcloud ";
                // TODO
            }
        }

Could anyone provide a minimal example to access password using libsignon-qt5?
Thank you!

@antidroid for SNAP, it is here: ~/snap/ubports-installer/current/.cache/ubports, however, the messages are not very helpful for someone begining with ubports

I reported it - it might be an issue for new users with newly adopted devices

@applee @usenix The problem actually was, that there was empty stable channel for jasmine_sprout (no release in this channel), but the installer offered it.

Currently, there is the first release(OTA-16) in the stable channel (http://system-image.ubports.com/16.04/arm64/android9/stable/jasmine_sprout/index.json)

To be honest, currently, the ubports ecosystem is somehow foggy for someone who is not familiar with it... actually, it took me some time to get into and get basic understanding of the dev cycle and resource location. This little piece of information is provided by ubports docs, while the good explanation is e.g. here

If I'll find some time, I'll try to document what I learned, because I started to like ubports, but currently, I invested my allowed hobby time into learning and doing this, and unfortunately I'm currently loaded by too many things ...

@totalsonic Aha, have you tried to replace the daemon configuration? If you had the previous version and you still have old config, it will not work. The paths are now different, as it was necessary to unify them to enable multiarch: is this issue helpful?

@totalsonic Well, I think this is just the "information", not "error" about starting the service. However, I also experienced troubles with starting the service, which were solved by service restart(s) ... I have only "ported" and "multi-arched" the build process, but unfortunately I don't have experience with the app.

@ernest As pointed above, I guess, there are severe issues and inconveniences related to the QT application or the service, unfortunately I have very limited experience with QT a QML. My current job limited to the build process and "grep&replace" code snippets. On the other hand this app looks to be essential for many users trying ub-touch (including me)... I agree, lets try to remove the "worst case issues" and somehow push it to the open-store.

@ernest I shared my telegram alias with you through the chat

I created the fork of the UBSync with included arm64 support - It works, but it definitely needs a revision. I believe, that most of the steps are correct, but especially, the 32bit build needs a re-revision - it should be principally equal as the forked one - the same binaries (I only changed paths to enable multiarch).

Changes are described in README.

I had no luck with including the build process into the package itself because it went me into the dependency hell in the container (given probably by mixed repos in the default container - I'm not experienced enough with clickable and docker to deal with in reasonable time). I also experienced errors (Access Forbidden) with the ubports binaries of owncloudcmd extracted from deb packages. The same I experienced for some of older self-compiled owncloud versions. I finally build v2.5.3 in libertine, extracted binaries and it works.

The fork is now on my GitHub
The 64-bit click package is also there for testing

Hello all!
I just won a fight with the A2 installation process

After many iterations with the installer, I successfully installed it from the "devel channel".

I tried to replicate all steps mentioned above, but for a long time with only a little success.

The part of the process running "in the" fastboot (almost) always finished well: in short I have a working ubports recovery. The only two inconveniences I observed here:

• there is the vendor.img checksum mismatch - this is probably only a mistake in the config file (old checksum and updated file ?) - it is possible to ignore, but it's a security issue
• the installer "requested" reboot to "bootloader", but "fastboot" was in reality required - I noticed when I was in the bootloader and the installer said something like "fastboot is waiting for device"

But what I observed too many times was the following error:

• the installer (almost) always hangs when I was already in recovery and the installer was trying to download ubuntu touch with the following error:

Error: systemimage:install: Error: Failed to download latest version TypeError: Cannot read property 'forEach' of undefined

I was successful only with the devel channel and even with the devel channel only in "some cases".

After a "successful" installation, the device stuck about 3-times in the "boot screen", the 4th "completed" iteration (after a few iterations terminated with the error above) was successful.

I tried from two locations with different network configurations...

I believe, that the root of the problem would be in the config file and/or remote repository accessibility, but I'm unable to perform diagnostics without deeper knowledge of the UBports ecosystem (which I do not have).

During the debug process, I was trying to find the instructions for the "manual installation" - could you provide it or point me to its description? I believe, that I'll be able to provide a closer analysis of what happened to report it using the manual process.

Is the "stable" and "rc" channel available for this device or it is not - I was unable to locate it (based just on the brief docs study).