Leaderboard

Here's mine, finally got it yesterday! Yay! 🙂 (QWERTZ 8/256 GB IGG order from Oct 2020, with the QWERTY 8/256 GB website order from Sept 2019 hopefully arriving soon too, though no tracking confirmation yet.) Coming from a (shifted) QWERTY, 8/128 GB Pro¹ with LineageOS 18.1 (didn't bother to upgrade to 19.1 yet with the Pro¹ X now actually within reach), I thought going back to stock Android would be a significant change for the worse, but so far I don't feel it is. Except for the right/lower speaker dropout problem, I haven't found any issues yet, which of course doesn't

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

Agreed. This is not a manufacturing problem. I would intuitively say this is a bug in 1 line of code in the DSP. Some mundane detail, like a decimal point. 😆

If you install "KeyEvent" you can see the reader generates a 135 / 470, maybe you can map that away similar to the camerabutton 27 / 212 ?

If you run the Camera2 app, it reports for both the Pro1 and Pro1X that it ought to be able to do raw. The biggest difference reported seems to be on video where the Pro1 apart from the QFHD (or 3840x2160) as the highest, it also reports it can do 4000x3000 - does not sound very likely though... So maybe the information reported through the Camera 2 API is simply incorrect.... And that can obviously confuse an app trying to use it.

Import VAT (129.16 € including administration fees) was 22.4% of the perk's original price for me, $679 which did equal 576 € in Oct 2020. Excluding administration fees (111.31 €), it's 19.3%, close enough to Germany's import VAT rate of 19%. I think I missed the 'super early bird' offer only by a few days back then 😉 but I found and find $679 to still have been an excellent price for what it is. By the way, without root, for the time being, and therefore without the ability to use the 'Advanced Charging Controller' daemon and app (ACC/AccA), I've reactivated my 'Chargie' devices to

Doesn't sound like a contact issue for me, either. If it were, the dropout phenomenon wouldn't reliably go away with the volume dialed up, which it seems to do for the people who've been reporting this. Also, a contact problem would produce some kind of noise between loud and silent phases, which doesn't happen here at all. The cuts are absolutely clean. Is there even anyone who doesn't have this issue? I'm no low-level systems programmer, but intuitively I would locate the reason at the bottom of the driver stack, like in the speakers driver, if there is such a thing. Headphones-o

Interesting. I doubt that the sensors are calibrated, to some standard source, so not surprised the numbers are not correct. The two devices could also have a difference in how wide they are getting light . The main purpose of the sensor is to allow for adaptive brightness. But sure would be nice if they (or we?) could calibrate them correctly.

Basically that was one of the things I was fighting for regarding kernel's keyboard driver of Pro1 (it should be the same for Pro1X)... others were not really understand why it can be important...

Regarding LXC, as discussed above, configuring keybindings is a key to make them productive on Pro1/Pro1x. However, at the moment, the Yellow modifiers do not send a keycode (nothing in "evdev_trace -t" on SFOS, and nothing in "xev" in Debian). Therefore, although they work and produce the yellow-printed characters when combined, they annot be used to configure custom system-wide keybindings. Yet, they are the most adapted for that use given that they are replicated on both sides of the keyboard and can therefore be combiened with pretty much every key, including other modifiers. I warned

I removed the part with removing the sensor folder. Since when testing again now i got the same result like you had. I must be mixing up images or something stupid... But the good news, flashing back the unaltered backup worked to solve that. I will add a disclaimer to the Repair part above. Its obviously just for educational purpose to narrow in the solution in the current state. Maybe we just found the reason why it takes F(x)tec so long to get the official documentation out 🤪

Okay! Got Debian Sid up and running in lxc, by fumbling my way through @matf's guide. It works! 😄

Except for the shutter release button not having two steps (which is no problem for my as camera apps seem to start with continuous autofocus anyway), I have not seen any complaints yet with regard to the camera, or were there some? I've only found a small one so far; my preferred camera app ('Manual Camera') does offer RAW mode, but, when activated, either freezes or crashes when I try to shoot. The default 'Snapdragon Camera' app doesn't offer RAW mode to begin with. Neither does 'Open Camera', although it ought to, as long as the camera itself supports it. Might be a b

@KingOfTerrible, Mine is nothing like that. It moves with a firm *click* when I press and completely flat when depressed. Same for the volume buttons. All of those have a high pich "TIK" "TUK" sound. The camera button is similar but muffled sound.

I Installed the App "lightmeter" on my new Pro1X and my old S7. Both are near by on my Desk. As you can see in the Screen they have a huge Differenz on the Same Spot. In the IGG Diskussion i read other Users have the same problem, but at this point there where no Bugreport over this.

