LineageOS, Current status : 16.0 Test Builds

[tdm 2,322]

Yes there will be an official lineage build. But first all the major issues must be resolved. And as you have found, there are a few. I think everything you mentioned is a known issue. Look on my lineage page for the git repos and issue tracker link.

 

I'm working through the issues as I can. I do this in my "spare" time and I'm not paid except for having been given a device for development.

 

As you may have noticed, I'm working on quite a lot more than just lineage. I've released a factory restore tool that has saved at least a dozen sailfish victims from bricking their devices and released a version of stock without Google apps. Currently I'm rewriting the keyboard driver to make it work better for everyone. That's pretty much done -- I had thought I was done this morning but @netman schooled me on detecting ghosting. So early tomorrow I'll be back to fixing lineage issues.

 

Upgrades should not require wiping data. If they do, that's a bug. I don't know what the issue was but it shouldn't happen again.

 

There is currently no data backup solution except "adb backup" and mtp. I'll be building a TWRP that can decrypt data soon. But that will come after the lineage ROM is usable, as lineage is my top priority right now.

 

PS: sorry this text isn't better organized. I'm writing on my mobile phone while I have a few minutes before the kids' bedtimes. Did I mention that my life is rather busy? 😉

 

[Craig 1,435]

2 hours ago, mechtec said:

7.  Any way to get the button for apps back?

I would check the trebuchet (launcher) settings.  That would be upstream lineage (not a pro¹ thing) so if nothing there, one option is Nova launcher, it has option to enable icon for app drawer.  (Not currently running los or I'd try it for you.)

Edited February 13, 2020 by Craig

[david 929]

3 hours ago, mechtec said:

Hello,

So I received my pre-order Pro1 a few weeks ago.  But getting it setup and usable has been slow.   My current Samsung Galaxy S Relay 4g slide is getting a bit old, still running Cyanogen as Lineage does not support it.  As such its starting to have SSL errors everywhere and is quickly getting to the point its unworkable.

My needs are simple, I need a decent input device (keyboard), root access (I really don't understand why anyone would accept a device they don't have control over), permission controls (Privacy guard works for this in Lineage) and all the basic things terminal/web browser/audio/phone calls/etc working.  I think I need Lineage to get proper permission control.  Unless I use XPrivacyLua with the (Ed)Xposed framework, I might be able to make the stock Android work, but I have not attempted this setup.

I came from a Relay 4G (running Cyanogenmod 11 = KitKat) to the Pro1 as well.  I just rooted my phone this weekend and switched over fully, activating a new sim in too, etc.  I am thinking I did have to run something on there to deal with old SSL root certificate issues too, now that you mention it, but I don't remember the details of that.

I'm not trying to dissuade you from using LineageOS, but just replying regarding the features you listed.

- Root works with Magisk

- Android 9 has app level permissions built in, so it functions like privacy guard in that way.  If you want to have control over permissions that aren't covered by stock android, then you could try XPrivacyLua.  I just tried that tonight (for a different reason, which was to feed apps fake contacts) and ended up in a state where I couldn't boot my phone.  Because there is no way to access /data from TWRP, with it being encrypted (to manually remove the problems), and no way to flash the EdXposed uninstaller zip, I couldn't uninstall the offending modules.  I ended up having to factory reset.  I did take a TitaniumBackup before I started, and I'm now in the process of restoring from that, with it failing with an app here and there and me having to kill it and uncheck the app from the restore list and restoring again.  It was able to restore from the backup I took on my Relay 4G, with the exception of one app, that I can't remember now.  I guess backups from Android 9 don't restore as well for some reason, so I'll probably have to go back to the older backups to restore some of these apps and data and find a better backup and restore tool.  Nandroid backups in the past got around these issues.

So anyway, there is risk with installing the EdXposed stuff.  I might try it again to see if the fact that I rebooted after installing the EdExposed drivers instead of installing the EdXposed manager first is what caused the issue.

But if you don't need to have control over more than what the stock permissions manager provides in Android, the stock ROM seems to work fairly well.

[Polaris 423]

1 hour ago, tdm said:

I'm working through the issues as I can. I do this in my "spare" time and I'm not paid except for having been given a device for development.

...

PS: sorry this text isn't better organized. I'm writing on my mobile phone while I have a few minutes before the kids' bedtimes. Did I mention that my life is rather busy? 😉

Gee Wiz dude, enough with the excuses!  Will you hurry up! 😉 😉🤣🤣

[EskeRahn 5,454]

@tdm I took the liberty to renaming the thread, and merged in the new thread.

Please let me know when there is a status change, or you want a different title, and and I will edit.

Maybe it would also be nice if we kept your original post up to date with any new important info. Just PM me with what you want it to contain. 🙂

[_DW_ 628]

5 hours ago, tdm said:

I'm working through the issues as I can. I do this in my "spare" time and I'm not paid except for having been given a device for development.

You need a beer fund 👍

[Zamasu 258]

7 hours ago, mechtec said:

6.  Anyone have a recommendation on backup tools?  I don't have Google apps installed and am hoping to run without them as I don't like Google monitoring my phone.  As such would need something I can do through adb or f-droid.  I do not want any closed source software on my phone beyond the absolutely required bits.

I had typed a reply in the different thread, but that reply got deleted so I'll try to recreate it.

Recommended app for backups still seems to be Titanium Backup, but that's closed source. You can get it from the play store with Aurora Store, but I'd get why you wouldn't want it.

Best open source alternative seems to be oandbackup. However this seems to maybe not backup some things like Wifi settings and texts. Performance might also be worse.

I will be trying oandbackup some time this week (with Titanium Backup as a backup backup), I'll post my findings here then. If anybody else got any recommendations I'd love to hear them as well, or if they'd want me to test any specific app/setting to backup across a wipe (as long as it's nothing too difficult). 

