Thursday, January 26, 2017

NEW BUILD! Alpha 1 LineageOS 14.1 for Huawei P9 Lite | hi6250 variants

Since my previous post I was able to fix quite a few things very quickly so, I decided to do an initial release. This is the first alpha build but its very usable dispite having some obvious issues. Do not expect to use this as a daily driver. A list of the "Known Issues" is available on the download page.

I have not had a chance to test extensively and so if you have issues other than the noted ones please let me know. The installation quirks of this ROM are very similar to CM13 and you can expect the same compatibility.


Tuesday, January 24, 2017

LineageOS 14.1: Booting on Huawei P9 Lite...

As I stated in a previous post, I was having trouble getting through a build of LineageOS 14.1. I am usually quite good a getting around build issues but this one was giving me a lot of trouble. So, I said that I would wait awhile, watch the LineageOS repos and see if anyone else had the issue or it was mentioned again anywhere. In the mean time, I got a new laptop... Well, not exactly new but it is at least 4x times faster than my old laptop. It's nice, I can get through a build in a reasonable amount of time. I got it all setup, ran a build, BOOM same build error. It had also not been mentioned anywhere on the internet afaict. New laptop, fresh setup; same error!

As it turns out, the three files givin' for OpenJDK 8 on Google's "Establishing a Build Environment" page are out of date. I believe that most builders out there have updated to Ubuntu 16.04 or later, in which, this issue would not come into play. This post refers specifically to the build error and the solution for Ubuntu 14.04.

So, now with that build error corrected, I pressed on and got through a build. Of course, the build would not boot. It rebooted almost immediately to recovery, so I check the LAST_KMSG and found it was an issue with selinux/sepolicy. As it turns out disabling selinux is no longer a supported configuration in Android. It's permissive or enforcing. Once I figured out how to get selinux "disabled" it was on and booting. If, I am making it sound like it was easy, let me assure you it took considerable effort!

So, that's the "good" news. It boots.

Now, for that bad news. Nothing else works. RIL, Audio, Wifi, BT and almost all the other hardware is not working. Additionally there are a few other odd things that do not work like the brightness slider and reboot. Yeah, rebooting does not work... Its odd.

I don't see any reason to publish what I have now. Like I said, nothing works so there really is no reason to install it unless you've got some development skill and can "really" help with the bring up.

Sunday, January 8, 2017

NEW BUILD! Beta 4 CyanogenMod 13 for Huawei/Honor HI6250 Variants

Most of you are probably already aware but since Beta 2, I've been experimenting with trying to support more of the Huawei/Honor Hi6250 variants such as the Honor 5c. A few people from the Honor 5c community had tried my ROM and had said that it worked except for the camera. I was already so familiar with the way the stock ROM worked that I was certain that fixing the camera would be easy and it was. From Beta 2 on to Beta 4 new models kept showing up and working and supporting these new models is fairly simple. All I have to do is set some properties in the system at the correct time to configure for a specific model. Since I don't own these other models I can't really test things but as long as it's as simple as setting these properties, then these models will be supported. Currently the list of supported models, which includes the Huawei P9 Lite | Huawei GT3, Honor 7 lite | Honor 5c | Huawei GR5 mini looks like this:

  • VNS-L21
  • VNS-L22
  • VNS-L23
  • VNS-L31
  • NEM-L21
  • NEM-L22
  • NEM-L51
  • NMO-L21
  • NMO-L31