That would be true if Android phones would be obliged to come with a light sensor designed and specified to report correct Lux values, but that is not the case. The app is taking readings from a sensor that never was designed for the purpose, just guessing what Lux value those readings might correspond to. If nothing reliable comes out of that, it's not the fault of the phone.

I have a Note 10 that is my primary phone and has never needed a screen protector, but I don't know what kind of glass is in the Pro1X, and I am positive that breaking the screen would be a much more difficult problem than with the Note 10. Regarding sensitivity and touch screen issues, that (and also color and glare problems) are solvable with some UV-curing adhesive, which I have since added to my Pro1X but had not yet done so when I took those pictures. Anyway, with effort and transparent adhesive, a tempered glass screen protector impedes neither the touch sensitivity nor the vis

Latest update: Whatever i remove or add to the partition when mounted like described above, i get a non booting device. Even copying the known working backup sensor data into a copy of the working persist backup, leads to non boot Flashing back the unaltered backup always works. I highly suspect the mount method above leads to file permission problems when copying stuff. From my PoV, all permissions look exactly the same. But the problem must lay in permissions since i copy know working things together and get a complete non boot. I also now know a bit better how i jumped to concl

We also have post talking on the issue over here (though no known fix yet) Oddly it does not seems to be always, I do not think it is a contact-issue though - but could be wrong.

Added a fairly easy way to backup partitions here

The bottom portion here worked for me: https://gitlab.com/ubports/porting/community-ports/android11/fxtec-pro1x/fxtec-pro1x I even flashed all the files from the most recent build copy/pasting the codeblocks, though I do have issues with WiFi starting up not mentioned by anyone else.

This is the phone that made me adjust my hostapd configuration to get HT40 and change to an unused channel. Also it stopped disconnecting after I disabled doze on it. It loses some battery life but it's worth it to me to not lose connectivity. I see log messages with doze enabled: 08-11 11:18:10.517 594 600 E android.system.suspend@1.0-service: Error opening kernel wakelock stats for: wakeup4: Permission denied 08-11 11:18:10.512 594 594 W Binder:594_1: type=1400 audit(0.0:4587): avc: denied { read } for name="wakeup4" dev="sysfs" ino=34968 scontext=u:r:system_suspend:s0 tcontext=

I found a way to backup partitions that also works for windows, with just the usual ADB on the PC. HOWEVER this ONLY works for an unlocked device. ADD: The below only works on Linieage/AICP not stock android, see also this If not unlocked - unlock wiping data, or look for another method.... Make sure that your phone is in developer mode [*], and allows adb to connect as root (the phone does NOT need to be rooted) Connect cable and run (first time you must accept the connection from the pc) adb root adb shell find /dev/block/platform -name "by-name" -exec ls -al {}

For what it's worth, Key Attestation" on my Pro1 with Lineage and Magisk shows "Not supported by this device." Not a big surprise. It has had Lineage or AICP on it since early 2020 and I've never gone back to Stock, so of course I've never noticed. It will likely be the same with my Pro1x. I will probably keep it on stock until Lineage is available. I plan on using my Pro1 as my experimental device (read that learning device). If I find a setup I really like and is stable on the Pro1, then I will try to bring it to the Pro1x. I will see if I can backup the persist partition when I get

I do not know where it should be done, have not come across a place for it browsing around. (I might have the permissions though, if I knew where to try. The tag "KeyMasters" could indicate that I do ) I have suggested the staff to do it some time ago, but I guess that they are either too busy, or disagree. ADD Found this, and I do not see these options, so I assume that is an indication of lack of rights.

I'm not talking about NFC payment apps, just my bank's mobile app and authenticator app. Both of those work fine without attestation, and with enough poking and prodding, even on a rooted device.

I can not guarantee that above is already final since i feel a bit like a lonely tester on this. It worked for me. But no one is around me to save me from jumping to wrong conclusions and build on them 😅

I am very sympathetic with your complaints. That you had to poach a phone that you paid for off somebody else's porch is crazy. And it's clear that the stock Android as shipped isn't designed for thumb typing on the physical keyboard, which is also crazy since thumb typing on a physical keyboard is the entire point of the phone. Even if you did decide to test the Android version out, you may suffer the same faulty speaker issue that I have experienced. But you did answer your own question here. They did give you a heads-up that they would ship Android. And as you could see from the websit

I'm using https://f-droid.org/en/packages/com.davidshewitt.admincontrol/ to disable fingerprint unlock - apps can still use it though.

I am writing instructions for a complete backup thread just now. Copying the data folder from the backup to the stock persist did not work. What worked for me however is to copy the sensors folder from the stock partition to the backup persist. EDIT:

Personally it is not convenient for me (and even there are letters like u/ú/ü/ű), so I set up another layout using the slant arrow which is basically functions like an AltGr for me at both sides (of my Pro1).

I believe we do know the screen assembly is the same

