[ROM] v2.1 STAYBOOGY ZTE KIS3 KK 4.4.4 [CM11] [ROM]

[Guest boogyboo]

STAYBOOGY'S ZTE KIS3 KK 4.4.4 [CM11]

 

v2.1

 

 

The last build had an extreme battery drain issue which I never could really narrow down in the Cyanogenmod source but it is definitely something that was added between November and January to the source (which they often add garbage on a regular basis since so many clueless people contribute to the code), so I reverted to an old edition of the repo which has completely fixed the issue.  Great battery life in the 2.1 version


By executive decision NavBar + Hardware keys are enabled by default--in my opinion this is the best setup for the device.  I have also opted to not enable KeyDisabler which provides the option to enable either NavBar or the Hardware keys (while disabling the other completely)--mainly because it's a stupid idea and garbage code that has been added by the Cyanogenmod team

If you do not like this and wish to have only the Hardware keys, add this to your build.prop and reboot:  qemu.hw.mainkeys=1
To revert after doing so either delete the line from the build.prop or change 1 to 0 and reboot.


Swap is no longer used--in fact it is not used in any of the Kis3 posted roms (from what I've investigated).  If you run mount from the terminal you will see that the swapfile is never listed.  Therefore, it has been removed permanently.  If it was actually being used it would be listed by the mount command, and it would cause unwanted battery drain.


CPU Settings actually stick and do not revert to userspace governor and 300Mhz scaling min frequency--set them how you want them


CyanogenMod statistics, account, and setup have been removed as they are unneccessary for unsupported devices


Performance Settings and Developer Settings are enabled and visible by default on the first boot--no more tapping nonsense


No nag screen when adjusting cpu frequencies either


Partition info added to settings menu since it is useful


System apps put their dalvik-cache on the /cache partition by default; User apps will still use /data partition



ROM is the fastest and most responsive of all available in my opinion.

It is mostly CM11, just with more device appropriate settings.
 

 

 

 

http://www.mediafire.com/download/wgg16g2rx0m2asz/stayboogy--zte-kis3--cm11--two-one--new.zip

 

 

 

 

same directions for installing as the other roms

 

 

 

SOURCES:

 

 

https://github.com/stayboogy/stayboogy_kk_kis3

(contains all necessary minus the Cyanogenmod repo)

 

 

 

 

ENJOY!!!

Edited March 3, 2015 by boogyboo
http://www.mediafire.com/download/abybk60mj177uj0/cm-11-20150104-UNOFFICIAL-kis3.zip

[Guest KonstaT]

Where is the source? Why are you not sending patches?

 

Edit. Oh, I think I found the device tree here. I really don't understand why you've chose to destroy the entire git history (it even had CAF history before me)! Please fork my original repo and make your changes on top of that instead. It also seems you've slightly misunderstood the use of overlay. Overlay is only used when you want to change the default value of something. Just copying more stuff with the same value as the original does nothing. Also where can I find this - 'set proper permissions for the proximity/light sensor for those devices that have one'?

[Guest boogyboo]

Where is the source? Why are you not sending patches?

 

Edit. Oh, I think I found the device tree here. I really don't understand why you've chose to destroy the entire git history (it even had CAF history before me)! Please fork my original repo and make your changes on top of that instead. It also seems you've slightly misunderstood the use of overlay. Overlay is only used when you want to change the default value of something. Just copying more stuff with the same value as the original does nothing. Also where can I find this - 'set proper permissions for the proximity/light sensor for those devices that have one'?

 

what is your deal?  delusions of grandeur much? lol  :blink:

 

i understand overlays...  all i did was use the original framework file and insert your values and changed a few others.  i always start with the config.xml values.xml from the source and edit as needed.  there's more than one way to do it...  or do you not understand that?

 

secondly, i have no reason to add to your git, as your device tree is just fine--i've complimented you on your work already, hell using your source to do my own build should be compliment enough as that's why you posted it, just like me.  i just tweaked a few things to my own liking.

 

i could have removed a few other things but chose not to.  a few of the .sh files in /system/etc/ are not used at all and are erroneous.  also init.target.rc is commented out in init.qcom.rc, which i know why that is, but zram swap is set in that file and so are the proper execution nodes in /dev for the proximity/light sensor on those devices with a proximity sensor.  i added this to the init.rc included in the system source that gets copied over the root.

 

i still do not understand what your deal is...

 

i've also since changed a few more things that have not been added to my git since this, as well as played with the kernel some.  the openc device tree on my github is useless lol.  it won't build that way without changing the source a little and those who are using your builds won't be able to install it since it has assertions in the update script... 

 

this is far from my first build from source, dude...

 

peace

Edited January 12, 2015 by boogyboo

[Guest KonstaT]

what is your deal?  delusions of grandeur much? lol   :blink:

Please leave my massive ego out of this. It has nothing to do with this. :P /s

 

I'm not sure if you are aware but it is an open source project you're working with here (CyanogenMod). What does an open source project need - it needs to have open source code! You took something that I've worked on for a significant amount of time and fully open sourced, and you went underground with your changes. That is considered extremely disrespectful and rude to say the least. Not to mention the parts you're even legally obligated to provide (GPLv2 - which you are in infraction with btw). 

 

I found your source and I reviewed it. It wasn't me who came up with bullshit changelog and false advertisement. Actually, I came easy on you. ;)

 

And what if you'd actually done something that I liked? How could have I included it in my CM11/CM12 (your upstream in this case) if you're not sending patches or there's no commits to cherry-pick?

 

i understand overlays...  all i did was use the original framework file and insert your values and changed a few others.  i always start with the config.xml values.xml from the source and edit as needed.  there's more than one way to do it...  or do you not understand that?

No, there's only one correct way to do overlays. You only overlay the values that you want to change from the default. Anything else you add is redundant crap.

 

secondly, i have no reason to add to your git, as your device tree is just fine--i've complimented you on your work already, hell using your source to do my own build should be compliment enough as that's why you posted it, just like me.  i just tweaked a few things to my own liking.

No, see you already took my git. You made few insignificant changes on top of it and destroyed the history of anyone who's ever worked on it. In open source world this means you took all the credit of the work to yourself.

 

i could have removed a few other things but chose not to.  a few of the .sh files in /system/etc/ are not used at all and are erroneous.  also init.target.rc is commented out in init.qcom.rc, which i know why that is, but zram swap is set in that file and so are the proper execution nodes in /dev for the proximity/light sensor on those devices with a proximity sensor.  i added this to the init.rc included in the system source that gets copied over the root.

I assure you, every .sh in system/etc is used. Please enlighten me why the init.target.rc is commented out. Please share your great wisdom why I did this in CM12 but have somehow completely overlooked this is CM11. (That is called sarcasm if it doesn't translate well :P)

 

i've also since changed a few more things that have not been added to my git since this, as well as played with the kernel some.  the openc device tree on my github is useless lol.  it won't build that way without changing the source a little and those who are using your builds won't be able to install it since it has assertions in the update script... 

Now you're only making it worse by saying there isn't any code that is usable (or matches what you've used in your build) in your github. :(

[Guest boogyboo]

LINK UPDATED

 

 

MUCH BETTER BUILD

 

 

 

CPU SETTINGS ACTUALLY STICK NOW UNLIKE OTHERS' BUILD

[Guest okmikel]

I'll will try it out this weekend, when I move back to CM11. CM12 is to laggy for me at the moment, so I will go back to CM11 for a while.

[Guest KonstaT]

LOL, the only one butthurt around here seems to be you. :D Your petty name-calling ("arrogant egomaniac (clueless)") is so pathetic I'm not even going to even bother commenting on that. Just remember that without my work you wouldn't the have sources to build this CyanogenMod your posting here, so may I suggest you grow up and start acting accordingly. I'd also expect to see the appropriate credit given in the first post since this is all built from the sources that I've released and you've managed make exactly zero changes to make it any better. ;)

 

SOURCES FOR THE BUTTHURT:

 

https://github.com/stayboogy/android_device_zte_kis3

https://github.com/stayboogy/stayboogy_android_packages_apps_settings

https://github.com/stayboogy/proprietary_vendor_zte

https://github.com/stayboogy/android_kernel_zte_msm8610

Next you could try merging your changes on top of the right branch. :P Not on top of my cm-12.0 branch with a huge commit that mostly just reverts every single change that was made for Lollipop! FYI it's cm-11.0 branch that is used in KitKat. ;) This is no better than your previous (failed) attemp. I'd also recommend using a kernel that isn't several months old. You'll be facing issues that have been resolved ages ago (e.g. wifi weak signal sleep of death, missing features/security updates).

 

MUCH MORE RESPONSIVE AND DEVICE SPECIFIC THAN KONSTAT'S BUILDS

CPU SETTINGS ACTUALLY STICK NOW UNLIKE  KONSTAT'S BUILDS--NO MORE LAGGING

SWAP HAS BEEN RE-INTRODUCED AND IS ON BY DEFAULT

Performance settings already work as intended. Certainly removing the whole post_boot script isn't a solution to anything! CPU setting is a remnant from days of old single-core devices. Modern devices have many mechanisms that affect the CPU (mpdecision, thermal, power HAL, etc). User shouldn't be messing with this anyway and the proper solution would be to remove CPU settings altogether (which is exactly what was done in CM12 in favor of performance profiles). zRAM (not swap BTW) has also always worked and you're only reverting part of a commit (failing in that too, though) I've made for a reason (https://github.com/KonstaT/android_device_zte_kis3/commit/eadd85e6521be20740008407dc4a046741c62452).

[Guest hecatae]

boogyboo,

 

let me know if you want this pinned and stickied, I may have to do something with the formatting if that's okay.

[Guest boogyboo]

LOL, the only one butthurt around here seems to be you. :D Your petty name-calling ("arrogant egomaniac (clueless)") is so pathetic I'm not even going to even bother commenting on that. Just remember that without my work you wouldn't the have sources to build this CyanogenMod your posting here, so may I suggest you grow up and start acting accordingly. I'd also expect to see the appropriate credit given in the first post since this is all built from the sources that I've released and you've managed make exactly zero changes to make it any better. ;)

 

Next you could try merging your changes on top of the right branch. :P Not on top of my cm-12.0 branch with a huge commit that mostly just reverts every single change that was made for Lollipop! FYI it's cm-11.0 branch that is used in KitKat. ;) This is no better than your previous (failed) attemp. I'd also recommend using a kernel that isn't several months old. You'll be facing issues that have been resolved ages ago (e.g. wifi weak signal sleep of death, missing features/security updates).

 

Performance settings already work as intended. Certainly removing the whole post_boot script isn't a solution to anything! CPU setting is a remnant from days of old single-core devices. Modern devices have many mechanisms that affect the CPU (mpdecision, thermal, power HAL, etc). User shouldn't be messing with this anyway and the proper solution would be to remove CPU settings altogether (which is exactly what was done in CM12 in favor of performance profiles). zRAM (not swap BTW) has also always worked and you're only reverting part of a commit (failing in that too, though) I've made for a reason (https://github.com/KonstaT/android_device_zte_kis3/commit/eadd85e6521be20740008407dc4a046741c62452).

1.  you're obviously so eaten with jealousy that you can't see that my commits were on the cm11.0 branch.  learn to look before you mouth off.  so high and mighty trying to be correct--except you're wrong, totally wrong yet again...  see attached photos, open your eyes...  aside from that, the only reason i did what i did was for all your freaking crying and whinning like a little baby... which didn't stop but only got worse--imagine that.  what are you 12 years old???

 

2.  you're no one and nothing.  just a punk with a big mouth.  so what?  you're a "king" at modaco which doesn't mean jack squat in the real world.  why keep running your mouth?  makes you look even weaker in my eyes and shows how immature you really are.  you're EVERYTHING that is wrong with the community and your constant crying proves it

 

3.  you're wrong about performance settings--they did not stick in your build.  cpu speeds, especially scaling_min_frequency would not stick and would revert to the low setting in the post boot script after a few moments.  just because you didn't notice doesn't mean it's not true--but it is true.  that's why i scrapped the script which i don't have to explain to some butthurt little crying baby konstat...

 

 

instead of being an ass, maybe just leave my thread.  you're not welcome with your whinning and garbage cluttering up the thread so you can ACT like you're something special...

[Guest KonstaT]

1.  you're obviously so eaten with jealousy that you can't see that my commits were on the cm11.0 branch.  learn to look before you mouth off.  so high and mighty trying to be correct--except you're wrong, totally wrong yet again...  see attached photos, open your eyes...  aside from that, the only reason i did what i did was for all your freaking crying and whinning like a little baby... which didn't stop but only got worse--imagine that.  what are you 12 years old???

 

2.  you're no one and nothing.  just a punk with a big mouth.  so what?  you're a "king" at modaco which doesn't mean jack squat in the real world.  why keep running your mouth?  makes you look even weaker in my eyes and shows how immature you really are.  you're EVERYTHING that is wrong with the community and your constant crying proves it

 

3.  you're wrong about performance settings--they did not stick in your build.  cpu speeds, especially scaling_min_frequency would not stick and would revert to the low setting in the post boot script after a few moments.  just because you didn't notice doesn't mean it's not true--but it is true.  that's why i scrapped the script which i don't have to explain to some butthurt little crying baby konstat...

 

 

instead of being an ass, maybe just leave my thread.  you're not welcome with your whinning and garbage cluttering up the thread so you can ACT like you're something special...

1. And what would I be jealous you for? LOL, do you really think I don't know what I've done with my own code. :D You took my cm-12.0 branch and merged my cm-11.0 branch with your changes on top of that on that gigantic clusterfsck of a commit that mainly just reverts everything that I did for Lollipop. The fact that you still want to argue about that tells everyone you don't have a slightest clue about what you're talking about.

 

2. Yet it's not me who's acting like a child here...

 

3. Like said, performance settings works as intended. Some third party apps display false minimum frequency value (current freq instead), even CM's performance settings does that momentarely until it returns back to its value. You can use an app like CPU Spy to verify that every CPU frequency is still being used though. It's the same thing on every modern Qualcomm device (e.g. discussed on my Moto G Lollipop).

[Guest boogyboo]

last build has a severe battery drain issue that is caused by some garbage in the Cyanogenmod repo.

 

new build is in progress and new link will be posted soon along with updated rom info and battery drain fix.

[Guest boogyboo]

boogyboo,

 

let me know if you want this pinned and stickied, I may have to do something with the formatting if that's okay.

 

If you want to sticky it you can.  it might be easier to find for everyone if it was.

 

you can change the format if needed. 

 

a new link will be added here in a few hours along with updated rom info, so if you want to wait until that is done that would be great.

 

thanks.

[Guest boogyboo]

rom info and link have been updated

 

v2.1

Edited March 3, 2015 by boogyboo

[Guest KonstaT]

The last build had an extreme battery drain issue which I never could really narrow down in the Cyanogenmod source but it is definitely something that was added between November and January to the source (which they often add garbage on a regular basis since so many clueless people contribute to the code), so I reverted to an old edition of the repo which has completely fixed the issue.  Great battery life in the 2.1 version

Or more likely because someone removed parts (post_boot) that set vital parameters. :P LOL yes, Cyanogen has grown into a multi-million (billion?) company because they're all completely incompetent. FYI everything (well, in fairness most things) is thoroughly reviewed before merged into CyanogenMod. We already know what happens if someone tries to comment on or review anything you've done. I'd also like to see what great contributions you've made to CyanogenMod (or any other open source project) since you're so eager to call other people clueless?

 

By executive decision NavBar + Hardware keys are enabled by default--in my opinion this is the best setup for the device.  I have also opted to not enable KeyDisabler which provides the option to enable either NavBar or the Hardware keys (while disabling the other completely)--mainly because it's a stupid idea and garbage code that has been added by the Cyanogenmod team

Err, wouldn't it be better to let the the user to decide? It's a brilliant option, really. And technically it's just a drop in the ocean if 'garbage code that has been added by the Cyanogenmod team' is the only reason (and all the 'garbage code' is still there anyway because you've done nothing to remove it). One could still force nav-bar with a system property even if there was an user option...

 

Swap is no longer used--in fact it is not used in any of the Kis3 posted roms (from what I've investigated).  If you run mount from the terminal you will see that the swapfile is never listed.  Therefore, it has been removed permanently.  If it was actually being used it would be listed by the mount command, and it would cause unwanted battery drain.

Maybe you could investigate the difference between swap and zRAM next. ;) zRAM has always worked as intended, swap has never been used and you're the only one talking about it. FYI, in terminal:

cat /proc/swaps
free

CPU Settings actually stick and do not revert to userspace governor and 300Mhz scaling min frequency--set them how you want them

Like already repeated several times, works as intended. And nothing ever gets reverted to userpace governor so no idea where you've pulled that.

 

CyanogenMod statistics, account, and setup have been removed as they are unneccessary for unsupported devices

'Unoffical' unsupported device or not - doesn't make any difference regarding any of this.

 

SOURCES:

 

https://github.com/stayboogy/stayboogy_kk_kis3

(contains all necessary minus the Cyanogenmod repo)

Same issue I've already raised. You've completely erased the whole git history (both my device and kernel trees even had full CAF history before me). As much it is about the openess of the code, it's about making your changes visible! Now you've also destroyed how git projects have always been structured in Android by putting everything in the same git. Different projects have separate gits for a reason and Google even wrote a specific git wrapper (=repo) for the purpose of managing different projects in Android. So if someone wanted to sync to these sources and make a build, how would he/she do it? Asking this because it's not possible with the way you've done things. This also means you can't keep up with your upstream (actually you're already behind my cm-11.0 branches) and you can't contribute back to your upstream either.

[Guest boogyboo]

Or more likely because someone removed parts (post_boot) that set vital parameters. :P LOL yes, Cyanogen has grown into a multi-million (billion?) company because they're all completely incompetent. FYI everything (well, in fairness most things) is thoroughly reviewed before merged into CyanogenMod. We already know what happens if someone tries to comment on or review anything you've done. I'd also like to see what great contributions you've made to CyanogenMod (or any other open source project) since you're so eager to call other people clueless?

 

Err, wouldn't it be better to let the the user to decide? It's a brilliant option, really. And technically it's just a drop in the ocean if 'garbage code that has been added by the Cyanogenmod team' is the only reason (and all the 'garbage code' is still there anyway because you've done nothing to remove it). One could still force nav-bar with a system property even if there was an user option...

 

Maybe you could investigate the difference between swap and zRAM next. ;) zRAM has always worked as intended, swap has never been used and you're the only one talking about it. FYI, in terminal:

cat /proc/swaps
free

Like already repeated several times, works as intended. And nothing ever gets reverted to userpace governor so no idea where you've pulled that.

 

'Unoffical' unsupported device or not - doesn't make any difference regarding any of this.

 

Same issue I've already raised. You've completely erased the whole git history (both my device and kernel trees even had full CAF history before me). As much it is about the openess of the code, it's about making your changes visible! Now you've also destroyed how git projects have always been structured in Android by putting everything in the same git. Different projects have separate gits for a reason and Google even wrote a specific git wrapper (=repo) for the purpose of managing different projects in Android. So if someone wanted to sync to these sources and make a build, how would he/she do it? Asking this because it's not possible with the way you've done things. This also means you can't keep up with your upstream (actually you're already behind my cm-11.0 branches) and you can't contribute back to your upstream either.

 i don't read your responses,

 

