Pro-1x in Android does not go into landscape mode, ever

[steeb 27]

Hey everyone,

I just got my Pro-1x today, and since I ordered it with Ubuntu, I immediately flashed Ubuntu and played around with it. Ultimately, I decied that if I wanted to use this phone as a phone, I need to re-flash Android. I did a factory reset, and hurray, I have Android again. But now the sliding out the keyboard does nothing. This functionality worked fine in Ubuntu; hell, it worked fine in Sailfish when I played around with it, but in the stock Android sliding out the keyboard does absolutely nothing. The home screen doesn't rotate, the browser doesn't rotate, and although the keyboard works, it's not particularly useful with the screen rotated 90 degrees.

Am I missing something obvious? There are no available OS updates and I even re-flashed with the stock Android image from "ROMs" thread elsewhere on the forum.

[ducksoup 110]

See this post, unfortunately probably too late.

Hopefully someone else knows how to fix that problem without a persist backup.

 

[EskeRahn 5,399]

1 hour ago, ducksoup said:

See this post, unfortunately probably too late.

Hopefully someone else knows how to fix that problem without a persist backup.

 

Maybe you should make a separate thread on what to do switching FROM stock Android, that I can link to in the ROM thread? As this seems generally crucial/useful.

[ducksoup 110]

Just now, EskeRahn said:

Maybe you should make a separate thread on what to do switching FROM stock Android, that I can link to in the ROM thread? As this seems generally crucial/useful.

Honestly I'm not the right person to do that.  I'm very much "learning as I go" here myself.  It's a good idea to have such a thread, but I kind of wouldn't know where to start.  😄 

[ducksoup 110]

1 minute ago, toast said:

Shouldn't it pretty much be the manufacturer's job to supply instructions that make sure not to render the users' devices permanently defective if used in the way intended?

Agreed, although to be fair, when they posted the factory ROM file, they did specifically say "instructions not ready yet".

[EskeRahn 5,399]

4 minutes ago, ducksoup said:

Agreed, although to be fair, when they posted the factory ROM file, they did specifically say "instructions not ready yet".

Yes, but note that this is a user-to-user forum where FxTec only occasionally are active. But sure would be preferable if they provided the info.

I will add 'something' for now....

[ducksoup 110]

Just now, toast said:

Lets just hope that there is some way to restore it, somehow, for those that already made the same mistake.

Indeed.  While this specific topic isn't something I know a whole lot about, I have seen persist-wiping incidents with other devices, and they've always been recoverable, but have sometimes required some help from the manufacturer.

[EskeRahn 5,399]

Added 'something' at the top of this on backup of the persist partition.

https://community.fxtec.com/topic/3207-various-roms-available-to-the-pro1pro1x-available-for-download-links/

Please correct me if what I wrote was wrong. @mosen, @ducksoup, @steeb and I will have it changed ASAP.
 

[ducksoup 110]

Looks good to me, from what I understand on the subject.

[mosen 201]

Yes, its fine.
The sensors getting "lost" is due to UT and sfos altering the persist partition afaiu. The keys are not touched in that process.
Only when attempting to fix the sensors for stock android by flashing the wrong persist.img, the keys get lost since the stock persist image only contains the correct sensor settings. But not the keys.
Flashing your own backup with keys and stock sensor config is what ultimately fixes the problem correctly.

Also the EDL flash does not touch your keys (but not fix sensor too) unless you falsely use the contianed .xml.bak to flash which completely overwrites the persist with the stock image.

[EskeRahn 5,399]

5 minutes ago, mosen said:

Yes, its fine.
The sensors getting "lost" is due to UT and sfos altering the persist partition afaiu. The keys are not touched in that process.
Only when attempting to fix the sensors for stock android by flashing the wrong persist.img, the keys get lost since the stock persist image only contains the correct sensor settings. But not the keys.
Flashing your own backup with keys and stock sensor config is what ultimately fixes the problem correctly.

Also the EDL flash does not touch your keys (but not fix sensor too) unless you falsely use the contianed .xml.bak to flash which completely overwrites the persist with the stock image.

Thanks, i know next to nothing on edl. Could you please make a full guide of how to get edl, And how to use it for backup and restore of the persist. Preferably in a separate thread, I can link to.

[mosen 201]

@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 got the sensors configured correctly but contains no keys.
The right way would have been to make a backup of my devices persist incl. key while the sensors had stock config. To manually flash that back over the UT/SFOS alternated persist, instead of using the stock one.