@Caseyis working on QFIL instruction which will be the official way to reflash to stock. The EDL method using EDL.py from BKerler is not perfectly easy to set up but used by the testers since the testing devices went out in may. Generally, the provided EDL image contains .xml files that more exactly define what to do with the images than fastboot could do. In our case the EDL images do not wipe/overwrite the persist partition. Meaning that there is no harm for the keys. But also its not the fix for the OT problem here. I borked my keys by flashing the stock persist image which only go

I'm pretty sure @esialb has a very valid point here in that scratches in the surface may lead to the glass as a whole being weakened compared to an intact display. Think of what you do with a normal glass cutter and plain glass, you basically make a scratch in the surface, and a break then easily occur along this line. And though Gorilla Glass is more complex it is still glass, so some of the same behaviour may be expected.

Yup - recognised on Linux after udev rules amended. Leaving this thread...

Although not with this device, I have seen this exact thing happen when a device for some reason didn't like my USB3/TB4 port in fastboot mode. (Yet it was fine in adb, go figure.) I resolved the problem by plugging the device in question into one of my keyboard USB ports, which are plain old USB 2.0. That being said, the Pro1-X has no trouble with my USB3/TB4 ports, so this may be a red herring.

From what others wrote, out-of-the-box, the Pro1X is not configured for charging in powered-off state (was the same for the Pro1). So keeping it connected to the charger will not fix anything if the battery is completely depleted. The phone should ship with a half-charged battery and ready for action. I think you should contact support.

My phone arrived with around 70% battery. It's bad for lithium batteries to leave them empty, so it's very unlikely yours shipped with a dead battery. I know you said you've tried all the buttons, but just to clarify, the power button is on the right side, in between the volume rocker and the fingerprint sensor. Normally you should not need to hold the power button down for very long before you feel a vibration and the screen comes on with the "powered by android" splash. However, under some circumstances, usually related to getting the machine into odd states during flashing proce

Re: First post: I successfully flashed, omitting the set active command. All i did after receiving the Pro¹ X with Android built 2.1.2 was: 1) Download Ubuntu Touch image and extract the boot.img From this build (2830649718 artifact.zip) 2) Download the SailfishOS 4.4.0.64 devel build and extract the userdata.simg From here (2807435728 artifact.zip) 3) Execute fastboot flash commands fastboot flash boot_a boot.img fastboot flash userdata userdata.simg Happy sailing! Hope this wrap up helps someone.

Great finding, thanks for posting about it. I edited the first post accordingly. Meanwhile, my old container works, it was just a permissions mixup due to my backup/restore procedure: [Edit] Damn, I wrote "Home seet home". What a fail. :<

Final version of the Pro1 case!

When holding my phone in certain positions, my hand rests against the fingerprint reader. When using Chrome, this constantly refreshes the page. I cannot find where this can be disabled.

Hello My Pro1X arrived but i have a problem it doesnt boot. its on charging cable now since 1hour but i get really nervous about it. when i plug the cable in, the red notification light is blinking one time and then nothing no light. screen black. and i can click and hold any button, nothing happens how long i have to charge before the phone starts? is this an issue or is it normal? like a really long first charging time?

Two Pro1-X issues, possibly related. First, the built-in microphone gain is extremely low. it makes my spouse completely inaudible during calls and only barely audible using a sound recording app. When we attach a wired headset, the microphone gain is fine. Second, and this one is really weird, when we're making a call using the build-in mic and earpiece, we can hear the other party just fine _until_ we try to say anything, at which point the incoming sound cuts out completely for anywhere from a fraction of a second to multiple seconds. I assume this is some kind of feedback avoidan

Anyone else observing this? Once paired and connected, I cannot make the phone 'forget' a Bluetooth device. At least not with audio devices which actively try to reinstate a connection with a controlling unit that knows it, like a phone or a laptop. Tried this with a 'Willnorn Soundplus' Bluetooth speaker and a 'Logitech' BT audio adapter for stereo systems. If I tap 'forget' while the device is connected and active, nothing at all happens. If I tap 'disconnect' and then 'forget', the device moves to 'previously connected devices' for a second, then immediately reconnects and

Hello folks. Unfortunately, it's the same song again. I've just received my brand new Pro1X. It looks great, I find keyboard much better than in Pro1 (at least normal position of bracket keys, much better tactile feel). But the right speaker is producing distorted sound, sometimes popping, sometimes silent. Since the sound changes when I press firmly the cover where the speaker is, I'm almost sure the problem is due to poor electric connection. It's the same story I had with Pro1 - fingerprint reader was now working at all, but I gave up and didn't send it for repair for months.

94% battery when I went to bed, 52% when I woke up. And this was with the Debian container frozen. Probably need to work on that. 😆

Just got mine from indiegogo... and the screen is defective. At this point I am ready to tell anyone who will listen to stay the hell away from F(x)tec.