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...

Thursday, November 3, 2016

NEW BUILD! CyanogenMod 13 for Hauwei P9 Lite

Since I got my laptop back up and running, I started looking at offline charging. It's something that should be fairly easy because I've worked on it for several other devices. Booting into charging mode mode is not really that different from booting normally. Init just chooses to initialize somethings and not others when in this mode. The problem with charging mode was that it did not show anything on the screen and it eventually rebooted to recovery. So, just like with the initial bring up, my first task was to get adb working but with so many init scripts it was difficult to tell just what things got initialized on "charging" mode vs "normal" mode. I decided to implement an "lpm.rc" to simply diagnostics.

After that was done and I got adb working, I was left with a "charging" mode that was just a blank screen but at least there were no "reboots to recovery". It just sat there happy and blank. After some poking around I noticed that the framebuffer did not have a "mode" set so I wrote the only mode available to /sys/devices/virtual/graphics/fb0/mode and BAM! the charging screen came on!

Then I turned my attention to fingerprint sensor. My first idea was to push the fingerprintd from CM on to stock and see if it would still work. It did, so I added a bunch of diagnostic code to CM's fingerprintd and pushed it on stock and watched the logs. Then I pushed put it on CM and too and watched the logs... Nothing. After thinking about if for a while I realized that fingerprint is a "security" device and there were parts of security that were still broken; the hw keymaster! I remembered thinking that the hw keymaster might not be so hard to fix and it wasn't. It turns out that it just does not support RSA for encryption and decryption and after removing attempts to add RSA for those "2" purposes, the keymaster was online and working; and so was fingerprint!

So, in this build:

  1. Offline Charging fixed.
  2. Fingerprint fixed.
  3. Sdcard detection fixed.
  4. Experimental graphics property tweaks.


Download available in the downloads section as always...

Tuesday, November 1, 2016

TWRP 3.0.2-0 for Huawei P9 Lite

Why build another TWRP when we do have one that works? Well, my cm builds do not currently support encryption and stock forces encryption on us with a key that no one knows. This makes the installation of CM a bit complicated and once CM is flashed the TWRP that we are using can not mount /data any more. So, got this idea for a TWRP that could switch everything based on what ROM was installed. I've been working on it for a while now and it ready to be released.

On Stock
On CyanogenMod

This TWRP has a few advantages over the one that we are currently using:

  1. The brightness slider works
  2. Battery percentage is reported at top right.
  3. English is the default languages with support for many more.
  4. TWRP settings are stored in /cust so they are preserved across /data wipes.
  5. Compatible with my Cyanogenmod 13 builds.
  6. USB Host mode switches.
Download available in the download section.

P.S. If it wasn't obvious with this post, I have gotten my laptop repaired and it seems to be running very well.

Thursday, October 20, 2016

Laptop Down!

My laptop has been acting strange for the past week or so. It was having trouble starting up and during builds it would suddenly stop and then when I would go to investigate why it failed, I'd get random "Segmentation faults" using simple things like "ls". When I looked at the logs it show disk errors at the "ATA" level. Yesterday was the "straw" that broke the camels back when my laptop refused to boot.

Luckily, I had a thumb drive with an installable version of UbuntuMate 14.04. I formatted everything and installed it. It seems to be OK but I lost everything. It's not really that big of deal though cause everything I need can be found on the web. I just hope my laptop remains stable...

It's going to take me awhile to get up and running with builds. Got to set up the build environment again and sync CM again. Lot's to do...

I just hope the it's not a hardware issue.

I have a build for the Huawei P9 lite on the device that I built an tested before the issues started and I'll try to get it uploaded soon...

Tuesday, October 11, 2016

NEW BUILD: CyanogenMod 13 for the Huawei P9 Lite

I decided it was time to rebuild everything and workout any issues with the build system and as it turns out there weren't any issues so... awesome. I also made several changes to help out battery life/performance.

My Huawei P9 Lite with a Samsung style theme...

  1.  Got the 2nd set of cores (4 - 7) scaling; before it was pegged out over 2ghz.
  2.  Set the minimum frequency of the gpu so it can scale. Before, I had manually set it at max for testing...
  3. Set the minimum frequency of the ram (ddr) so it can scale.
  4. Set the default ddr scaling frequency to "mali_ondemand". This takes care of most of the "tearing" on the screen.
NOTE: If you have any experience with "governors" and frequencies and want to experiment you can adjust frequencies for the ddr and gpu here:

