mosen

Indeed, for edl it might be worth to try a usb 2.0 connection. This can be done by using an old cheap usb 2.0 hub if your computers do not offer any @thilo `fastboot fetch` is just not available, sadly. Regarding your backup attempts using adb, its necessary to root android using magisk to be permitted to access those partitions. Its an easy process documented here officially: https://docs.google.com/document/d/1sBS-Taw-3MXrG4lETA6dfuwda8K-9uVlzLhGk46ctzg/edit Or in short, - install magisk from the official source https://github.com/topjohnwu/Magisk - grab the boot.img fitting to yo

@CraigActually, i never bothered to check without root rights. Agreed, the official EDL.py instructions on Bkerlers git do not mention sudo or root. I only now see. But the EDL instructions i followed (the ones you qouted) showed them executed by root, with leading #. So i just did that as of yet while not feeling adventurous and trying differently. Did you try? Does it work?

@maridavAre your sure to not mix up Pro¹ and Pro¹-X intructions and even images? Those are two completely different devices due to different SoC and the Firmware is not interchangeable. For the Pro¹, the unlock command is `fastboot oem unlock` for example. Also, there is no LineageOS for Pro¹-X yet. so i figure you tried to flash the Pro¹ LOS files? LineageOS for Pro¹-X has just now been booted up first time by a dev as reported on Telegram.

@EskeRahn @eorg The recovery is the dead droid. To activate its menu, press the power button and the volume up button. Still, the limitation is that ADB is not fully available in recovery. We can only sideload patches. In the beta group its used to manual sideload local updates from "OTA" packages that are contained in the releases. We even got an alternate fastbootd that can write logical partitions. You can reach that by either `fastboot reboot fastboot` or from the recovery menu item fastboot. @eorg Don't let yourself confuse too much from the evolving threads here. Most things have be

@zaptastici used that second one you linked. But since the method is called Key Attestation, i guess all of those tester apps should do quite the same. You can observe using those, that key attestation is a feature that does not depend on Safetynet/Play Api integrity. But the other way around. Using this Play API integrity checker, you can observe that unlocking the bootloader breaks "Device integrity". Rooting the device breaks "Basic integrity" and missing keys break "Strong integrity". But the pure Key Attestation checker apps you linked above, are happy as soon as they see keys. Not

Updated the first post with warnings regarding the restore of backups. Sadly, i could not identify a pattern in which case restoring a backup works reliably. Even after days of trying and countless reflashes/lock/unlock BL... I managed to put a device in the perilous state where a restored backup with contained keys does not make those usable in Android. And was not able to recover from that state by any means. I documented the way i reached that. But the unsettling thing is, i did nothing different than during the successful restores. Until someone else with deeper knowledge solves t

There is an official Pro¹-X rooting guide using the Magisk boot.img patch method here.

@fxnoma Like Kabouik mentioned, Android sync apps will not work since the SailfishOS android layers do not support to relay bluetooth to the system. On the native sync client side we have Adams Amazfish, originally written to support Amazfit products. But adam maded it nicely modular and now the PineTime and bangle.js are supported as well. https://github.com/piggz/harbour-amazfish Then there is rockpool, providing support for all pebbles. I used that on the Pro¹ for some time. You might have heard of AsteroidOS, a full linux replacement to WearOS on 19 supported watches. The pitty, tho

@marmistrzAdmitted, i am not after the google free experience on this device. I have my privacy sensitive things on the Pro¹-X with SailfishOS. But since the gps reception is miserable on sfos, i thought i'd prepare the Pro¹ as a secondary Navigation and Messenger machine. Thanks for the discussion!

Now activated the google location service that was offered in settings -> location -> location services. And deleted the AGPS cache using gpstest from F-Droid. Lets see what that does.

Ah, ok, that sounds VERY familiar to the situation on SailfishOS. The problem on SailfishOS lies in the AGPS support. Mozilla at some point 3 years ago changed the license model for its MLS. Which ment that SailfishOS users lost celltower based location assitance via Mozilla Location Services. A work around attempt on SialfishOS that never really worked was to manually feed the offline availabe MLS files. But since we are on Android, maybe there is a way to enable the google location service or whatever makes stock android get gps fix instantly?

Thank you @Kaali, much appreciated! I now successfully applied the "sideload magisk.apk renamed as zip" method. I was put off by following the Pro¹-X stock rooting procedure.