An EDL cable is not required. The procedure described below the edl.py install is effectively doing the same like an EDL cable.
The EDL cable just puts a device into EDL mode. EDL cables can easily be made DIY, Just look up YT.

Install edl.py from: (Copying the install instructions below for convenience.
https://github.com/bkerler/edl

# Debian/Ubuntu/Mint/etc
sudo apt install adb fastboot python3-dev python3-pip liblzma-dev git
sudo apt purge modemmanager
# Fedora/CentOS/etc
sudo dnf install adb fastboot python3-devel python3-pip xz-devel git
# Arch/Manjaro/etc
sudo pacman -S android-tools python python-pip git xz
sudo pacman -R modemmanager

sudo systemctl stop ModemManager
sudo systemctl disable ModemManager
sudo apt purge ModemManager

# Actual install on all OS
git clone https://github.com/bkerler/edl.git
cd edl
git submodule update --init --recursive
sudo cp Drivers/51-edl.rules /etc/udev/rules.d
sudo cp Drivers/50-android.rules /etc/udev/rules.d
python setup.py build
sudo python setup.py install

Then download the 2.1.2 stock images from this google drive. Its the one F(x)tec released last week
https://drive.google.com/drive/folders/1_sgQ64ef9Di9kJ63Y6WNqllGRgRFOjac
Unzip and open the folder containing the images and .xml files in a Terminal.

 Put Pro¹ X in EDL mode using

adb reboot edl

when you got adb available. Or connect your EDL cable now to automatically boot the device into EDL mode.
Else, for the manual finger combo method:
Hold power and vol + and vol - During boot and release all after android logo flashes up shortly and goes into a dark screen second. If it stays dark after you removed the combo and does not boot, show recovery or fastboot menu, Pro¹ X is in EDL mode.
If it is booting or showing fastboot or recovery (dead droid logo), redo. I needed some tries first.

Check if the usb connected Pro¹ X is in EDL mode:

lsusb

It should show:

Bus 003 Device 011: ID 05c6:9008 Qualcomm, Inc. Gobi Wireless Modem (QDL mode)

Then become root or do the following with sudo each:

edl --loader=prog_firehose_ddr.elf --memory=ufs qfil rawprogram_unsparse0.xml patch0.xml .

edl --loader=prog_firehose_ddr.elf --memory=ufs qfil rawprogram1.xml patch1.xml .

edl --loader=prog_firehose_ddr.elf --memory=ufs qfil rawprogram2.xml patch2.xml .

edl --loader=prog_firehose_ddr.elf --memory=ufs qfil rawprogram3.xml patch3.xml .

edl --loader=prog_firehose_ddr.elf --memory=ufs qfil rawprogram4.xml patch4.xml .

edl --loader=prog_firehose_ddr.elf --memory=ufs qfil rawprogram5.xml patch5.xml .

If any of the commands get stuck, redo the finger combo and enter EDL again.

I did not need to do that since all went well with original cable and Pro¹ X not touched during flash.

Reboot Pro¹ X  with

edl --loader=prog_firehose_ddr.elf reset reboot

Please only follow this procedure if you are used to the command line.
Mind for instance the dots at the end of each flash command.
If you do not feel confident, wait for the official instructions using QFIL.

Will add backup and restore instructions for individual partitions in a new Thread. Sorry, just read the suggestion now.

Edited August 12, 2022 by mosen

[sspiff 29]

So, I'm in the same boat. I've flashed a recent UT build, didn't work.

Then I reset by following these instructions to restore to a booting phone, and to try out SailfishOS instead. On Sailfish, everything seemed to work, apart from the lock screen rotation when flipping out the keyboard bit. Normal rotation worked fine based on the gyroscope, so I didn't really think much of it other than "early community build".

After deciding the software ecosystem on SFOS is a bit spartan, I decided to hold out for a more mature, working Ubuntu Touch build for the phone, but go back to Android in the mean time. Now I have no rotation, neither from sliding out the keyboard or tilting the phone. It does detect the slide mechanism, because it lights up the display. According to the software, it seems it thinks the keyboard is always active, because it never shows the virtual onscreen keyboard.

I really hope this is recoverable. I would hate to have waited 2.5 years for this phone, only to receive it with a slower SoC and brick a crucial feature of the phone on day #1.

Edited August 12, 2022 by sspiff

[mosen 201]

If you did not overwrite the persist partition, this could be recoverable.

More competent people than me are currently looking into how to fix just the sensors in backuped persist images.
You can check if your keys still exist, for instance with the "Key Attestation" app from playstore.
It shows "Not supported by this device" when no keys are present. Any other view in that app is fine.

And it does not really help to state, but the Hardware Key Attestation is very rarely used by any apps currently.
On the Pro¹ X i lost the keys on, SafteyNet still works when locking the bootloader. Did not try Gpay or such however.

Edited August 12, 2022 by mosen

[sspiff 29]

2 minutes ago, mosen said:

And it does not really help to state, but the Hardware Key Attestation is very rarely used by any apps currently.

On the Pro¹ X i lost the keys on, SafteyNet still works when locking the bootloader. Did not try Gpay or such however.

I installed Key Attestation and it shows "Security level: TrustedEnvironment"

[eBrnd 1]

I guess I broke it on mine. I flashed the persist.img from the stock rom archive in order to bring back rotation and keyboard backlight*, which worked. However, I get "Not supported by this device" from the Key Attestation app.

*) I thought I had already wiped my persist at that point by installing Ubuntu and Sailfish, but apparently that wasn't the case. Bummer.