and the cpu here:

I also decided to go through framework/res overlay and add anything that might be useful for this device.

  1. Enabled adaptive brightness
  2. Enabled all tethering
    1. Wifi hotspot
    2. USB
    3. Bluetooth
  3. Disabled hardware button configs
I had a chance to test the sensors and it seems that the lux,prox,acc and orientation sensors are all functioning while the gryo,airpressure and thermal sensor are not working. However the thermal-daemon is up and running and it is reporting temperatures. I'm planning to write a standard sensors lib for all the sensors but I checked on the gyro sensor and even when turned on, it's not reporting data. In fact it hangs while trying to get_data. So, I'll need to hunt it down in the kernel and see what's stalling it out.

Also, although I have not tested it. The issue with wifi not saving passwords is most likely fixed in this build. If it is not please let me know.

I have looked at the "deep sleep" issue closely. It seems that during the resume process "local_enable_irq" hangs starting here:

I've tried to re-arrange the resume process to bypass the hang but to no avail. When I first started this project, I wanted to download the kernel directly from the Huawei but all the links I tried failed so I used a repo that someone had already modified. The next thing I'll try is to revert those changes and see if it helps.

Download on the download page as always...

Thursday, October 6, 2016

NEW UPDATE! CyanogenMod 13 for Huawei P9 Lite update 2

A few days ago when I first got the modem online I was thrilled. If you been keeping up with my blog then you know how difficult it's been. That feeling quickly wore off when I realize that the RIL was unstable. It seemed to be fine for a few minutes after boot but then the signal would become irratic and then making calls would be nearly impossible. Accessing data would also be a problem. I was reviewing the ril log when I noticed that the second modem was online and it was detecting signal strength? I don't have a second sim in there so why would it be doing anything at all. I started to think that I needed to find a why to turn off the second modem. I looked all over the place. Hisi's RIL class does have a method for setting the active modem but it's not implemented in our RIL class. So, I was considering implementing but then last night I decided to compare and contrast the different prop values per device, in the phone.prop from stock. That's when I found it.

This property completely stablized the RIL for me. Now, keep in mind that I only have one sim. For dual sim situations you may need to remove this from the build.prop or change it to something like . I suspect that it will, by default enable both modems by default by just removing the property...

Also some of the sensors have been fix thanks to surdu_petru@xda. I have not tested them all but the accellerometer/orientation sensor and the proximity sensor are working.

The installation instructions have changed please read them carefully!

Download on the download page.. ;)

Tuesday, October 4, 2016

Huawei P9 Lite: RIL up and running!

I was reviewing the out put from dmesg on stock when I saw "do_modem check" from init. This was nothing new, I had seen this before in the init scripts. Since it's not an external binary found in bin, xbin or sbin I figure this is an internal function that Huawei programmed in to init. Then I noticed something that I had not noticed before. After the "do_check_modem" dmesg said something like "do_check_modem success. Wake up modem". Then some process, "modem_sysboot_start" starts talking about /nvm:20/modem_nv/Nv.bin. So, I figure that init is loading some firmware into kernel space to start the modem. It seems that there must be a path that could be used to load this firmware. So I dug around in the kernel for a while and I finally found it. It was the simplest solution. All I had to do was write 1 to /sys/devices/platform/his_modem/modem_sysboot_start . Then the kernel driver uploaded it's firmware from default paths and kicked up the modem. Why Huawei built this into init instead of using a simple line in the init scripts, I do not know.

I've got some tweaking to do on the time of the initialization of the modem and the start of rild. Sometimes rild starts without it's prop entries and has to be restarted... I will probably be releasing an update soon..

Oh, and thanks to XePeleato, I ended up using his RIL class and it does work!

Sunday, October 2, 2016

Huawei P9 Lite: How deep the rabbit hole goes...

I'm a big fan of "The Matrix" movies and so I feel as If I have taken the red pill. It's been along time since I had to work with smali code but I figured that the best way to get the RIL code was to reverse engineer (RE) it out of telephony-common.jar . I found a file "" which is the common ril found in that project, and , once I converted the smali code to java, I noticed ( what seemed to be ) significant differences. So, I thought the challenge would be to rework this code into code that would work with CM but, in navigating around my RE code, I saw alot of abstract classes and custom classes proceeded with the prefix 'hw'. So, I started to suspect that just reworking this RIL class was not going to do it. There was much more involved here.

"You've been living in a dream world Neo" -Morpheus