you arrogant fanboy.

[Guest KonstaT]

 i don't read your responses,

 

you arrogant fanboy.

 

PM from boogyboo titled 'butthurt much?'.

just because my builds are better than yours is no reason to harass.

i don't care who you think you are, but to me you're no one. and to the world you're less than no one. so grow up.

you're a fanboy, nothing more. you regurgitate crap you see on the irc, which shows just how ignorant you are as to what people want in my opinion...

i don't flame your boards so stay out of mine. obviously you must realize you are unwelcome

peace.

LOL, 'your' build. :D Crying out loud you've built it using sources I've provided following instructions I've written! You haven't actually made any relevant changes to make it any better yet you are making these bold claims that are not even remotely correct in any technical sense. I just happen to have a very low tolerance for bullshit. I've spent significant amount of my own spare time (easily some hundreds of hours) to do the work on this device and I really hate seeing it being butchered like you've done (what you've done with the sources is truly horrible - you can ask anyone if you don't value my oppinion). BTW, OP is still missing the appropriate credits and links to all of the sources you've used (legaCyMod).

 

I wasn't flaming and you're always welcome to discuss any tehnical issues on my threads. If you have a genuine problem and you can offer a solution - even better. :) That is exactly one of the reasons I've open sourced my work in the first place and even wrote documentation how to build it (I truly want people to be able to do that!). Open source communities are about working together towards better things. It is very difficult if some people are not working in a manner that everyone else is accustomed to. There are reasons we're using revision control (git) and projects are structured (repo) the way they are in Android development. Standardized way of using of using these tools is the key to working efficiently.

[Guest pronetla]

Thanks to all Great JOB and Stop fights, 

 

i'm a new user on zte open c, and the 2 roms have the big same problem cm 12-11 any version on openc zte NO badword 3G brand (USA) repeat ONLY USA like me NO 3g on my phone i'm from Venezuela so i use the US Version of ZTE open c------------ so FIX IT and stop fight tahnks YOU------------------------

[Guest boogyboo]

Thanks to all Great JOB and Stop fights, 

 

i'm a new user on zte open c, and the 2 roms have the big same problem cm 12-11 any version on openc zte NO badword 3G brand (USA) repeat ONLY USA like me NO 3g on my phone i'm from Venezuela so i use the US Version of ZTE open c------------ so FIX IT and stop fight tahnks YOU------------------------

 

it won't show 3G instead it will display H or H+ (for HSPA) which is better than 3G anyway.

 

there are also APN settings that will need to be tweaked to carrier specific values as the config file provided a catch-all file and may or may not be correct.  the values for my carrier where not right and had to be slightly modded.

 

this is not a rom fault but a user fault...

Edited March 26, 2015 by boogyboo