[david 929]

4 hours ago, Zamasu said:

I had typed a reply in the different thread, but that reply got deleted so I'll try to recreate it.

Recommended app for backups still seems to be Titanium Backup, but that's closed source. You can get it from the play store with Aurora Store, but I'd get why you wouldn't want it.

Best open source alternative seems to be oandbackup. However this seems to maybe not backup some things like Wifi settings and texts. Performance might also be worse.

I will be trying oandbackup some time this week (with Titanium Backup as a backup backup), I'll post my findings here then. If anybody else got any recommendations I'd love to hear them as well, or if they'd want me to test any specific app/setting to backup across a wipe (as long as it's nothing too difficult). 

Titanium Backup does not work well for some newer apps, in my experiences.  I have a list of about half a dozen it failed restoring yesterday for me.  I will be looking at another backup solution too, so will be interested in what you come up with.

Some apps to test:

- Latest version of Textra.  It should restore all the sms and mms messages too.

- SwiftKey

- Quickstep launcher

Features:

- I use Google for the android settings, but if you find a good app that does those too, that would be good to know. 

- Being able to schedule backups and do them to the SD card is important. 

- Backing up the apk and the data is important.  

- Split apk support is important. 

- Support for filters to pick and choose what to back up and restore

- System app backup

- Keeping multiple backups and being able to restore older versions

I am thinking a comprehensive solution will require using multiple apps, so that when one fails at something, another one will hopefully succeed.  I might need to think about buying a bigger SD card for this reason.  And hope the SD card speed issue on the Pro1 is fixed.

[Gigadoc2 54]

So, now that the topic of keyboard mapping has come up here already, I want to add a bit of (what I hope is) constructive criticism. But first off I want to clarify that I am and will stay grateful for @tdms (and mccrearys) work on this port, without which my Pro¹ be not much more than an expensive toy. And, those who do all the unpaid community work (i.e. @tdm) have the right to decide how this project goes, until we start writing patches ourselves we should only offer suggestions.

So, here we go:

If I understand @Craigs suggestion right, he would have the semantics of the "slanted arrow" keys and the "fxtec logo" key swapped, with the logo key acting as a modifier and the arrow keys not (but instead being shortcuts and/or a standalone key like slash). I see the appeal of being able to remap one of those keys, but I am afraid that for a lot of other people that would greatly diminish the typing experience. The keyboard we have has the shift, "slanted arrow" and even ctrl modifiers on both sides, and that speeds up typing as you can press the modifier key with one thumb and the "main" key with the other. Even with sticky modifiers it speeds up typing, or at least makes it more comfortable.