The file "hwTelephony-common.jar contains the actual RIL class ( that just inherits from in "telephony-common.jar and they have modified the class to implement an abstract class which allows them to call functions in HwRILReferenceImpl.jar. This is just the beginning, these classes depend on the entire "Hw" framework; that is to say all of the jars in "/system/framework". Despite the challenges, I thought that perhaps I could get the framework working in CM. So, I spend a couple of days trying to get it running only to realize that it would never work. Then I thought that I could synthesize a working RIL Class by substituting fake info in situations where these 3 classes reached out beyond them selves. So I spent a few days doing that and again I am foiled.

"I bet your feeling a bit like Alice tumbling down the rabbit hole..." -Morpheus

So for the past week or so I've attempted several approaches to getting the RIL working but have made ZERO progress. Now, it starting to make me miserable so, I've got to climb out of the rabbit hole for awhile. Have a little time to absorb what I've learned and let my mind work on the question marks. In the mean time, I'll be trying to work on other things...

Sunday, September 25, 2016

NEW UPDATE!: CyanogenMod 13 for Huawei P9 Lite Update 1

Now that I've had a while to dig into this device, I'm getting to know the challenges with bringing custom ROM's to this device. Getting a fully working build is going to take some time so I would not hold your breath waiting. However I feel like given enough time we'll get all these issues worked out.


  1.  There are system properties in phone.prop that have to be sorted out. There's entries for each "modemid". In CyanogeMod, if you open "/sys/firmware/devicetree/base/hisi,modemid" with "File Manager" it will show you your modem id. Mine is "34B412000". Then the corresponding system entries in phone .prop entries must be set.
  2. There are a few partitions that the modem needs that are not being mounted.
  3. More research in the radio log on stock is necessary.
  4. The RIL class may need to be reverse engineered out of telephony-common.jar from stock.
  1. The hardware composer must be build with a static libbinder. I suspect that the hwcomposer is creating ION memory heaps and surfaceflinger is treating the like standard memory heaps. Surfaceflinger neglects to unmap graphics buffers when the are free so we quickly run out of graphic memory and crash.
  2. We need to trick the build system into allowing use to use MemoryHeapIon without having the hisi libion source. I will need to think about this ...
  1.  Huawei, implemention of sensor seems a bit complicated. Luckily the sensor hub kernel implementation is simple and strait forward. I believe that I could write an opensource sensors lib easily... You can start a sensor, with the a file manager and root, and get a reading.
    1. Open " /sys/class/sensors/acc_sensor/" with a root access file browser.
    2. Open "set_delay" and overwrite 0 with 200. Save.
    3. Open "get_data" and you'll see 3 comma delimited numbers. These are the x,y,z of the accelerometer .
  2. The system just needs a "bridge" functions to read those...
  1. Haven't really looked at it
  1.  The camera is pretty odd. It seems that the hardware camera lib is dependent on a Java android service... That's strange to me. The service must me in one of the jars or apk's on stock. So the next step is to find it and see if we can get the Android Service Daemon to start it...

So far I have managed to get Audio, Wifi and Bluetooth to work. I created an update zip that you can flash via recovery that will patch the current build. I also disabled deep sleep for now to work around the wake up issue.

I've created a link to the Download page in the "Downloads" section. Unless otherwise stated, links to downloads will be posted there. So the update patch is there by the link to the ROM.

Tuesday, September 20, 2016

DEVELOPMENT BUILD: CyanogenMod 13 for Huawei P9 Lite


This build boots but almost nothing works and installation is a little complicated. I'm putting this out there for testers, builders and devs. Basically people who know how to recover from soft bricks. If you are not one of these then I don't recommend that you attempt to install this.

See the download page here to proceed.

NOTE: I have not had a chance to organize and post my source trees but I intend to in the next few days...

Monday, September 19, 2016

Huawei P9 Lite: It's Alive!

The device arrived on Saturday as expected. I was still working out issues with the releasetools for my CM build when it came. So I didn't get the build done before it arrived but I did finish it later in the day. My P9 Lite came with a case and a screen protector. If I had known that I wouldn't have ordered a case and screen protector separately. I watched a couple of reviews of the device and one of them mentioned that the screen is not Gorilla glass but some sort of regular tempered glass. So I wanted something to protect the screen from scratches. I managed to get the screen protector on there with no bubbles so "BONUS".

