tdm

I've done a first build of AICP Q using the Lineage 17.1 sources as a base. After it is tested for a while, I will probably try to get official support. The boot image is used just as in the Lineage test builds. Flash it with fastboot, boot into recovery, and then flash the main zip. If you want gapps, I tested OpenGapps pico for Android 10.0. Don't forget to switch slots before flashing gapps. Please report any issues and I will try to sort them out. Boot image for initial flash: http://files.nwwn.com/android/pro1/aicp_pro1-q-boot.img

So I looked up that device and it has a SDM730 chip, which means that this issue apparently spans multiple qcom devices. But it did ship with Android 9, which we also use. I am guessing that her device has been upgraded to Android 10 and the issue is fixed there. So one thing to try, if you can, is upgrade to Lineage 17.1. Nolen has a build if you are interested. Or you can wait a few more days, he is just about ready to switch official builds.

Interesting issue. I poked around a bit and these particular messages are from the camera hal, which we currently take as a prebuilt blob from the stock firmware. So there may be some incompatibility. I could try building the camera hal -- it is open source and does differ slightly from the stock version. What model is your sister's device and what exact software is she running (lineage or stock, what version, etc.)?

I reproduced this issue on test-3. I am trying to figure out if it happens on stock, lineage, both, or neither. The fix should be relatively easy.

Yes it would be possible to ship LineageOS with a locked boot loader. This basically means that the boot loader would ensure that the boot partition (kernel and recovery, mostly) is bit-for-bit as shipped by the factory. It does not necessarily mean that the contents of any other partitions (system, vendor) would be locked. It could be configured to do so, but that requires other security measures -- most notably verity, which LineageOS disables to allow add-ons to be installed. Now, what would that gain you? I'm not exactly sure. I don't see how this improves security unless

There are many considerations to stock/factory software. Here is a (probably not complete) list from someone who has been relatively close to the process in the past but not directly involved: * The software must be cryptographically signed. IdeaLTE has the private device key and, as far as I know, FxTec does not have a copy. So FxTec has no way of generating valid software unless they get that key from IdeaLTE. * The software must be loaded at the factory. This means FxTec would need to provide software in the format that IdeaLTE requires, which is probably not a b

So, a few things here: 1. There is a difference between certification and rooting. SafetyNet is supposed to determine if the device is certified. This means not just rooted, but running stock software that has been certified through Google. 2. There is no single way to detect a rooted device. Each app is coded differently because there is no API for this in Android. Some apps may just look for the presence of /system/xbin/su. Others have more extensive checks. 3. Apps are not limited to just detecting root. Some apps are known to look for things that m

Yes, once we isolate the issue and fix it.

Thanks I'll look into that.

@DieBruine and other keyboard testers, here is a new test image: http://files.nwwn.com/android/pro1/boot-stock-kbd-3.img This switches the irq/event logic to the Lineage code. The remaining differences between this and the official Lineage driver are really just the de-ghosting logic.

I believe the backup page you are seeing is for Google stuff. It does not backup app data or system settings, as far as I know. A fully functional TWRP is one way to do a full backup of your data. However, we do not have a fully functional TWRP yet -- the feature you need to make this work is data decryption, and I have not gotten that working yet. It's pretty high on my todo-list though. If you are familiar with Unix/Linux commands, you can use "dd" (paired with "gzip") to backup your data to a PC. There really isn't any other option to do a full data bac

I never really looked into it. But how much of a demand is there for such a setting? That is, how often do people have the keyboard out and use the device in portrait mode? Seems to me that it would be rather unusual.

IIRC, the keyboard backlight should always be on if, and only if, both the display is on and the slider is out. The keyboard backlight code (and LED light code) is here: https://github.com/LineageOS/android_device_fxtec_pro1/blob/lineage-16.0/light/Light.cpp

No, vold mainly stays the same during a given release cycle.

@npjohnson says it boots and many things work. The two biggest things to fix are radio and camera.

The rear camera issue sounds like a hardware problem. If you get a dmesg from boot, we can look to see if the sensor is detected properly or not. In any case, I suggest that you contact support. They may or may not want you to go back to stock.

First, backup your boot image. If you are on official Lineage, this is the same file that is publish as the recovery. So you can just use that as your backup. Next, download my image and run something like this: adb reboot bootloader fastboot flash boot <image-name> fastboot reboot That's it!

No, the only change you will see is that FN key is exposed.

No, it is not feasible to keep both drivers in the kernel. My feeling has always been that the FN key should be used for the keys marked with yellow symbols. But I do understand that there are only two keyboards available and this leaves many languages without proper support. So I can look into making the FN key "un-dead". That is: Send FN key press and release as any other key. When FN key is pressed and a key is pressed that has a yellow marking, send the following two events: (1) release KEY_FN, (2) press the yellow marked key. When FN key

@DieBruine @raymo and everyone else with keyboard issues... here is an updated boot image. This has all Lineage keyboard code except for the aw9523 key handler. I also fixed the FN key handling. The QWERTZ setting (and everything else) should work now. If this still works properly for you, I will start modifying the aw9523 key handler code to see where the Lineage driver is broken. Boot image: http://files.nwwn.com/android/pro1/boot-stock-kbd-2.img Code: https://github.com/tdm/android_kernel_fxtec_msm8998/tree/lineage-16.0-kbdtest

@daniel.schaaaf the response that @Gigadoc2 has above is spot on. I would only add that instead of requesting changes in the OS to accommodate older apps, it is much better to use updated apps. Unmaintained apps can be a security risk. I know that is not always desirable or even possible, but it will surely be the official position of both Lineage and Google for this issue.

The layout setting may not be working. I'll try to look at that tomorrow.

Correct.

Yeah this. @daniel.schaaaf what write access are you not getting? As for modifying vold, if there is a compelling reason, I can submit a change to lineage and try to get it in. Otherwise it would be local builds only.

Certainly the fingerprint reader works. Google Pay will not work by default. Other users you can make it work by using magisk hide. But I cannot help with that, I don't use magisk.