[sspiff 29]

3 minutes ago, eBrnd said:

I guess I broke it on mine. I flashed the persist.img from the stock rom archive in order to bring back rotation and keyboard backlight*, which worked. However, I get "Not supported by this device" from the Key Attestation app.

*) I thought I had already wiped my persist at that point by installing Ubuntu and Sailfish, but apparently that wasn't the case. Bummer.

Sucks 😞 I made a backup of my persist partition and I notice they're just ext4 partitions. I guess copying the right files from one to the other would resolve it.

I wonder what happens  when you flash the same keys to multiple devices? 🤔

[mosen 201]

They are crypto keys that get checked against or contain the serial of the device or the IMEI. As far as i figured from diving into Android Developer Docs.
I tried to "clone" a testing devices persist with keys to the production Pro¹ X with lost keys. But that did not work.

But yes, the partitions being ext4 should mean we can copy the keys from a backup with broken sensor config.
Afaiu, thats whats being tried currently. Maybe it will be a dd method where we merge the working parts into a new persist.
Fingers crossed.

[mosen 201]

Good news. It has been done.

I am not at a computer currently but essentially what people in the Pro¹ Telegram group did is to copy the whole Data folder from the persist backup to the stock persist image.
Will be able to test later today.

[steeb 27]

@mosenOh that's fantastic news. I did just check w/ the Key Attestation Demo app and I do in fact still have my keys, which I backed up immediately. I'll be keeping an eye on this thread and the main forum for a solution when someone with a bigger brain than me figures it out!

[sspiff 29]

3 hours ago, mosen said:

Good news. It has been done.

I am not at a computer currently but essentially what people in the Pro¹ Telegram group did is to copy the whole Data folder from the persist backup to the stock persist image.
Will be able to test later today.

I'm going to try that later as well. Thanks for the tip.

[mosen 201]

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:

 

Edited August 12, 2022 by mosen

[JECE 24]

Guys, this is all incredibly hard to follow. I don't plan to flash custom ROMs until F(x)tec says that they're ready, so I hope that they release good instructions by that point. But in the meantime, do the backup instructions outlined above have anything to do with the backup instructions found here?

And what is the difference between Google Mobile Services and Google Play Services, anyway? I know about the limitations of using a device without the latter, but not the former.

[sspiff 29]

58 minutes ago, mosen said:

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.

Copying the sensor data from the downloaded ROM and then flashing (using `edl w persist persist_backup.img`) did not fix the keyboard & rotation for me.

I did not remove the directory before copying the stock sensor files into it - so it still contains more files from my backup, not just the files from the stock ROM. Should I remove the directory and replace it with the stock ROM files only?

[mosen 201]

1 hour ago, sspiff said:

Copying the sensor data from the downloaded ROM and then flashing (using `edl w persist persist_backup.img`) did not fix the keyboard & rotation for me.

I did not remove the directory before copying the stock sensor files into it - so it still contains more files from my backup, not just the files from the stock ROM. Should I remove the directory and replace it with the stock ROM files only?

Yupp, sorry for the salami tactic.
I have written a guide. But that just worked for me. No guarantee that i did not mess up at some point while testing to come to the conclusions.
Happy to get corrected.