Leaderboard

I personally believe that we will. This is mostly hope, not evidence based, but in my experience, while they may take time, FxTec always delivers. But I'm sure I have a reputation for being overly optimistic. 😉

@mosenok, so while stuck in the boot logo I was trying to restart the phone, but dropped the button before it actually restart and it seems something triggered in the background and phone booted android properly!!! 🎆🎉🙈 So now I'm on the backup step then going back to try and flash Ubuntu Touch 🥵

I'm now going to try the recommendations from here: https://piunikaweb.com/2020/11/05/android-11-default-launcher-setting-gets-reset-for-multiple-users/ Didn't work 😞

I did a restore using google backups and have the same issue.

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.

No, I always made a copy and modified that copy. One of the originals was only ever copied, while the other was mounted read only at some point to copy from the backup into the stock image in an attempt to put the keys on the stock image. Regardless, I will try restorecon and see what happens 🤞

My backup persist does have keys in it. My persist flashed onto the device (for now) does have keys in it. restorecon relabeled everything. After a reboot, I still don't have attestation. restoredon did fix the sensors though. I've never touched the backup persist. Even my read-only explorations of the image have been performed on a copy.

It is highly advised to take a backup of your device specific partitions right after you receive the device. Update 20220829: tl:dr: Community has not found a safe way to restore backups as of yet. Making below described backups is still highly advised for a future where some wizard found a reliable way to restore those backups. For now, if you have broken sensors from flashing another OS, the restorecon method described in the "Repair sensors/ folder..." section does 100% work to fix those while retaining your attestation keys. While restoring any backup has a high chance to make the keys

I haven't heard about the existence of clandestine OTA updates happening in the background, and I have no reason to suspect my phone would have had any such update in the short while that I have it. That said, I have no idea what has been happening here, either, but, purely speculatively, I could think of some things. Like some kind of speaker calibration happening in the first days of usage, with some usage data gathered and the driver behaviour changing slightly according to the collected data. I have no idea why anyone would program something like that for something as simple as a speaker,

I successfully read a tag that stored a Wifi config. Try using the top left of the phone

It takes longer to type or copy a command and it gives you the chance to do it wrong and both of these things are seen as "bad" when it comes to officially supporting something. It's copying - either it works or it doesn't and both methods do so why would you want to mess around installing windows, drivers and reading licenses when you could just use a simple tool 🙂

I get asked on every boot, so to me it looks as if some setting is not persisted.