With @tdm having already implemented his idea of an in-kernel key mapping, I feel doubly bad about criticizing it now (please don't take it the wrong way)... But still, I think this is the wrong way forward. I'll leave aside any architectural or idiomatic aspects, as that is in the end only personal preference; instead I want to point out one Feature that this approach conflicts with (as far as I know): The sticky modifiers. If the keyboard is declared to be of type "ALPHA" (i.e. be a thumb-typing keyboard), we get sticky modifiers and auto capitalization (at the beginning of a sentence). Even though the Pro¹ has a large keyboard, it feels more comfortable to me to have sticky modifiers (after all, it is still thumb-typing). Now currently the `Fn` modifier is not sticky in either case, so it wouldn't make a difference whether handled in the kernel or higher up, but I think that this might be something that Lineage or even upstream AOSP is willing to accept a patch for. After all, when even `Alt` is sticky, having `Fn` left out seems like an oversight, or at least something that should be toggleable at build time. If this would be done, the in-kernel mapping of `Fn` would prevent it from becoming a sticky modifier, or the kernel driver would end up emulating the behaviour from userspace (which still would be weird when an app disables the sticky modifiers and then `Fn` is left as the only stick one).

To be fair, I also see the point of doing it in-kernel: Apps on Android can not only disable sticky modifiers (example: Termux), they can also choose to disable some modifiers at all (example: the built-in Terminal disables `Fn`). Especially with QWERTZ, having `Fn` disabled leaves one unable to input some (crucial) symbols. Having the `Fn` mapping done in the driver would work around this and present a full ANSI keyboard to every App (so if an App disables even more modifiers like Shift, it would be unusuable even with a full keyboard). I'd personally say the apps should be fixed, but it is possible that many more apps exhibit this behaviour. I suspect that many "remote desktop" type Apps will fall under this category as they will want to pass the modifiers through to the target (which probably doesn't understand the `Fn` modifier at all, or has a different behaviour for it). The only one I've tested so far is "KDE Connect" with its remote keyboard feature, which surprisingly does not try to pass through `Fn` but correctly applies it locally.

[_DW_ 628]

A lot of this keyboard stuff I thought was normally done in the keyboard firmware?

[netman 1,424]

3 hours ago, _DW_ said:

A lot of this keyboard stuff I thought was normally done in the keyboard firmware?