@marmistrzI don't think it is necessary even. I was just not expecting that the first fix would take 30 minutes. I tried multiple times around 15 and 20 minutes, then starting to look for a possible solution -> gps.conf. But as soon i got a "first time ever fix" after like 30 minutes and then rebooted, after reboot i had instant fix. This behavior now persists, i get a fix within 30 seconds constantly and i think the issue is explained and solved. Thank you!

Hey all! Trying LOS 19.1 as my first LOS ever on Pro¹. Install went fine including MindTheGapps-12.1.0-arm64-20220605_112439. Flashed to stock android beforehand to start from a clean state. Two problems i am facing: 1.[SOLVED, after some reboots i suddenly got fix without updating gps.conf] I read "GPS fix taking a long time" is due to /vendor/etc/gps.conf. I downloaded a gps.conf that is fitting for my region and should speed up sat-fix. But pushing the file using adb root and adb push gps.conf /vendor/etc/ results in "read only device". I figure adb root is not enough and i

As a fellow linux user, i advise to use the edl.py method explained here. Testers are using this method since month intensly. The windows QFIL instructions are a recent thing to make full reflash possible for windows users. Never tried the QFIL method myself. Always used edl.py as of yet and had no problems. But mind to make backups before flashing anything.

@EskeRahnbut do you see that dead droid logo at any point when doing different volume buttons on reboot? When seeing that, its vol up and pwr to activate the actual recovery menu. Ok, but since you said you sideloaded OTAs you sure have been in there 😛 Just not fully understanding what you mean. Since i figure from what you say you can only reach fastboot bootloader menu and flash the OTA via fastboot? Btw, why are you not in the TG beta channel? 😅 Its ment for both, pre production units and retail units just to test the latest OTAs.

@Ivaylo Hubanov That is an indicator for the sideload mode not being started in recovery. There should be an option in the recovery menu that says along the lines "sideload using/via adb". If you select that, the screen will change to black and only show some white text saying something like push .zip now and showing the command how to do so. (the adb sideload image.file one) When you start sideloading from your computer using this command, it will show progress on the device screen.

Wow, you seem to have a very early version then!? On the testing device i had delivered with 2.0.8, the recovery is reached by holding any volume button during the first seconds of boot. I can not reliably reach fastboot with the volume method, neither on the retail Pro¹-X, not on the testing device. But i always end up at the dead droid recovery start page. To activate the menu of recovery, one has to then press power button and volume up. The menu appears over the dead droid and there we have the option to boot to bootloader and the adb sideload among others.

@Ivaylo HubanovAnother idea. Since your device boots into the F(x) logo and gets stuck there, it is in a state already where OTA changes can influence the boot process. Can you try sideloading an OTA update via adb in the recovery mode? Download a beta OTA from here (not GMS certified) Please note the beta disclaimer. Set device into recovery mode by holding vol down button on reboot. At the dead droid, push pwr btn and vol buttons to activate the menu. Choose sideload via adb. Push the downloaded .zip file using: adb sideload merged-qssi_bengal-ota.zip And reboot.

Thanks already for the confirmation that you found your keys. That's cool and you can pat yourself on the shoulder for not deleting them by chance 😄 However, i understand correctly that you did alterations to all of your backups by copying into all of them at some point? Then it would make much sense that restorecon can also fix all other folders. When you have your device rooted and moved to /mnt/vendor/. Just try the restorecon -nvRF persist on the whole persist. The verbose output will show every file restorecon can relabel and thus put back to context. The -n option is to no

Check here for a method to search for the keys in any partition or image:

That is 100% a matter of having a (backup?) persit partition with keys contained in the data folder. User Ducksoup had a question that also involves identifying whether a partition or image of a partition contains keys at all. To not double post too much, i invite you to read how to check for keys here:

Ok, i am frankly out of ideas to blind diagnose. And the backlog got so long that i would favour to spend time in starting a fresh attempt. My fear is franceso or casey over at the official support tickets will have a lot of work to disentangle what happened anyway and you will likely have to explain every thing over and over. At this point, imo we should compile a sort of issue tracker or support request form/matrix where the most important questions are answered. I have not seen an official F(x) one. So i guess we could help them a lot with such. A good way to achieve a complete list of

I must admit to not having full understood. Imo your case is isolated due to the instructions having been unclear over the last days. And you where possibly lead into some action i can not really follow. First of all, it has never happened to me that flashing a persist that actually contained keys, did lead to the Key Attestation demo app to not show/use them. There is a fix for the sensors folder now (updated in the backup, restore and repair partitions guide). Hopefully this will help everyone with broken sensors only. To debug your case, lets start all over. I would first of all make

Sure! Its just lsusb and the Pro¹-X will show up as qualcomm gobi modem when in edl mode.