Yesterday, I set about completing my initial tasks. Getting the bootloader unlock code was a bit of a pain. In the spot where it asked me for the model, I had to put it in exactly as it was in "About Phone" all caps "HUAWEI VNS-21" and not "Huawei VNS-21" as the tutorial on XDA suggested. After getting the code I quickly unlocked the bootloader and flashed TWRP, did a backup and used dd to backup all partition except, recovery ( it's TWRP i just flashed it so why back it up ), and the /data partition; it's too large to fit on itself. For those that do not know that data partition houses the internal storage...

I flashed my build of CM13 and of course it didn't boot; visually it did not get passed the "bootloader unlocked screen" but adb is was running and I was able to get access. The only problem is that it did not have a shell, which indicates that the system partition was not being mounted, because adbd uses the shell @ /system/bin/sh and alternatively @ /sbin/sh. So, I moddified the init.rc to not remount the "/" tmpfs ro and pushed busybox to /sbin/sh and wahlah adb access.

As TheMarrionette@XDA had told me, the hwcomposer was an issue but I was able to bypass it and force CM to use opengl. However, for some reason I'm not sure of, doing that caused serveral critical services to not start; Namely: zygote, zygote_secondary, installd and netd. Through adb, I was able to start them manually and BAM!

We have lift off!

That being said, almost nothing works ATM. The build will not even boot by itself but this is a significant step forward and I have good idea of how to fix these "initial" issues. It is only a matter of time before we'll have a rough tester build. I honestly did not expect to get this far this fast!

Once I can get CM to boot on its own. I need to get some simple things working.

  1. If the device goes to sleep it will not wake up.
    1. I don't think this is serious. I think it's just the key configuration for the power button.
  2. The on screen navigation bar does not show up.
    1. Again, just a config somewhere.
    2. There used to be a build.prop entry that would turn it on.
  3. I pieced some of this together and I need to work on getting the build system to reproduce some of the "hacks" I've done. 

Thursday, September 15, 2016

Huawei P9 Lite: And so it begins.

Recently I was contacted by "The Marionette@XDA" who asked me If, I'd work on the Huawei P9 Lite. I really enjoy working on devices, especially if they do not have any official support from CyanogenMod or Google. The reason being that there is no real challenge if the already have support. However, It's nearly impossible to develop for a device without out actually having the device to test on/work. So the Huawei P9 Lite community generously donated the funds necessary for me to order the device. I would like to thank:

  1.  Tommi N.    [Red-Killer@XDA](TOP DONOR)
  2. Jakov Gudec             [The Marionette@XDA]
  3. Dominik Hopf           [Senaxo@XDA]
  4. Ayse Guduz               [ndroid1562@XDA]
  5. Michael Pottker
  6. Krzysztof Mikulski  [lsander@XDA]
  7. Malcom Rigg

I like to do something special for my "sponsors". Not sure what that will be but you guys put your money where your mouth is and I wont forget that. Perhaps you can be my testers during development.

My Huawei P9 Lite VNS-21 is expected to arrive either Saturday or Monday but I am eager to get started. So, I'm working "The Marionette's" on the existing device and vendor trees today. I may not end up using them but working on them will help me familiarize myself with the configs. I hope to have a build ready by the time the device gets here but I have a lot to do before I begin testing. Although I am a developer, every device is different and it takes a little while for me to become comfortable with the device. Being over-confident might cause me to brick the device and nobody wants that. My first initial tasks will be:

  1. Unlock the bootloader.
  2. Flash twrp
  3. Use dd to dump (and backup) every partition.
  4. Use the dump of the system partition to verify device and vendor trees.
  5. Study hardware configuration and look for quirks.

I will be developing CyanogenMod 13. If I find that it is more advantageous to switch to AOSP then I will but I'd rather build CM 13 because I am already familiar with it; having just brought up cm 13 for codinalte. I have a few ideas for how to workaround hwcomposer issues.

As soon as I have a booting build I'll start a DEV thread @ XDA

Codinalte/Venturi community:
Bringing up this new device will be taking up most of my time so bug reports will be "noted" but not worked on for sometime; perhaps not till next year but do not worry. I will get to them.

Both codinalte and venturi need kernel bring up's to at least 3.1. for marshmallow. Codinalte already has marshmallow but, you'll notice that battery stats do not report battery consumption for apps. Also bandwith quotas on network interfaces is not working. This is because of a deficiency in the kernel UID_CPU_TIME and it's dependent subsystems are not in the 3.0 kernel and that's why we need a bring up. Time permitting, I intend to start on this spring next year: and yes it is my intention to bring up MM for venturi but for now the focus is on the P9 Lite.

Tuesday, September 13, 2016

NEW BUILD! CyanogenMod 13 for the Galaxy Exhibit / Ace 2e

This build is pretty stable but there still some rough edges that need to be smoothed out. Thanks to a ChronoMonoChrome@xda for his assistance! Gps is not quite there. Blobs seems to be working... no errors but also not location so... It needs a little more investigation. Also MTP is not working. Probably just needs a little research. As far as I can tell everything else is working fine. Have not tried any gApps so... your on your own there.

Not working:

Download here

Tuesday, September 6, 2016

Preview BUILD: Carbon MM for Galaxy Exhibit / Ace 2e

The bring up for Marshmallow has not been easy and it's far from complete. Carbon's MM offering seems a bit premature and that's what I have been doing the bring up on so, I've decided to switch to CM13 which I just repo sync'd. That means abandoning the work I've done so far so I thought I'd release a little preview build for you guys to check out. Make sure that you do a backup because you are not going to want to stick with this ROM. There are many issues both serious and minor but it does boot and there are no annoying ui issues.


  • WIFI
  • Bluetooth
  • Internal SD
  • Audio
NOT Working
  • RIL
  • External SD
  • GPS
  • Camera

Download here

Note: I have not yet tried any Gapps so, if you try some and they work, you might leave a link in comments for everyone.

Friday, September 2, 2016

Progress on Marshmallow for codinalte

I spent most of the day yesterday working out the issues with building Marshmallow for codinalte. There were/are some significant issues but I was finally able to boot Marshmallow this morning. There is some sort of race condition in the fuel gauge driver that needs to be worked out. Also, there is an issue with mounting the internal sdcard( witch I have been doing manually through adb) before I can even release this build. It's an engineering build anyways. I just wanted you to guys to know that progress is being made and Marshmallow will is being worked on.

There are probably numerous other issues/things that do not work as well but...

Tuesday, August 30, 2016

Carbon KK for Galaxy Player 5 Update 2

For those of you who have been running custom ROM's, like this one, on your Samsung Galaxy Player 5.0 for a long time, you may have forgotten about a small piece of unusual hardware on this device. Although, the YP-G70 is not a phone it does have an earpiece in the top center of the front of the device and it is functional. I have never heard of another Android device that has an earpiece and is not a phone. It's odd but it does make sense. I don't know any of this for certain but it seem to me that Samsung was trying to come up with a competitor to the ipod and they were already making phones so it seemed like they just took a phone design and modified it into to Galaxy Player 5.0.

We have been building Android for this device as a small tablet. I guess that makes sense, after all, if we had built it as a phone, there would be lots of useless phone software on the device ( like the Phone.apk ) but doing it that way renders the earpiece useless. I'm not sure how useful the earpiece can actually be on a device like this but, I feel like if it's there we should be able to use it. So, I build in a switch in "Extras" so that you can route audio that would normally go to the speakers on the back, to the earpiece. If anyone has any idea's about how to make this piece of hardware more useful. Let me know.

When I first calibrated the compass for the LP sensor lib it seemed to be working perfectly but I have recently replaced the LCD Screen on my YP-G70. After that, compass was misaligned. It was puzzling and now I have no idea if the compass is aligned properly. All I can say is that it is aligned properly for me.
  • Update 2
    • New Sensors Lib
      • Accelerometer
      • Orientation
      • Magnetomer
    • CodinalteParts
      • Audio to Earpiece

Download next to the build on the download page

Friday, August 19, 2016

Carbon LP 5.1.1 for Galaxy Player 5 Update 2

I purchased my Samsung Galaxy Player 5.0 new at best buy in late 2011. Ever since then I've been working on it. Most of you might not remember this but I released the first custom ROM for this device. It was called "FOREIGNER ROM". It was little more that a stock 2.3.6 modified with what ever hack's I could figure out; patching and slicing stuff together. I was a complete n00b. Afaik, every custom rom that was not stock or modified stock has had some significant issues. 1, the camera has never worked right. 2, the magnetic sensor has never worked. With this release of Carbon LP 5.1.1, update 1 and this update, we take a couple of steps forward in having this device completely working

In ICS and JB the rear camera photo snap was not working at all. The dev's that brought up and worked on those ROM's did an excellent job. Bringing up a 3.0 kernel base on a kernel form a different device could not have been easy. But the camera photo snap did not work producing all green pictures. In development of KitKat, I found a way to give the rear camera photo snap some limit functionality. Basically I peeled an image off the preview window just as the front camera does but the resolution was limited to the preview window resolution; 800x840. Although the camera is still not working completely as it should, by adjusting kernel memory allocation for fimc and jpeg drivers, I was able to increase the resolution all the way up to 3MP the default for the US/INT versions of the YP-G70. I never expected to be able to do this; there are just so many moving parts to adjust to make this happen. However, although the images are 'adequate' they are still not what the image sensor is capable of and in addition, the exif data is incorrect; specifically the flash, exposure time, focal length,iso, white balance(?) and aperture fields are derived from incorrect data. From time to time I take a stab at this and every time I learn more so perhaps one day I will have this completely corrected.

I have recently had a few breakthroughs in my understanding of how sensors work in Android. Those breakthroughs have allowed me to write a hw sensors library for venturi based on the work I did for codinalte. I had to calibrate the magnetic sensor manually but as far as I can tell, the compass works perfectly. I used codinalte with the stock sensors lib to calibrate and use as a comparison for the compass. When laid flat and parallel to each other, they give very similar cardinal directions. I have not, however, tested the compass with any navigation apps or even google maps, I'm running without gapps. Performance seems greatly improved without them. I think that apps are supposed to adjust the cardinal degrees when the device orientation changes because at the hw lib level, there is know way to know if orientation is locked or not.

Please let me know if you experience some situation where the compass does not seem to behave as it should...

Update next to the build download

Tuesday, August 16, 2016

Carbon LP 5.1.1 for the Galaxy Player 5

I've had this ROM built for awhile but I did not release it. I've created an update that solves several problems, most notably the camera. I must say the it does not perform well. This is just an old device but, I thought that I would let you decide for yourselves if it is worth running. Perhaps with some tweaking this ROM can suite your purpose.
There is an update that solves several issues just flash it after you install the ROM.

P.S. Don't forget to install TWRP first.

Download in the download section

Carbon KK for Galaxy Player 5 Update 1

My last release of Carbon KitKat was less than stellar; my apologies to all. I've been working on codinalte but I decided to get back to venturi. For the million'th time I delved into the the camera subsystem. It's a labyrinth  with perils, pitfalls and long twisting dead ends. Our 3.0 kernel was build from the kernel of a similar device "crespo" which has a different rear cam (assumption entered). Our camera driver is from the 2.X Kernel that originally came on this device,I think our fimc drivers are from the 3.0 Kernel and our userspace camera lib is from the Galaxy Tab... ugh.

However, I did manage to get the rear camera to capture images at higher resolutions.

  • Update 1
    • Fixed issues with video recording.
    • Possible fixed other video related  issues
    • Camera can now snap photo's @3MP

Download next build in download section..

Sunday, August 7, 2016

Carbon LP 5.1.1 for Galaxy Exhibit / Ace2e Update 2

The version of dm-crypt in our 3.0.31 kernel is 1.10.1. This version was coded to only accept 5 arguments ( as seen here ). Apparently, in future version of dm-crypt more arguments were added. Vold sends more than 5 arguments causing dm-crypt to return errors. This is easily fixed by simply ignoring the extraneous arguments.

  • Encryption is fixed and completely automated.
    • I recommend using a pattern because TWRP 3.0.1-0 does have issues with pins and passwords.
    • The data partition is automatically resized. Very small resize only 16k.
    • Encryption happens in place so no data is lost, UNLESS you interrupt it.
  • Fixed the hang at "Finishing Boot".
    • SystemUI was getting killed prematurely. Had to do some experimental hacks. Let me know if you have trouble with Apps and the ANR procedure.
  • Fixed the odd behavior of "Network traffic VS" in Carbon Fibers.
    • Due to some sloppy merging there were overlapping vars with the same name!
  • USB clean up USB mass storage might work, but if it does it's only with the external sdcard. Charge only should also work.
  • Fixed Performance action bar back button crash. (AGAIN)
    • Due to a logistical error, the patch did not make it into the last update as it should have.

Sunday, July 31, 2016

Carbon LP 5.1.1 for Galaxy Exhibit / Ace2e Update

  • Fix issue with GPS blob.
    • Installation with out GApps will work.
  • Fixed Performance action bar back button crash.
  • Fixed issue where Carrier mcc/mcn would display instead of carrier name.
  • Cleaned up status bar battery percentage customization. Default is now default and percentage will not automatically display next to icon if charging.
  • Extra's no longer needs root access.
Download next to the build on the download page. 

Note about phone encryption:
Although I have not actually tried it and have never used "phone encryption", I believe that it is not an issue with the ROM but rather, an issue with the size of the file system. When I attempted to encrypt my phone, of course it fails, but the logs say that the "Original file system overlaps the encryption area" ( or something close to that ). Then I remembered reading that encryption requires 16k at the end of the physical partition to use as the encryption footer. So I got to searching around and I believe that this procedure ,although it is for a different device and some of the "specifics" would need to change, would allow "phone encryption" to work. If you really want this feature then try it at your own risk. Our data partition is located at a different path and the disk sizes would be different but I believe the procedure would be correct.

Thursday, July 28, 2016

NEW BUILD!: Carbon LP 5.1.1 for Galaxy Exhibit / Ace 2e

I put a lot of work into this one, trying to make this a stable daily driver.
    • SELinux/sepolicy enabled and a much more proper implementation (IMHO):
      • No longer using patch.
    • CMStats - Removed! I don't like opt-out stats collection even if the data is anonymous!!!
      • Dear CM don't collect info from my device without asking first!
    • About Carbon - Removed!
      • Very buggy on an unoffical device. I did not want to remove it; I just did not want to waste my time trying to fix it.
    • Various Device tree cleanups:
      • Removed old lpm.rc.
      • Removed old custom graphics.
    • Offline Charger:
      • Remove workaround that was using KitKat binaries and brought up to Lollipop.
      • Options in "Extras" now working properly.
    • Carbon Fibers:
      • Fixed SlimActions tile crash (NPE).
      • Fixed a crash when adding a specific shortcut to the lockscreen (class not found).
    • vold:
      • Supported Disk Formats:
        • vfat
        • ntfs
        • ext4
        • f2fs
        • exfat
      • Allow automatic mounting of OTG ext4 formatted drives without security context.
      • Move to sd fix included. No need to flash patch.
    • Developer options:
      • Shown by default.
      • Advanced reboot automatically enabled.
    • CodinalteParts:
      • Sponsors Updated!!! Thank you all!
      • OTG disabled by default and move to "Extras"
        • Can only be enabled once per boot but you can plug multiple times...
        • Sometimes the battery will show charging while OTG is enabled.
        • WARNING!: There may be an issue where the device gets stuck at 1000Mhz all the time after using OTG which will cause battery drain and and the battery temp to go up. A Reboot will return the device to normal. Hope to have this fixed by next release.
      • Randomize WLAN MAC
        • This will set a random MAC address for your wifi card giving you some anonimity.
        • Automatically enables wifi.
        • Sometimes it will work quickly, other times it will take a minute.
        • Reboot to regain your original MAC.
Download here

Thursday, July 21, 2016

TWRP 3.0.1-0 for the Galaxy Exhibit / Ace 2e

It took awhile but I due to some nudging by a user on androidforums, I decided to work out the issues with / and bring up recovery for codinalte. Ever since ClockworkMod was discontinued and critical GGL Pixel format for codinalte (RGB_565) was not supported in most recoveries since Lollipop was introduced, I've been reluctant to tackle these problems. I must have missed it before but it IS supported in TWRP. The new default pixel format reported by fb0 works but it looks horrible. Perhaps I have something misconfigured in that format but by forcing RGB_565 it works perfect.

I have not had time to test this extensively. Everything seems to be configured properly. The right partitions are listed and mountable. No extraneous warning or errors reported but this needs to be tested and I probably won't have time for a while. So, if any one would like to try it out and report any problems. It would be appreciated.

Download on the download page as always.

Sunday, July 17, 2016

Upcomming Feature: Randomize WLAN MAC

The internet is not the same place it was 10 years ago. It seems that network administrators are vigilantly working to ensure that you use the internet the way that they want you to; blocking ports and analyzing HTTP traffic to curb your activity. They are making the internet secure for all but "security" is not worth sacrificing freedom.

When the internet was young, it was so free. Information was exchanged freely and there were no restrictions. Everyone was more concerned with making things work that with controlling how people used it. These days if a network admin doesn't like what you are doing they just block you... by your MAC address. Effing fascists...

This feature, which will be included in my next build for codinalte, and possibly venturi, will help you take a little freedom back. As you can see in the video, when selected, it will disable WIFI, set a ramdom MAC and re-enable WIFI.

Friday, July 15, 2016

Codinalte "Move to SD" fixed!

Moving apps to the sdcard has not working on codinalte since KitKat and it's not for the lack of trying. I looked at this problem several times before and could not quite understand why it wasn't working. When trying to move an app to the SD card LP would simple report that there is not enough space. Obviously that is was not correct. It was just a "stock" error reply for anything that went wrong during the move process.

Further investigation revealed that when the external SD card (/storage/sdcard1) is mounted, vold looks to see if it is flagged as "providesAsec" and if so mounts the /storage/sdcard1/.android_secure which points the way to the apps on the sdcard. In the case of codinalte, /storage/sdcard1 is not flagged as "providesAsec" so the secure area where apps are stored is never mounted and /mnt/secure/asec is just an empty dir attached to the root "/" mount with no actual space and it's read only. That's why when moving "apps to sd" it reports "not enough space". I've got this corrected and I didn't want to build and entire release for this fix so I made a little patch that can be flashed via recovery. This fix will be included in future builds. This patch is for "CARBON-5.1.1-METICULUS-20160712-0645-codinalte" only.

Patch is on the download page next to the build.

Wednesday, July 13, 2016

NEW BUILD! Carbon LP 5.1.1 for Codinalte

I've been working on this build for the past few days. I took awhile and was very frustrating trying to get the patch set just right. I borked my build environment a couple of times, that set me back, and I have been trying to stabilize USB host mode/otg. You plug in the cable and it works! Then you unplug it and plug it back in and.... nothing. I suspect the kernel code for host mode/otg/musb is "incomplete". Perhaps I can backport newer code. However, I wanted to get a release out so I'm releasing it in this state and I hope to get it working properly soon. This is the final Carbon LP 5.1.1 Source with CodinalteParts integated and even though Carbon did not integrate PerformanceControl in LP, I managed to get it in there. I see why they didn't do it, sepolicy makes it difficult and I had to patch it up in order to get it working.

This is a preliminary build. I haven't had a chance to test everything, so pass me a note on anything that is not working properly. I suspect that device encryption will not work. I think that it depends on recovery to do that actual encryption and our recoveries are quite old and may not support it. Screen recorder probably still does not work. Video recording is fixed thanks to ChronoMonochome@XDA.

My apologies to sponsors, I have not had a chance to update the list yet.

Download here

Sunday, July 3, 2016

Development for Galaxy Exhibit (codinalte)

I really don't mean to keep bringing this up but, after my laptop was stolen I could not maintain my website ( and it fell by the wayside. Since I could not build ROMs anymore I saw no reason to keep my Samsung Galaxy Exhibit(Codinalte) so I sold it at a yard sale for $20 bucks. It was battered and beaten, with nicks and scratches all over it; plus, due to a mishap trying to help a friend recover his phone, the EMEI number was corrupted and I could not test phone related functions on the device. So it was gone and with it, development for codinalte... but wait... Yesterday I was strolling through Wal-Mart and low and behold, a Univision SGH-T599 for 20 bucks!

Needless to say I picked it right up and as time permits I will be working on this device. So, for all you codinalte users out there:


Friday, July 1, 2016

Carbon KitKat for the Galaxy Player 5 (revisted)

Hello all, I know it's been awhile and this site has been broken for a long time. After the calamity that killed my other site "", I was not sure if I would get back to Android development but, here I am. I decided to revisit the YP-G70/Galaxy Player 5 and the ROM that I have been running for nearly a year. My custom Carbon KitKat. I've had a year to notice some issues that crop up over long term regular use. Namely, issues with video that cause crash/reboots, and instability when overclocking. So, I restore the stock MFC buffer sizes in the kernel, removed patches related to MFC, increased voltage to 1600mhz and updated to the final source for Carbon KitKat. The result is:

  1. Increased stability with video related operations.
  2. Increased stability when overclocking.
    1. Stable for me at 1600mhz ( Tried serveral times to stablize 1700mhz but could not). Your mileage may vary.
    2. I tested stability by playing "Asphalt Nitro" for several races. Loading and playing this game pegged the cpu at 1600mhz for long periods of time. There were no artifacts or crashes of any kind.

I plan to work specifically on this ROM for awhile so if anyone is having issues with this ROM I will attempt to address them now. Now is the time to speak up and let me know about any problems!

Download here