On a PC it is because there is a microcontroller in the keyboard that can actually run firmware (traditionally a 8052 if i recall, but we've long since moved on from that). In the pro1 the driver itself handles all these things, and the keyboard is done with a relatively simple multiplexer chip (an aw9523, the same chip used by Cosmo Communicator/Gemini and Unihertz Titan incidentally :D). See: https://matland.be/aw9523b.pdf

Edited February 13, 2020 by netman

[_DW_ 628]

10 hours ago, netman said:

On a PC it is because there is a microcontroller in the keyboard that can actually run firmware (traditionally a 8052 if i recall, but we've long since moved on from that). In the pro1 the driver itself handles all these things, and the keyboard is done with a relatively simple multiplexer chip (an aw9523, the same chip used by Cosmo Communicator/Gemini and Unihertz Titan incidentally :D). See: https://matland.be/aw9523b.pdf

Well I guess with embedded keyboards that is fine they won't just get plugged into something random 🙂

[EskeRahn 5,454]

1 hour ago, _DW_ said:

Well I guess with embedded keyboards that is fine they won't just get plugged into something random 🙂

Well it might... See this 🤣

[_DW_ 628]

54 minutes ago, EskeRahn said:

Well it might... See this 🤣

not sure I'd go to that much trouble to get a sliding portrait phone 😄

[tdm 2,322]

test4 build is up.

 

This has the shiny new keyboard driver and a kcm file that declares the keyboard type to be ALPHA.  I am still working on persisting the keyboard layout, so qwertz users will need to "adb root" and then "echo qwertz > /sys/bus/i2c/drivers/aw9523b/6-0058/layout" after each boot.

 

It also has the fingerprint reader fix and a few other things that I can't recall at the moment.

 

I'll try to get new builds out more regularly now that the hard work on the keyboard has been done.  Things you are likely to see in test5: persisted keyboard settings, keyboard backlight working, a2dp working.

 

Edited February 14, 2020 by tdm

[d 27]

1 hour ago, tdm said:

a2dp working.

Do you have any idea why aptx does not seem to be working on the stock rom?

Thanks!

[tdm 2,322]

47 minutes ago, d said:

Do you have any idea why aptx does not seem to be working on the stock rom?

Thanks!

I don't recall seeing the aptX files on stock. Which leads me to believe that FxTec did not license aptX.

 

 

[Craig 1,435]

Thanks much!  I just installed test4 and going to see how the keyboard works!   Haven't done much yet, but right off the bat it seems some keys can't be seen by Supertux that could be seen by stock.  I know this isn't the most important app, but its something I'm famliar with and a way to test key chording and assignments, and a way I can see if leght and right slant arrow are now separated.   On stock rom, supertux calls the Sym key 'left super' and both slant arrows 'right super'.   However, with this version of LOS, it can't see the slant arrows or the sym key at all!  just acts like I didnt press a key at all.  (Alt still working as left alt, both shifts still left shift, and now both controls are left control!)

(My old supertux keyboard assignments were designed around the fact that only certain keys worked as chords, so I in particular used modifiers and slant arrow etc for most controls.   Gunna have to learn a whole new set of controls to play with this test version of LOS - but should be easy since can chord any keys now.)

Elsewhere, sticky shift and longpress for accented characters works tho, happy about that!

Anyway gunna keep playing with it, just noticed that right away, along with no wake on keypress.

 

Edited February 14, 2020 by Craig

[tdm 2,322]

8 minutes ago, Craig said:

Thanks much!  I just installed test4 and going to see how the keyboard works!   Haven't done much yet, but right off the bat it seems some keys can't be seen by Supertux that could be seen by stock.  I know this isn't the most important app, but its something I'm famliar with and a way to test key chording and assignments, and a way I can see if leght and right slant arrow are now separated.   On stock rom, supertux calls the Sym key 'left super' and both slant arrows 'right super'.   However, with this version of LOS, it can't see the slant arrows or the sym key at all!  just acts like I didnt press a key at all.  (Alt still working as left alt, both shifts still left shift, and now both controls are left control!)

Elsewhere, sticky shift and longpress for accented characters works tho, happy about that!

Anyway gunna keep playing with it, just noticed that right away.

 

 

In the current keyboard driver, the slant arrows are completely dead modifiers.  That is, they never generate any key presses on their own.  They only affect behavior of other keys.  This ensures that the kernel and userspace never get out of sync with respect to modifier state.  Is it important to be able to detect the slant arrows?

 

I mapped the sym key to KEY_SYM because it looked logical.  However, going back and looking more closely, it seems that KEY_SYM was added by the OEM and is not an official Linux key code.  So I'll need to change that.  I had planned to take at least these changes from @Sean McCreary :

 

https://github.com/mccreary/android_kernel_idealte_msm8998/commit/2121b1ad7854fa3ca8f5b5f036ad94ba38b90ee4

https://github.com/mccreary/android_kernel_idealte_msm8998/commit/09b1334da8eb37510368c0be9214a7613847c57e

 

I'm sure you are aware that the pairs of shift, ctrl, alt keys are wired together so both appear as a single key in hardware and they cannot be separated.  I did make them all generate left versions of their keys for consistency.  I didn't think anyone would care (or even notice).

 

[EskeRahn 5,454]

54 minutes ago, tdm said:

I don't recall seeing the aptX files on stock. Which leads me to believe that FxTec did not license aptX.

Some are reporting aptX working, even in HD variant. see this.  But several reports issues, so it works to some extent, but not perfect.

[Craig 1,435]

10 minutes ago, tdm said:

 

In the current keyboard driver, the slant arrows are completely dead modifiers.  That is, they never generate any key presses on their own.  They only affect behavior of other keys.  This ensures that the kernel and userspace never get out of sync with respect to modifier state.  Is it important to be able to detect the slant arrows?

 

I mapped the sym key to KEY_SYM because it looked logical.  However, going back and looking more closely, it seems that KEY_SYM was added by the OEM and is not an official Linux key code.  So I'll need to change that.  I had planned to take at least these changes from @Sean McCreary :

 

https://github.com/mccreary/android_kernel_idealte_msm8998/commit/2121b1ad7854fa3ca8f5b5f036ad94ba38b90ee4

https://github.com/mccreary/android_kernel_idealte_msm8998/commit/09b1334da8eb37510368c0be9214a7613847c57e

 

I'm sure you are aware that the pairs of shift, ctrl, alt keys are wired together so both appear as a single key in hardware and they cannot be separated.  I did make them all generate left versions of their keys for consistency.  I didn't think anyone would care (or even notice).

 

Those two commits will be very welcomed by me.  That'll get the sym key seen, symbol keyboard, and global keyboard shortcuts.

As to the left control, I'd mentioned that myself in my long post on what I thought modifiers should be and why, so I certainly did notice and like it better that way.

As to detecting the slant arrows. Not important in the supertux case, as I can use other keys now freely without worrying about chording and rollover issues.     However my personal goal is to make the right slant arrow behave as slash, something I suspect would never make it into LOS cuz it doesnt match the print.   I had previously with stock used keymapper to assing the sym key as slash as a temporary workaround.  Keymapper now doesnt see sym or slant arrow keys either so I can't use that.

You said this method makes all keys remappable, so I'm going to read what you and thekit were discussing yesterday to see if I can make sense of it enough to use your method to do it. 

 

[tdm 2,322]

3 minutes ago, Craig said:

Those two commits will be very welcomed by me.  That'll get the sym key seen, symbol keyboard, and global keyboard shortcuts.

As to the left control, I'd mentioned that myself in my long post on what I thought modifiers should be and why, so I certainly did notice and like it better that way.

As to detecting the slant arrows. Not important in the supertux case, as I can use other keys now freely without worrying about chording and rollover issues.     However my personal goal is to make the right slant arrow behave as slash, something I suspect would never make it into LOS cuz it doesnt match the print.   I had previously with stock used keymapper to assing the sym key as slash as a temporary workaround.  Keymapper now doesnt see sym or slant arrow keys either so I can't use that.

You said this method makes all keys remappable, so I'm going to read what you and thekit were discussing yesterday to see if I can make sense of it enough to use your method to do it. 

 

 

Okay so yeah ... right now the gpio keys are not remappable.  But I would like to add that in the future.  That would let you map the right slant arrow (and the fxtec key) to whatever you like.

 

The main issue with doing this is that it introduces the possibility that there may be multiple modifier keys, which complicates the keyboard logic.  Right now I've just got two bool variables for each modifier -- one to tell if the key is physically down and one to tell if it is logically (forced) down.   That would need to change.  The physical flag would need to be a counter for the number of keys that are down for each modifier.  For example, suppose you map the left slant arrow to a normal left shift.  Now you can press either left slant arrow or one of the shift keys to get a shift down indication in userspace.  If you press both, you don't want a duplicate indication sent to userspace.  And it's important to keep track of the number of shift keys held down for the code that manages the logical (forced) shift state.

 

Ultimately it's very doable and not a big deal.  But it does require some non-trivial work that I would rather pass on for now, because I've already spent way too much time on the keyboard driver and not enough time on other stuff.

 

[EskeRahn 5,454]

5 minutes ago, tdm said:

.

.

Ultimately it's very doable and not a big deal.  But it does require some non-trivial work that I would rather pass on for now, because I've already spent way too much time on the keyboard driver and not enough time on other stuff.

Interesting. If you want to take this to the ultimate, you could even consider the ORDER they are pressed. That is there is nothing that says E.g. Alt+Sh should do the same as Sh+Alt

This would give us a shitload of keymaps....

An my suggestion (if it is doable) would be that releasing a modifier-key-combo without pressing a key after would display an overlaid keymap for what each non-modifier would give.

And if sticky, the same after the last modifier is held down for a while without release....

Just Ideas 🙂

[mcdinner 375]

@tdmThx for the new build, I'll install it soon.
Could you update the md5/sha1 susm for the new files ?

[tdm 2,322]

6 minutes ago, mcdinner said:

@tdmThx for the new build, I'll install it soon.
Could you update the md5/sha1 susm for the new files ?

Oh didn't I do that? Thought I had...