Ah Bluetooth you pain in my ***. Bluetooth pairing has been an issue for quite awhile and I had almost given up on it. I couldn't seem to find any new ways to approach the problem. I knew that a command was "timing out" (optcode 0x40f) to be exact. I checked the logs from the two android phones and I could see that a connection was being established but, when this optcode was send, there was simply no response ever. In that case the bt hci_layer causes bluetooth to be reset. I tried to find some information about what optcode 0x40f did but I couldn't find anything. I tried serveral other small experiments to see what effect they would have; like increasing the length of the timeout, trying different build configs for the BT HAL. Nothing seemed to do anything. I gave up on it but I never forgot about it. Recently, enzo24754 @ XDA, re-mentioned that he had a work around that allowed him to pair to his device. He had mentioned it before but it was at a time when I had less information about the issues and so, in the confusion, i disregarded it but now, I thought that perhaps I could learn something new about the problem from this workaround and asked him to explain it. I could not get it to work. Perhaps it was just my scenario that didn't work but when another user at XDA said that they had gotten it to work and described in more detail the method that he used it got me thinking. The procedure that was described made me think that perhaps this "optcode" was being issued to early; that maybe it was being send before the connection was established and therefor it was never received and ipso facto, a response was never received and boom "timeout".

So with that in mind I decided to play around with the BT hal and see if I could delay sending the 0x40f optcode until the connection was established. After I got my code all set up and rebuilt the BT hal, it didn't work. The problem was still the same so I thought well, what if I just block the 0x40f optcode. After all you can't timeout on a request that you did not send right? RIGHT! Blocking the 0x40f optcode allowed normal pairing. I just hope that it's not needed....

I know that many of you are wondering about a custom nougat ROM and whether or not I will develop one. It was my intention to build CyanogenMod 14.1 but most of you know that CyanogenMod is  a dead project and the devs have created a fork to continue the work called LineageOS. I have already tried to get through a build of LineageOS 14.1 a few times and I just couldn't get throught it; build errors. I pretty sure they were not related to my code but could have had something to do with my build environment or could have just been a few poorly timed repo syncs ( I did try a few times ). So, I think I'm just going to wait awhile and then sync a couple of nougat ROMs
and if one fails I'll just try the other... might be awhile though, I'm trying to get the money together to get a faster, more powerful laptop so I can do builds more quickly...

Thursday, December 8, 2016

NEW BUILD: BETA 1 - CyanogenMod 13 for the Huawei P9 Lite.

Well, it's been a long time in comming. The trees have finally made it to a point where I can call it "Beta". All of the hardware is on line with just a couple of minor exceptions namely, the fm radio and the "pseudo/emulated sensors".

I do not believe that we can use stocks implementation of the FM Radio and we may not be able to use CyanogenMod/AOSP implementation either. The latter is aimed at qcom which does not work for us.

There is also a bluetooth pairing issue which I have not been able to resolve yet. All camera apps should work properly now and NFC is online

This ROM will remain in beta until:
  1. The bluetooth issue has been resolved.
  2. Sepolicy has been fully implemented.

Big thanks to Daniel Múčka (dady000 @ XDA) for his work on NFC, for correcting a lot of my typos/derps and other contributions.

Download on the download page as always.

Thursday, November 24, 2016

NEW BUILD! Beanstalk 6 for the Huawei P9 Lite

So, here it is, Beanstalk 6 for the Huawei P9 lite. This ROM has all the extras that any ROM ever had and then some. I think your going to like it.

NOTE: Fingerprint enrollment does not seem to work BUT if you dirty flash this over CM13, your already enrolled fingerprints will work! 