Tried Lawnchair, same thing happens. Looked at Nova's settings which indeed was 'battery optimised', but disabling that didn't help. When the selection dialog appears, it's system modal, but when I choose another launcher to go on with and then check Nova's info, it still is stoppable. My suspicion for now is that copying the Pro1's configuration over to the Pro1X (from Google's backups with the Google app on setting up the phone) carried over some hidden settings which are not compatible, even though both are on Android 11 (only that the Pro1 obviously was running LineageOS and t

You are welcome, for details see this.

This is a sad topic to read. I fell in love with LinageOS 18.x on my Pixel 2 XL and if I wanted I could flash to 19.x even and get Android 12 based on that old phone. I do hope we eventually get support for LinageOS 19.x on the Pro1-X

no no the bootloader is there, but selecting recovery within it fails. I see exactly the same on my retail Pro1 (no X), that has only had OTA updates.

will do

@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.

After seeing all the quick replies I decided I would open it up and just check it out (after finding a thingiverse possible case solution). Everything works perfectly (well I haven't tried to charge it yet, or traveled away from my home): wifi seems as good or better than my 2XL, Verizon works when swapping SIM from my old 2XL (calls in/out, text in/out), speakers sound good, screen rotates as expected... Really I am starting to feel good about this device...I still want LinageOS so I don't need to have all the Google default cruft, but still being ASOP basically the phone is quick and

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

This is my situation, I have two backups of my persist partition, from when the phone had broken sensors but working attestation keys. They contain a data folder (with files similar to yours) and have only been copied (so I could modify the copy) or mounted read-only (to copy files from). restoring any of my persist backups with the data folder does not restore the attestation. I'm not at my PC until tomorrow night, but I will try out the restorecon method on the data folder when I get back.

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

Send an e-mail to f(x)tec asking for support. E-mail: info@fxtec.com

Strictly EDL on the Pro¹-X. Its very convenient not having to unlock the bootloader to flash imo. Having much experience with fastboot from doing user support over at AsteroidOS. I am using and debugging Fastboot a lot and i really appreciate to now learn about EDL more. In AOS, we don't have rooting problems 😛 We even got our very own universal community bootloader with integrated adb server. So debugging a WearOS smartwatch and prepare it for porting is as easy as "fastboot --cmdline debug-ramdisk boot aos-bootimage.fastboot" to boot into the bootloader and have full adb. Where is the mag

I have Droidian on a Pro1 since last year, and on a Pro1x since last night. Droidian hasn't been a daily driver for me (mostly due to battery life and the fact that I'm not friend with the ergonomics of Phosh) so I don't know everything about it, but feel free to ask questions. I have played with it somewhat actively last year to get alternate WMs working (Sway doable with some work, and with issues, i3wm doable too with a X hack), LXC (doable with Sway as WM but the keyboard mapping caused issues for my keybindings), Waydroid (Droidian may have the best support for it), or simply install

Sorry, still traveling. Quick clarification, i did back up all mentioned partitions since i was advised so by someone that all of those are device specific and might help in the future. For now, i only played with restoring persist. That one always restored fine. I flashed like 20x back and fourth testing several broken states that lead into non-boot situations. But was always able to get back to the backup state.

As far as I understand, IMEI and whatnot should be in fsc, fsg, or more likely modemst1 and modemst2. Don't quote me on that though.

FWIW, I did not back up persist until after it was "damaged" to break the sensors. However, when I flashed back everything stock except persist, using the edl Python tool and the process described here (I edited the xml to skip persist), I did still pass attestation in Android. Then, I used fastboot to flash the stock persist.img, thus fixing sensors and breaking attestation. Finally, I used fastboot to flash back my saved persist, and did not regain attestation. I performed additional tests using QFIL to flash full stock image back, and then fastboot to replace persist with my bac

If no one else find a solution before that, I plan to try to backup everything from the retail unit that I hope to get soon, as well as the early unit in the state it is, and then see If I can wipe the early unit completely with Casey's guide, and attempt to transfer the keys. It might not work as the 'serial numbers' (imei, mac etc) could be saved somewhere completely different, and they just might have to match the attestation keys... I do not know. https://forum.xda-developers.com/t/info-android-device-partitions-and-filesystems.3586565/

Mosen definitely backed fsc, fsg, modemst1, modemst2 and persist (which I advise to do as well, they're only taking up 40MB of storage space on your disk), but I don't know if he restored them all.

Indeed and maybe also what he did not *LOL* That is more precisely narrow down the difference between what @ducksoup and @mosen did. Since restoring the Persist helped Mosen, we can conclude that it is needed But since it did not for Docksoup, we can also conclude that restoring it is not enough. Maybe it is HOW they did the backup and/or the restore that was different? e.g. file rights, Maybe what Ducksoup did 'damaged' more than what Mosen did? Maybe Mosen restored something else, that also matters? It will require more thorough tests to say for sure what

Thanks for your neutral review! The camera issue when keyboard is open is fixed in a later update if I remember correctly, that you could get as OTA soon (hopefully) or in the beta program (see other thread here).

I've seen other benchmarks which, all in all, attested the SD 662 only slightly lower performance compared to the SD 835. From that I would expect to hardly notice any difference at all in actual use, perhaps with the exception of a rare app that heavily uses one of the operations for which the difference is more significant. On the other hand, that's only the CPU; the GPU is substantially slower indeed. Still, as of now, the Pro1 X doesn't feel any less snappy to me than my old Pro1. But then again, except maybe for the BB PRIV, I never used anything but midrange phones which always performed

Sorry, we'll just have to agree to disagree. Where you see "intentional false information," I see overly-optimistic estimations, which, when they don't pan out, they get beat over the head with it. No wonder they kept communication less frequent until they got close to a real production phase. And of course hardware "quirks" would affect software, if the software has to use that hardware that is being fixed. My guess would be a that pre-production models went out in June. I don't know this, but that seems to be about when hardware tweaking was mostly done and the big concern was g

Tried to do them on a Pro1 and Pro1X single core Pro1: 394 Pro1X: 307 multi-core Pro1: 1604 Pro1X: 1294 compute (opencl) Pro1: 1943 Pro1X: 383 compute (vulkan): pro1: Fails, 408 (0 on Horizon detection) pro1X: Crashes the entire app And the big difference is in the GPU parts only

well, with respect to your numbers, mine seem to be on the optimistic end of it. So I'm putting the Pro-1X in the best light possible.

To me it make sense that they have taken a principal decision not to tell what is going on. If they did, they would have endless questions on how far they have come, and if it would be possible to get an early version for testing et cetera. It make a lot of sense waiting to they have something fairly close to an acceptable version. But that said I'm (also) impatient and would love to have an idea on when we will get it. It is like the Pro1X it self, worth waiting despite felling that the waiting time is killing us....

To put "for the most parts" into numbers - here is Geekbench5 on a 825 (that is a $400 phone from 2016, the 835 from the initial Pro1 should be ~30% faster) vs. the Pro-1x: single core 825: 326pts pro-1x: 307 oneplus 9 pro: 1075 multi-core 825: 812 pro-1x: 1280 oneplus 9 pro: 3389 compute (opencl) 825: 1610 pro-1x: 381 onplus 9: 3541 samsung galaxy S21: 6990 compute (vulkan): pro-1x: crashed (I tried twice) Regarding "normal use", all I can say after testing for ~2hrs is: build quality is very nice speakers very decent

If you are lucky... otherwise that Pro1 would has been also converted to Pro1X... I would still wait for LineageOS... support also did not come too early for Pro1 but it is a much better system. I hope there are some work in the background and Pro1X will also get official LineageOS support, it would worth a lot.

More ram, new camera-chip, an over three years newer chipset that will get security updates, and a two major versions newer Android too.... For many that alone says update. My daily driver has since 2019 been a retail Pro1 on stock android. And when I get the retail Pro1X as I perked for, I expect it to take over, and demote the Pro1 to tests (and as a backup device) But sure for some power hungry tasks the Pro1X is slower. But for a lot of tasks the difference is minor. Not unusual that an older flagship is close to a newer midrange chip. Have a look at e.g. this https://nanoreview.

Thanks for the workaround, I have marked your post as recommended, hopping that other will see it. And pinned this thread.

Yeah, I´ve read somewhere that the default launcher includes some basic functionality other launchers rely upon, too... so disabling is not recommended... 😕

I suppose the camera button is connected to the default camera app like it used to be on the Pro1. Problem now is, starting with (stock) Android 11, changing the default camera app is not possible anymore for alleged security reasons. One of the many Android changes over time which artificially limit the versatility and reduce the usability of our phones.

Thanks so we now know that it is important but NOT sufficient to backup the persist partition, so now the big question is what ALSO should be backed up? (And without the ability to add key-attestation, it is hard for us to test, unless we initially backup EVERYTHING from a device that still got the keys....)

Same situation here. I had broken sensors, but working attestation, but then when I reflashed my persist backup, which ostensibly valid keys, I lost attestation.

on the geekbench, take their results with a truckload of salt. look here for the Pro1 https://browser.geekbench.com/search?utf8=✓&q=fxtec Results vary from 152 to 394 for single core, and from 513 to 1754 on multi. Both Vulcan and OpenCL results vary with a factor of two. I'm trying to running it on the Pro1 and Pro1X. The Pro1 failed on the Vulcan, something with horizon.

For the most part yes. The Pro1X got the newer supported snapdragon 662, the Pro1 got the 835, that is no longer supported with security updates. It is not easy to get a Pro1, and as a consequence those sold are not cheap. But If you are lucky and find a user that plan to only use stock Android, the Pro1X is an update, you might be able to arrange some swap.