Install like this:
  1. Install cm13 and enroll your fingerprints (if you have not already).
  2. Uninstall any themes and go back to stock theme ( if you already had cm13 installed ).
  3. Flash Beanstalk 6 (Don't wipe anything... just flash and reboot).
  4. Reinstall your themes
  5. Profit
Happy Thanksgiving!

Download: here

Please do not mirror or re-post my files! Link to this page!

Thursday, November 17, 2016

NEW BUILD! CyanogenMod 13 for the Huawei P9 Lite

From day 1 we have been operating without a hwcomposer. We have also been experiencing a lot of minor graphical type issues and everyone ( and I mean everyone ) assumed that it was because of the missing hwcomposer. Well, I learned long ago that just because "A" precedes "B" doesn't mean that "A" causes "B". I knew that the hwcomposer was insignificant because codinalte runs just fine without one and I did a little experiment. I deleted the hwcomposer on stock and rebooted. Guess what? It ran just fine! There was absolutely no change in the way Stock operated visually that I could detect. So the question remained, "What is causing these minor graphical issues?"

So, finally, since everyone assumed it was the hwcomposer, I thought I'd write one. I personally thought there might be a problem with vertical synchronization and the hwcomposer (can) be responsible for that, but during my debugging, I noticed that the default number of surface buffers in surfaceflinger was 2. In the back of my mind I already knew this and 2 buffers has always been enough for my previous devices but something made me decide to experiment with it. So, I bumped it up to 6. Then I tested. I must say that the graphical glitching was plaguing me. I tried so many different things to try to get it fixed and every time, I thought, "It's fixed!"; Boom it would happen again. So, I kept expecting it to happen again but it never did! All it took was bumping the surface buffers to 6. Not really hwcomposer related at all. I'm so glad I took my time and followed my instincts.

Since that was fixed I buttoned up the hwcomposer that I wrote and it works just fine. I'm uncertain about the vsync implementation. When enabled, surfaceflinger quickly decides that it's not needed and turns it off and indeed, it may not be needed because visually, everthing looks awesome.

This build also has a new opensource power HAL that I wrote. I must say that I'm quite happy with the results but it's effectiveness will depend on usage. Please let me know about your "battery life" experiences. Is it better/worse than before? Is it better/worse than stock?

Battery modes now available in Settings.

Wifi/BT off, 2g no data, balanced power profile, no gapps

Wifi/BT off, 2g no data, balanced power profile, no gapps

I also had a chance to test A2DP and for me it's working perfectly.

I also fixed Screencast and no, the issue is not related to hwcomposer. It was a media codecs issue. Our hw stagefright codecs do not play nice with standard color formats. So, I just modified the "/etc/media_codecs.xml to prefer google codecs over our hw codecs.

Download and more details on the download page as always.

Thursday, November 10, 2016

NEW BUILD! CyanogenMod 13 for the Huawei P9 Lite...

Camera and GPS are the big two that are left. There are also some smaller issues and some might say, "Hey what about the gyroscope." Well, further research has revealed that there is no "hardware" gyroscope. Huawei has some sort of emulated gyroscope on stock. As I have been saying for awhile now, it is my intention to create a standard sensors library and perhaps at that time, I can figure out how to "emulate" gyroscope data using data from the existing sensors but for now, it goes to the back burner. NFC also needs attention but not a high priority.

In this build, I've implemented some, rather hacky, fixes to prop up the Camera. Personally, I don't like these hacks but for now, they make the camera much more use-able. The issues with the camera are 2 fold. Fold 1, perfhub. Perfhub is a daemon that the Camera daemon "HwCamCfgSvr" communicates with for "copybit" operations. Both of these daemons are proprietary blobs and getting in the middle of them to correct issues is difficult. Perfhub often crashes when attempting to close copybit. Closing copybit happens when switching between the back and front camera, closing the camera, after photosnaps; at the end of almost all camera operations. First I tried to reverse shim the function that crashes. The result was pretty good. The camera was stable. Photo-snap worked on both cameras but video recording did not. So, it was an improvement and it was clean ( no crashing ) but, no video recording. So, then I thought well, if perfhub is going to crash, init is going to automatically restart it because its a non-oneshot service. So why doesn't the camera work after perfhub restarts? Well, it seems that communication between perhub, media, and HwCamCfgSvr is broken and does not reinitialize if just perfhub is restarted. Solution: restart them all if perfhub restarts. It's not the best solution but it sorta works. Hopefully, I'll come up with something better soon. Fold 2: copybit operations parameters seem to be off at high resolutions. Miraculously, copybit does not fail at high resolutions, but it creates an image that is the wrong resolution and a much lower resolution. I'm not quite sure why this happens.

I've also added a bunch of minor fixes and features. Check the download page for a complete list.

Download available on the download page as always...