Database Info

[ROM] AOSP w/o Google apps (readd-able) FIRST HALFLEGAL ROM

Here I provide a half legal (I included the HTC drivers for the hardware...) stock AOSP (android-1.5_r3) ROM!
You can add Google Apps legally if you have bought a Google experienced phone by running this script on a linux-machine:
http://forum.xda-developers.com/showthread.php?t=564744
Features:
-No special features
-Just stock w/o Google apps
Download for G1:
http://www.4shared.com/file/135524283/e812c64f/dream.html
Instructions:
Unzip the file, then:
fastboot erase userdata
fastboot flash system system.img
fastboot flash boot boot.img
fastboot reboot
To Do:
I'm a lazy guy.
Next release will be cyanogenmod w/o googleapps.

Well does the rom working without all googles stuffs ?
Can we add them easily ?
Thanks for the new build, hope this googles' issue will be fine

It does work, but it's nearly useless.
I work on a windows version of my script which adds google apps legally.
I also will create a script for recovery.
I'll work on this ROM when I'm done with these, as soon as the scripts are ready, this ROM will get some goodies from Cyan.

Nice work Maxisma!
Its a good start

awesome bro

keep it up it's a start!

maxisma said:
It does work, but it's nearly useless.
I work on a windows version of my script which adds google apps legally.
I also will create a script for recovery.
I'll work on this ROM when I'm done with these, as soon as the scripts are ready, this ROM will get some goodies from Cyan.
Click to expand...
Click to collapse
Excellent.
With all this doom and gloom.
Surely this is the problem solved?
But what do you mean by google experience?
I know I got all the apps with my phone... T-Mobile G1...

Google Experience are all phones with Google Apps preinstalled.
Just some indian and russian HTC devices don't have it.

Out of interest would this boot fine without running the script?
I am presuming not, but i am just curious?
I would try it out, but at the moment I am not at home and only have 2g coverage on my phone so its a bit slow to download
Edit //
Could i (in theroy) install, boot and then use wget to download sam3 from slideme.org and then download a third party dialer / K9 etc... etc..
So use all third party apps

vixsandlee said:
Out of interest would this boot fine without running the script?
I am presuming not, but i am just curious?
I would try it out, but at the moment I am not at home and only have 2g coverage on my phone so its a bit slow to download
Click to expand...
Click to collapse
It boot's fine w/o the script ;-)

Not to rain on your parade, but ....
Hi Maxisma,
Not to rain on the parade, but ...
Per Google, this ROM is no more "legal" than any other ...
The following is taken from http://source.android.com/documentation/building-for-dream
* The Dream device software contains some proprietary binaries. For contractual reasons, these cannot be redistributed separately from the shipping hardware, but the provided script may be used to extract these binaries from your development device so that they can be correctly included in your build. These libraries include the openGL|ES library, the Qualcomm camera library, the HTC Radio Interface Library, etc. You need adb to be in your path, and you need your device to be configured for adb access. If you don't have adb already, do a generic build first, which will put it in your path.
Click to expand...
Click to collapse
Just my understanding of things.
~enom~

Interesting, i am going to have to have a look and a play later.
Cheers for the work (forgot to say that in my first post)

if you're interested on maybe trying to do this on your own:
http://www.johandekoning.nl/index.php/2009/06/07/building-android-15-build-environment/
Contrary to what you might think, a room w/o google apps is not entirely useless. Probably the major setbacks are the lack of market access, the lack of a YouTube player (we need to work on a port of Totem's Youtube implementation but for android), and a way to manage contacts (irrenhaus is looking at the posibility of setting up a Google Contacts sync), plus we'd probably need to write an utility to actually read/write contacts to and from SIM.
G-mail, you can acess from the browser (which, AFAIK, is still free and open source under the Apache Licence), Maps can be downloaded once we get Market access.
Other than that, a bone-stock android build will keep you connected to the internet, allow you to tether, allow you to run scripts, deliver your mms, give you camera and music player, have theme support, and ofcourse, make phone calls just like any other build will. You'll just have to go a bit off of your way to get apps, but again, that's the main drive here, either get acess to market of create a new one and invite app developers to submit their apps there too

enomther said:
Hi Maxisma,
Not to rain on the parade, but ...
Per Google, this ROM is no more "legal" than any other ...
The following is taken from http://source.android.com/documentation/building-for-dream
Just my understanding of things.
~enom~
Click to expand...
Click to collapse
That's dead on too, and I forgot about it. The issue would not be with google anymore though, but with HTC and it's hardware partners. This is what cyanogen realized, now that the spotlight is on rom development, companies will have watchdogs for re-distribution of binary code. If you own an ADP device, you can legally download the binaries from the HTC website and MAKE YOUR OWN BUILD (so redistribution targeting dream is out, unless we can talk to HTC about it), either that, or, as I've said before, move onto an open hardware platform so we can write our own drivers.
---edit---
By the way, I still don't agree with the whole feeling of gloom floating around here. This is only a change to the way we're doing things right now, but it doesn't hinder development in any way. If you're the kind of dev that's here for the praise, then yeah, you wont like it that now people will have to actually know what they're doing, so your fanbase will be reduced. I for one welcome the change. This rom, for example, can still be distributed without the HTC binaries and maybe have instructions for the user to download them, install them in their OTA package, and the actually flash the rom. But then that requires that people actually know what they're doing, since we can't legally provide them the finished product.
Also, it doesn't hinder improvement of the platform. None, I repeat, NONE of cyanogen's or other dev's work ever even touched the proprietary parts of the build, as this is nearly impossible without the source (I know, baksmali, but really, I'm trying to make a point here!...) and most of what made his work awesome was the behind-the-userland work; kernel's bfs patches, scripting, cpu time management, modifications to available source, for example, the settings package.
We can still improve the platform, we can contribute, and maybe this time around the way Google wanted people to, by submitting code for their consideration to have it maybe implemented in android's next build.
I'll be glad to see all the "OMG, MY PHONE WONT START" threads diminish as people realize that this will no longer be the place where you get it all dumbed down and easy to use.

hey just by simple curiosity, how do you then log into the phone, if this rom is google less? I presume you still need a google account to set up your machine right????

kmassada said:
hey just by simple curiosity, how do you then log into the phone, if this rom is google less? I presume you still need a google account to set up your machine right????
Click to expand...
Click to collapse
You don't need to login as there is no setupwizard.

jubeh said:
That's dead on too, and I forgot about it. The issue would not be with google anymore though, but with HTC and it's hardware partners. This is what cyanogen realized, now that the spotlight is on rom development, companies will have watchdogs for re-distribution of binary code. If you own an ADP device, you can legally download the binaries from the HTC website and MAKE YOUR OWN BUILD (so redistribution targeting dream is out, unless we can talk to HTC about it), either that, or, as I've said before, move onto an open hardware platform so we can write our own drivers.
---edit---
By the way, I still don't agree with the whole feeling of gloom floating around here. This is only a change to the way we're doing things right now, but it doesn't hinder development in any way. If you're the kind of dev that's here for the praise, then yeah, you wont like it that now people will have to actually know what they're doing, so your fanbase will be reduced. I for one welcome the change. This rom, for example, can still be distributed without the HTC binaries and maybe have instructions for the user to download them, install them in their OTA package, and the actually flash the rom. But then that requires that people actually know what they're doing, since we can't legally provide them the finished product.
Also, it doesn't hinder improvement of the platform. None, I repeat, NONE of cyanogen's or other dev's work ever even touched the proprietary parts of the build, as this is nearly impossible without the source (I know, baksmali, but really, I'm trying to make a point here!...) and most of what made his work awesome was the behind-the-userland work; kernel's bfs patches, scripting, cpu time management, modifications to available source, for example, the settings package.
We can still improve the platform, we can contribute, and maybe this time around the way Google wanted people to, by submitting code for their consideration to have it maybe implemented in android's next build.
I'll be glad to see all the "OMG, MY PHONE WONT START" threads diminish as people realize that this will no longer be the place where you get it all dumbed down and easy to use.
Click to expand...
Click to collapse
I could probably write a Java application that would allow the user to:
1) hook their google phone up over USB and grab the existing google apps off of it
2) point to the location of their proprietary drivers on a manufacturers website for download
3) point to a central location of legal ROMS for download
4) click an ASSEMBLE button to put it all together. The resulting update file would be like they have always been, but no illegal redistribution has taken place.

One little problem ...
Ohsaka said:
I could probably write a Java application that would allow the user to:
1) hook their google phone up over USB and grab the existing google apps off of it
2) point to the location of their proprietary drivers on a manufacturers website for download
3) point to a central location of legal ROMS for download
4) click an ASSEMBLE button to put it all together. The resulting update file would be like they have always been, but no illegal redistribution has taken place.
Click to expand...
Click to collapse
Hi Ohsaka,
One little problem with that is ... the manufacturers do not post the drivers (standalone) on their websites for download, they only redist with the hardware. Also, there are other library files as well, it's not only drivers.
~enom~

Simple fix.. just don't include it. People will have to "magically" find the drivers on their own.

If it boots, why is it nearly useless?

Mer linux for kaiser.

EDIT:
Magister2k7 said:
Please update first post of a thread, as Mer should run X with a latest kernel from git.
You just need to disable FB_MSM_DOUBLE_BUFFER ("Enable MSM Framebuffer double buffering") and enable framebuffer refresh thread.
Click to expand...
Click to collapse
Yeah, I kinda doomed myself from the start with how I structured this post. I'll restructure it later to be more able to show you good information.
Old start:
Mer is a more community-led version of the Maemo phone and internet tablet operating system. See http://wiki.maemo.org/Mer/ .
I was in contact with a member of that project (Stskeeps on freenode#mer), who gave me some information about porting this to phones such as the kaiser. He and I thought it would be a great way to benefit both communities (we get a good, not google-owned linux-based os for our phones, they get developers helping them make mer better). We also agreed that it would take a bit of effort.
First of all, Mer is completely designed for landscape-only, 800x480 phones at this point. It has been run well at 640x480, but that's still 4 times our native resolution, and 2 times what we can fake without crashes. The resolution problem is easily fixed by skilled theme-makers. The landscape/portrait problem should be fixed soon, given that the upcoming n900 will be a portrait/landscape phone. He said wait for the maemo conference for more on that.
The other problems we might hit basically are just the standard problems of molding the userspace around the kernel (get a phone app working, get the modem to work, etc.).
If you are serious about helping, please come to #mer and/or #htc-linux on freenode. At this point, the mer folks are probably more help to what we need to do.
INSTRUCTIONS:
At this point, quite literally nothing works, but it all almost works. Here's what I did to get that far:
1. Partition your sd card into two partitions, and make the second one ext2.
2. Unpack (with the -p option of tar) the rootfs (http://wiki.maemo.org/Mer/Releases/0.16testing , pick the q5 rootfs) to the ext2 partition. Make sure that it's not in any subfolders, but as the root of the drive.
3. Grab a zImage (or build your own) using the instructions we had in place from android. Put it on the fat side.
4. Set up HaRET on the fat side - Use a default.txt from android, get rid of the initrd, get rid of your ppp stuff (for now), and add "root=/dev/mmcblk0p2 rootwait" to the kernel cmdline.
5. mknod /dev/fb0 c 29 0 (this was my number, check using the terminal in android, cat /proc/devices for the major, and /proc/fb for the minor). Also make sure that it's within the root, not on your disk .
That should boot, giving you a ton of messages about an "incorrect resolution png" or something - that's the splash screen unable to load. Simply rename /lib/init/splash-* (two files) to something else. Once you get a terminal later, there's an actual package to remove, but this lets it go a bit further.
You also need to keep X from starting at this point - all it does is hang. I have not yet done this myself, but it should be an initscript that you just un-link.
EDIT: It wasn't X that caused the issues. It was the combination of failed splashes and consolefont. Comment out the lines with "splash" in them in /etc/init.d/check{fs,root}.sh, and re-run.
I do not know if X actually fails - doing that test now.
EDIT: hitting framebuffer issues... no X yet.
So, if you're adventurous, and preferably a dev at this point (this is completely useless to users), please try this out and make it better!
Okay, just a note: the password is "rootme".

First reply!
this is relevant to my interests. I'll take a look. I remember seeing that Maemo was made on top of Gnome. Do you know if there's a chance to get Debian apps on here? That's the big thing for me to get me working on it-- some type of desktop compatibility. Having an X-server is perfect. Looks like you're saying the resolution issue is purely theme based? How open are the devs for it for suggestions and feedback?

2nd reply
This does sound cool

already made some read about this in the new nokia n900..
its cool.. it free.. but i dont like the ui :\
lets see where this goes.. but.. for now.. for me... android (L)

Ok, just saw it's Jaunty based which is what I've been looking for in a phone.
Is there a list of features/bugs/issues and what's been developed so far? Seems like if the kernel brought to us in part by dzo will work maybe it won't be so hard to get wifi and other features working. A list is good.

I'll admit I haven't put much effort into it, but at this point X won't work, for one thing - probably have to change the resolution in a config somewhere.
Indeed, most of the hardware should be fine - I imagine, for example, once we are able to load the firmware, wifi should be good. Some code will have to change (a few things are built android-specific in the kernel), and some of the RIL stuff especially (phone, data, etc.) will have to be ported by someone who has that code and some time.
Indeed, Mer is Ubuntu-based, and so, according to their site, 95% of ubuntu apps should work perfectly. This is really nice for getting software on (aren't just limited to any applications in an app store or market.).
At this point, all we need to do is everything .
I'm going to try now to disable X and see if I can't get a few more things working.
EDIT: in response to your question about how open the mer-folk are to suggestions? The idea that I got from talking to them was that they are more than happy to get this extra help, and since they are trying to bring this to more devices, they are willing to put up with our requirements, to make this more readily available in general.

Alright, as I edited, I got some more success.
By removing the splash calls and the X starting, I can get a terminal. I edited the /etc/shadow file to have a password that I knew for root. Now, I can log in as root on the console (/dev/tty1).
I tried to start X, and I'm getting some strange framebuffer errors.
I'll keep you posted.

Wow, if we could get this working, it'd be sick! Thanks for posting, formatting now.

with all the hard work already done for the Android port, seeing devs being interested in Mer is REALLY PROMISING! Waiting for Google to open up Android even more, is frustrating...
Porting Mer and thus having a REAL linux (kernel+software stack) is what we need to leverage the dev capacity of the great XDA community. At least, this is what I feel like .
Owning both a Kaiser and 2 N800s, I'll probably try out the stuff posted here... I was keeping an eye on Mer for my N800s anyway, but using it on the Kaiser is more triggering
so devs, have courage and good luck!

Frame Buffer and X server
Unfortunately I've been quite busy lately and haven't been following the Android development as closely as I would like. (I don't think I've updated my git repo for months)
If I remember correctly, the frame buffer code in the kernel wasn't finished. That would prevent X from running. Can anyone say whether that was completed? I just wanted to mention this in order to avoid people wasting their time if it is in fact the problem.
It would be great to *eventually* see X running with hardware acceleration, can anyone point me to info about how DZO got that working? Was it reverse engineered, or did he figure out how to make some binary blob happy?
It will be nice to have some choice of Linux based distros the Kaiser and Vogue. Keep up the good work everybody, I appreciate it!
-Mysteryvortex

I've been looking at the n900 for quite some time just waiting for its release to the US next month. I know nothing about developing but I am very excited about this one, and I hope that there is a quick start to the apps that are put out for it. I was curious myself as well at how this would port to the kaiser so I could get a good hands on before I went and bought one. I would be more than happy to be a tester. I bought an iphone cause cause the little green guy is really starting to piss me off and my tilt's about to give up the ghost. I quickly gave it to my wife as the signal strength and battery life just sucks so I hope this maemo can give me what I want

mysteryvortex, Android does not use an X server at all. This was my disappointment when issues arose trying to run Ubuntu in a chroot. This is different though. We should be looking at troubleshooting the X server as top priority I think. The rest should flow. Bear in mind the kernel for Android, like I said, has nothing to do with X compatibility since Android uses its own display so the kernel should need some serious work.
poly, is the build you linked to hardware specific? Looks like a generic one. If so, then the only outstanding difference should be the kernel and if that's the case we should be able to use this on any phone we happen to have a kernel for right?

enatefox said:
mysteryvortex, Android does not use an X server at all. This was my disappointment when issues arose trying to run Ubuntu in a chroot. This is different though. We should be looking at troubleshooting the X server as top priority I think. The rest should flow. Bear in mind the kernel for Android, like I said, has nothing to do with X compatibility since Android uses its own display so the kernel should need some serious work.
poly, is the build you linked to hardware specific? Looks like a generic one. If so, then the only outstanding difference should be the kernel and if that's the case we should be able to use this on any phone we happen to have a kernel for right?
Click to expand...
Click to collapse
The build has a kernel and stuff, but don't use it. Use the regular stuff from android (or build yourself from htc-vogue).
mdrobnak from irc got mer up on his raph - thanks to the vga screen, with a quick kernel patch and some xorg.conf modification, he got X working great.
Within the next few days, I'll do some tests of the data connection and such.

enatefox said:
mysteryvortex, Android does not use an X server at all. This was my disappointment when issues arose trying to run Ubuntu in a chroot. This is different though. We should be looking at troubleshooting the X server as top priority I think. The rest should flow. Bear in mind the kernel for Android, like I said, has nothing to do with X compatibility since Android uses its own display so the kernel should need some serious work.
Click to expand...
Click to collapse
Yes, that's correct. Android doesn't use X. Many, many months ago, it was mentioned that the framebuffer in the Vouge/Kaiser kernel (which X will use) was broken. Nobody was planning to fix it since Android doesn't need it. I was just trying to point people who have time to work on supporting our phones in the right direction.
poly_poly-man: Looks like the Raphael kernel is being developed on another branch, but it sounds like the FB patch helps us?
-Mysteryvortex

poly_poly-man,
I have setup my second partition of sdcard to 512MB and extracted there Mer preserving permissions.
What I did also is to modify the x config and change resolution and also resize the Mer-logo.jpg so it fits.
After I tried to boot I went successfully through all steps (at least I think so) and a blank screen appeared to me.
Can you tell me what was the parameter to output the Haret boot sequence to a file, so I can check what passes and what fails?
Another question: The following "mknod /dev/fb0 c 29" have to be performed on root of second permission, right? If so I think the command should be ""mknod ./dev/fb0 c 29", am I correct?
Regards,
Borkata

Borkata81 said:
Another question: The following "mknod /dev/fb0 c 29" have to be performed on root of second permission, right? If so I think the command should be ""mknod ./dev/fb0 c 29", am I correct?
Click to expand...
Click to collapse
'./dev/fb0 c 29' does only work if you are in "/" (root of the filesystem) otherwise (and in all other cases) 'mknod /dev/fb0 c 29' is correct.
bye...

Borkata81 said:
poly_poly-man,
I have setup my second partition of sdcard to 512MB and extracted there Mer preserving permissions.
What I did also is to modify the x config and change resolution and also resize the Mer-logo.jpg so it fits.
After I tried to boot I went successfully through all steps (at least I think so) and a blank screen appeared to me.
Can you tell me what was the parameter to output the Haret boot sequence to a file, so I can check what passes and what fails?
Another question: The following "mknod /dev/fb0 c 29" have to be performed on root of second permission, right? If so I think the command should be ""mknod ./dev/fb0 c 29", am I correct?
Regards,
Borkata
Click to expand...
Click to collapse
It seems that even set to the right resolution, our fb does not work with X. Needs more patching than just the patches I got from the other branch. We may need to move up to the other branch, I'm not sure.
the /dev/fb0 should be replaced with /path/to/sdcard/root/dev/fb0, of course. And it's better to just get rid of all the splash references - that way, you don't get the blank screen issue.

toasty_ said:
'./dev/fb0 c 29' does only work if you are in "/" (root of the filesystem) otherwise (and in all other cases) 'mknod /dev/fb0 c 29' is correct.
bye...
Click to expand...
Click to collapse
Yes, but poly has written that user have to be in root so that was what I have asked
Question: our fb driver is msm_fb?
poly can you share which patches you tried from raph branch?

Borkata81 said:
Yes, but poly has written that user have to be in root so that was what I have asked
Question: our fb driver is msm_fb?
poly can you share which patches you tried from raph branch?
Click to expand...
Click to collapse
Oh yes, you're right. I should first read the full post before answering questions that havn't been asked

Borkata81 said:
Yes, but poly has written that user have to be in root so that was what I have asked
Question: our fb driver is msm_fb?
poly can you share which patches you tried from raph branch?
Click to expand...
Click to collapse
http://people.openezx.org/tmzt/
the msmts and vres patch. Didn't work, because there are more problems in our older kernel.
I'm interested in finding out why we aren't on 2.6.27 already...

Compiling & replacing framework.jar

A couple of weeks ago, I picked up a used G1 from craigslist, and I really like it. However, I was disappointed to find out that it won't work with my university's WiFi system. I did some searching and came up with issue 1597 on the android google code page (apparently I can't post a link yet). Post 45 on that thread explains the fix, and since it seems fairly easy to apply to the Android source and google won't release it for who knows how long, I decided to do it myself. However, getting it onto the device has been a real problem. These two threads (which I can't link to either):
t=476563 and t=629551
lead me to believe that I can essentially compile the android source, push the new framework.jar to the device, and the fix will be in place.
I eventually got it to compile, but when I try to install it, It just hangs on the G1 screen. I've tried building it on Ubuntu 9.10 and OS X Snow Leopard using the sources from 2.1 and 1.6 and installing it on King Eclair and BlueMagic Donut (the stock firmware lasted maybe 6 seconds after I got it), and I'm getting the same results, even if I just build the source unmodified. I've probably tweaked and recompiled it 20 times now, and am about ready to lose my mind. I think every time I've gotten at least one error from certain jni libraries not compiling properly, but I've assumed that since they appear to be just for the device, not the system I'm building on, and all I need is the jar file, which should be relatively independent, that isn't important. I'm willing to try a stock rom on my device if that's what I need to do, but I'd like to believe that Android isn't so fragile that I can't use an essentially stock framework with a tweaked rom. Maybe that's not the case, though.
The logcat from my most recent attempt (Currently running BlueMagic) is attached. Everything after the second "AndroidRuntime START" will repeat forever until the phone is rebooted. I've also attached my patched SslCertificate.java and the latest framework.jar I've built from the 1.6 source, if it's any help. I realize the changes I've made to SslCertificate.java might not solve the problem (IMHO the patch description wasn't as clear as it could have been), but if I could actually get something that I've compiled to just run on my device, I think debugging it would be relatively trivial.
I'm not an idiot, I understand most of what's going on here and I've spent a lot of time reading, searching and trying to do this myself, and have attempted to demonstrate that in this post. I am relatively new to Android, but I have been trying to learn as much as I can about it. I don't think this should be so difficult, and I'm really stuck at this point. I assume I'm missing something obvious. If anyone with experience compiling and tweaking Android can spare the time, any advice would be appreciated.

[Security] fb0 world read- and writeable on Samsung Galaxy S2 with CM9.1.0 galaxys2

Hello,
the device /dev/graphics/fb0 is word read- and writeable on my device (Samsung Galaxy S2 with CM 9.1.0). I suspect it is the same way on many other devices.
Every app can read the whole framebuffer and make screenshots. If the app would do that it could also monitor the softkeyboard. The results wouldn't need to be saved because it could extract the pressed key on the fly.
I have tested a short loop in the Terminal and it worked. I was able to get screenshots from an app with the FLAG_SECURE set. Which should disallow the ability to make a shot. ( I wasn't root. ) I was able to get the fb dumps with the keyboard and the keys pressed.
You can manualy set the Permissions to 660, then only root and graphics users can use it.
Can someone please confirm this configuration on other devices?
I don't think it is intendet that every app can play keylogger.
And before you ask I havn't posted/informed anyone. Because if you look at the /dev/exynos-mem hole you want to check every other file in /dev for similar errors. So that is what I did and i can't be the only one. So I figure the blackhats are two steps ahead.

blulantern said:
Hello,
the device /dev/graphics/fb0 is word read- and writeable on my device (Samsung Galaxy S2 with CM 9.1.0). I suspect it is the same way on many other devices.
Every app can read the whole framebuffer and make screenshots. If the app would do that it could also monitor the softkeyboard. The results wouldn't need to be saved because it could extract the pressed key on the fly.
I have tested a short loop in the Terminal and it worked. I was able to get screenshots from an app with the FLAG_SECURE set. Which should disallow the ability to make a shot. ( I wasn't root. ) I was able to get the fb dumps with the keyboard and the keys pressed.
You can manualy set the Permissions to 660, then only root and graphics users can use it.
Can someone please confirm this configuration on other devices?
I don't think it is intendet that every app can play keylogger.
And before you ask I havn't posted/informed anyone. Because if you look at the /dev/exynos-mem hole you want to check every other file in /dev for similar errors. So that is what I did and i can't be the only one. So I figure the blackhats are two steps ahead.
Click to expand...
Click to collapse
I'm 90% certain this file was copypastaed from a Samsung initramfs - so some Samsung releases most likely have this setup too. I'll ask codeworkx which one.
I'm in the process of cleaning up ueventd, unfortunately this mess happened just as I was getting ready to leave for the holidays.

Entropy512 said:
I'm 90% certain this file was copypastaed from a Samsung initramfs - so some Samsung releases most likely have this setup too. I'll ask codeworkx which one.
I'm in the process of cleaning up ueventd, unfortunately this mess happened just as I was getting ready to leave for the holidays.
Click to expand...
Click to collapse
I was unable to locate the same issue in stock devices, maybe CM is using copypasta from old firmware ramdisks.

jcase said:
I was unable to locate the same issue in stock devices, maybe CM is using copypasta from old firmware ramdisks.
Click to expand...
Click to collapse
Yeah, there's a good chance it predates XWLPM. We swapped kernel sources but not ramdisks with Update7.
What builds have you looked at? I'm going to try and see if codeworkx remembers which build he pulled those from.
I'm going to attempt to do a ueventd cleanup before I leave for the holidays. It may be an "axe everything and let the rest of the team figure out what broke and needs repair" approach...

I think this may have been in a samsung leak that never got removed, it dates back to the very first commit of this file in ICS, but isn't in one of my initramfs dumps from one of the first ICS official releases.
http://review.cyanogenmod.org/#/c/28759/
If no observed regressions it will be backported to CM10/CM9 time permitting, but could take some time as I'm unavailable from tomorrow onwards until the new year.

Hi,
I did a little code search on github, this issue seems more widespread than I thought.
I can't post external links here, because I'm new
If you search on Github in Code for:
/dev/graphics/fb repo:CyanogenMod/*
You will find
CyanogenMod/android_device_htc_click » init.bahamas.rc (Rust)
CyanogenMod/android_device_geeksphone_zero » init.zero.rc (Rust)
If you don't restrict the search on a repo you will get many results for different devices, the once i checked had the permission set to 666 or 777 (in the latest revision). But I didn't find the result with the galaxys2 so i figure my results are far from complete.
Is there a mechanism to let the owners know without searching through every projekt and opening an issue there?
Thanks.

Entropy512 said:
Yeah, there's a good chance it predates XWLPM. We swapped kernel sources but not ramdisks with Update7.
What builds have you looked at? I'm going to try and see if codeworkx remembers which build he pulled those from.
I'm going to attempt to do a ueventd cleanup before I leave for the holidays. It may be an "axe everything and let the rest of the team figure out what broke and needs repair" approach...
Click to expand...
Click to collapse
Recent builds (im lazy and in bed so ill look later)
Sent from my SGH-I317M using xda premium

Entropy512 said:
I think this may have been in a samsung leak that never got removed, it dates back to the very first commit of this file in ICS, but isn't in one of my initramfs dumps from one of the first ICS official releases.
http://review.cyanogenmod.org/#/c/28759/
If no observed regressions it will be backported to CM10/CM9 time permitting, but could take some time as I'm unavailable from tomorrow onwards until the new year.
Click to expand...
Click to collapse
Makes sense since leaks often have more relaxed permissions due to debugging.
Sent from my SGH-I317M using xda premium

[ROM][OVATION][EMMC][UNOFFICIAL] Liquidsmooth KitKat v3.2

ROM:
http://www.mediafire.com/download/wkzcatpp7az4r5f/LS-KK-v3.2-2014-10-17-ovation.zip
MD5:
http://www.mediafire.com/download/piwirf8ee421dqv/LS-KK-v3.2-2014-10-17-ovation.zip.md5sum
A shoutout and thanks goes out to Rhyang for his help with the Slimkat rom, (to which this is somewhat similar).
Compiled with Sabermod toolchains. 4.8 for the rom and 4.7.4 for the kernel.
O3 optimized.
I made an attempt to fix 'OK Google'. Dunno if it's working or not (haven't tested). If it's still broken then it will be in the board files and will be a bear to try and find....
Dunno, it seems to work fairly well (ALMOST as good as Cyanogenmod 10.1 ) I kinda like it in a way (except it's KitKat).
I'll try and upload some source later. My internet connection has been giving me problems lately (took four hours or so to upload this). Even with source this is somewhat difficult to compile anyways (I fought with it some).
Cheers!

Great. I'll download now and try it out today :good::good:

Oh man I love LiquidSmooth! I am using it on my phone and have never looked back.
I guess I will have to give this a try. Thanks a lot for this. Is it also running on your yellow kernel or something different?

Which Gapps file is used with the rom please?

Yes it's using the same kernel as Slimkat except that /sound and /drivers/mfd folders have been swapped out with their CM11 kernel counterparts.
If you go into settings and 'about tablet', you will find download links to two types of gapps, full and minimal.

Things are running well. OK Google doors not appear to work too well

Jon Lee said:
Yes it's using the same kernel as Slimkat except that /sound and /drivers/mfd folders have been swapped out with their CM11 kernel counterparts.
If you go into settings and 'about tablet', you will find download links to two types of gapps, full and minimal.
Click to expand...
Click to collapse
Hey Jon, thanks for yet another new rom. :good: Looking pretty cool so far but as already mentioned, "Ok Google" is not working properly. I swapped out your yellow kernel with the stock CM11 kernel and Google Now is working as it should.
Since I lack the capability to compile a kernel, I simply replaced the yellow kernel boot image and the entire modules folder in /system/lib with the CM11 boot image and modules folder. I hated to lose the yellow kernel as I feel that it has better performance than stock CM11 but I love using OK Google. Btw, I did the same with your Slim rom with similar positive results.
Also, I see in the build prop that the density is set to 320DPI instead of the standard 240. I happen to prefer 320 but I would think that the masses might want the standard density and would be wondering why their desktop looks so big.
Anyway, thanks again for your contributions. It's appreciated.
Mike T

Ooh, nice!

Wow, is this fast!
So many ROMs, so little time.
I've been using CM 11 nightlies for a couple months now and didn't have many complaints. The usual CM 11 screen flicker problem when charging, some screen black outs (and crashes) on a certain screen in one of my aviation apps. That was about it. CM 11 was fairly fast and incrementally getting better all the time.
CM 11 doesn't have zRAM built in (yet), so I got a lot of app restarts when switching between my high memory aviation moving maps and other apps. But we're trying an experimental zRAM build that's helping with the HD+'s limited RAM.
But then I got a wild hair and decided to look around in the HD forum to see if perhaps Jon had an OC kernel for CM 11. Then I found his build of Liquidsmooth for the HD+. I didn't want to spend a half day wiping and installing a completely different ROM. But I'm glad I did. Wow.
I don't know if it's the overclocking or the other tweaks or all the above, but my AnTuTu score jumped from 17300 to 19100! Thanks, Jon!
(Hotplug governor seems to work best for me in both LS and CM 11. Too early to tell, but battery life doesn't seem any worse in LS.)
I assume that LS does not force the CPU to 100% when running AnTuTu, as CM 11 does. So the 19100 is probably a realistic reflection of performance.
(I haven't experimented with the I/O scheduler yet. I left it set at fiops for now. (Supposedly best for flash memory. Heretofore I've always used Deadline.) I lowered the SD cache to 512, which I found worked best in CM 11. (Using SD Booster to make that change.) FWIW, I enabled the GPU Acceleration and Super Tweaks in LS. )
[FWIW, the word "compiler" is misspelled (twice) in the "Just in Time Complier [sic]" setting.]
I'm happy to report that the screen flickering/crashes are gone when on that special page in my aviation moving map that always flickered - and sometimes crashed - in CM 11. (Requiring that I disabled HW overlays in Developer Options in CM11.) And since I set the "Low Memory Killer" to "Light" in LS, it doesn't kill my apps as aggressively as CM 11 did. (Not apples and oranges, because I was running ART in CM 11, whereas LS implies you shouldn't even try ART.) LS should be even better with zRAM. (And the boot animation is better than the frowning, scary CM alien face. )
(Speaking of zRAM, I noticed that someone in the Slimkat forum is running zRAM on Slimkat. I read here that Slim and LS are kinda the same. Is there a way to turn zRAM on it LS?)
I'd be curious to know what the major differences are between LiquidSmooth and Slimkat. Since Jon says LS is "similar" to Slimkat, why does LS exist?
Not much I could find on the web about it. I looked at the Slim home page. It's main advantage seems to be fancy interface stuff. (Although LS has PIE too.) Kinda like a toned down version of PAC? But the LS home page is silent about what makes it better/different.
Like I need to spend another half day wiping and flashing can customizing another ROM. (Titanium Backup is supposed to save data/settings. If it does, it doesn't seem to work for me. I have to reset the Settings on my apps when I restore from Titanium.)
---------- Post added at 10:34 AM ---------- Previous post was at 10:21 AM ----------
Every trying for that last bit of performance, some questions:
Q: On zip align apps on boot. Should I expect a toast or a notification if an app needed to be zip aligned?
Q: In CM 11, there's a Developer's Option to kill an app with a long press of the Back button. (Seems to be different from swiping "closed" in Recents, in that it completely shuts down the app.) Is there a similar trick in LS?
Q: I updated the host file for disable ads. I got a message that it worked, 0/4. Zero out of Four? That doesn't sound right. Is it?
Q: In CM's Launcher settings, you can disable transitions, stop scrolling wallpaper, etc. But I can't find a way to disable transitions - especially in the App drawer - in LS. (I see ways to change the transitions, but none of the options have "None.") Where are they or what's the trick to kill them?
Q: Last, and this is more of a Slimkat design element, but shouldn't there be a "Close All" button in the Slim Recent panel?

PMikeP said:
Q: Last, and this is more of a Slimkat design element, but shouldn't there be a "Close All" button in the Slim Recent panel?
Click to expand...
Click to collapse
For a while SlimROMs said they wouldn't support this, but now you can close all apps in the recents panel with a two-finger pinch. I think they might even have a youtube video of this ...
I like Slim because it's minimalist -- no bloated theme engine and its associated bugs. That said, their drivers tend to be a little more out of date than CM. The framework source is also slightly different. This makes sharing code between the two a PIA sometimes. I have no familiarity with LS, so I'm not sure how applicable these comments are to it.
Looks like you've been busy Jon

rhyang said:
For a while SlimROMs said they wouldn't support this, but now you can close all apps in the recents panel with a two-finger pinch. I think they might even have a youtube video of this ...
Click to expand...
Click to collapse
Thanks. I found the pinch gesture serendipitously while trying to swipe away a running app in Recents. Still, it's problematic trying to get it to 'close all' all the time. I went back to stock Recents for now. (Favorites implementation in LS Recents might be nice, as they've implemented in Slim, but I haven't figured out how to invoke it in LS if it's there.)

Here's the device and vendor source as promised:
http://www.mediafire.com/download/z3llb4mauxo8m16/liquidsmooth.tar.gz
Let me know if you need help or any other source to build.
I kept this one very much "original"/plain, meaning I didn't add the zram script (or anything else extra).
To add zram to it, just extract the attached 60ZRM script to /system/etc/init.d
(make sure it is executable & root:shell owned), and reboot.
I believe as far as 'ok google' is concerned, the next step would be to compile with the normal vanilla Cyanogenmod defconfig (sorry, but I refuse to install Gapps just to test). Microphone works, mixer values are the same, so... There's a reason I disabled some of that IPv6 stuff...
Behind the scenes I've been (rather unsuccessfully) attempting a port of ION CMA Heap.
http://pastebin.com/J1Ptxz3W
(Which is why I shared the first build without adding any extras, because I knew I was going to break it immediately following).
BTW, I'm still very new at compiling android and it will take me some time to become better acquainted with the build process.

A hack to fix auditd error "protocol not supported"
Jon Lee said:
To add zram to it, just extract the attached 60ZRM script to /system/etc/init.d (make sure it is executable & root:shell owned), and reboot.
Click to expand...
Click to collapse
Thanks again Jon! The Permissions for your script file were correct from the start. I don't know how to make sure it was root:shell owned, but it worked nevertheless.
Now, a hack to stop auditd errors:
After I got my apps reinstalled and set late last night, I decided to run catlog, just to see what I could see.
LiquidSmooth is definitely quieter than CM 11. (In the sense of less processes starting and stopping.) To be fair, not quite apples to apples because I'm back to running Dalvik on LS and was running ART on CM 11. (ART comes alive frequently to trim memory.)
But there was one process in LS, that I didn't notice in CM 11, auditd, that just kept starting and stopping with an Error, "Protocol not supported."
Despite that fact that auditd is constantly trying to run, it doesn't stop one of the CPU cores from shutting down (with Hotplug governor), nor does it prevent the CPU from dropping to its lowest freq. So, in practice, it doesn't seem to be a problem. Still, it can't be good to have this one thread constantly starting and stopping and it bugged me.
Now, maybe I caused the problem, because I typically uninstall a lot of Google junk and I disable a lot of Google services in the junk I can't remove. (Boy, Google just keeps pinging and pinging you!) And I hadn't run catlog with a virgin build of LS to see if the auditd Error was there at first.
Having said that, I did find a few other people on Google asking about the same auditd Error. (Apparently, auditd is a process from Sun.)
On the assumption you all get the same Error too, the best way to stop this would be to find out why it's trying to start. And to stop it. (Duh.) But that's WAY beyond me. So instead, I simply renamed the auditd file in /system/bin (it's a binary) to auditd.old.
I cringe when I think about it, but it worked anyway. (Worked in the sense that I don't get the auditd Error anymore.)
(As I write this, I wonder if the "d" at the end of audit is Unix convention to signal a daemon? If so, the I suppose there's probably a start up folder or file somewhere in Linux that's trying to start it? Or do daemons start themselves?)

When streaming video on any room using yellow kernel I get occasional freezes that require powering off my nook

Can I use Yellow Kernel in CM 11?
webdroidmt said:
I swapped out your yellow kernel with the stock CM11 kernel and Google Now is working as it should.
Since I lack the capability to compile a kernel, I simply replaced the yellow kernel boot image and the entire modules folder in /system/lib with the CM11 boot image and modules folder.
Click to expand...
Click to collapse
Clever! So, then, can I do this in reverse and swap Jon' s OC kernel into a CM 11 build?

PMikeP said:
Clever! So, then, can I do this in reverse and swap Jon' s OC kernel into a CM 11 build?
Click to expand...
Click to collapse
Never tried but in theory, it should work. Best way to find out is to make a nandroid and try it.
Mike T

webdroidmt said:
Never tried but in theory, it should work. Best way to find out is to make a nandroid and try it.
Click to expand...
Click to collapse
I tried it. Unfortunately on first boot, after immediately getting the CM set up screen, I got the message "Unfortunately, the process com.android.phone has stopped." (It didn't even go thru the process of updating apps like it normally does after a clean wipe, so something seems wrong. I re-did a second Factory Resent and /system wipe. Still no joy.)
So let's make sure I'm doing what you did. I downloaded the latest CM Nightly zip. I have Jon's LS zip. I opened both archives in 7zip.
I took Jon's boot.img from the LS zip and copied over (and replaced) CM's boot.img. I did the same with the modules folder in /system/lib. Then I closed up 7zip and tried installing the new hybrid CM 11 zip file.
But, since you said that you found that "Ok Google" didn't work for you on LS with Jon's kernel, it occurs to me that maybe you made these changes in a running install? That is, I would first install a "stock" CM 11 Nightly and then, after it's running, go in and change boot.img and modules? (I think changing the boot img in the partition would be a challenge for me.)

PMikeP said:
I tried it. Unfortunately on first boot, after immediately getting the CM set up screen, I got the message "Unfortunately, the process com.android.phone has stopped." (It didn't even go thru the process of updating apps like it normally does after a clean wipe, so something seems wrong. I re-did a Factory Resent and /system wipe. Still no joy.)
So let's make sure I'm doing what you did. I downloaded the latest CM Nightly zip. I have Jon's LS zip. I opened both archives in 7zip.
I took Jon's boot.img from the LS zip and copied over (and replaced) CM's boot.img. I did the same with the modules folder in /system/lib. Then I closed up 7zip and tried installing the new hybrid CM 11 zip file.
But, since you said that you found that "Ok Google" didn't work for you on LS with Jon's kernel, it occurs to me that maybe you made these changes in a running install? That is, I would first install a "stock" CM 11 Nightly and then, after it's running, go in and change boot.img and modules? (I think changing the boot img in the partition would be a challenge for me.)
Click to expand...
Click to collapse
You did it right. I did a total clean install of the Liquid rom with the newly "implanted" CM11 kernel. I wouldn't mess around with the partitions, dangerous territory. :laugh:
There's possibly some "hook" that Yellow is looking for that is not contained in CM11.
After reading your post, I just decided to see if it would work in reverse. I also got the same process phone has stopped error. With the ease of making nandroid backups, stuff like this is always worth a try when it's something you want or need. I'm thrilled that it works the other way, as I do use "Ok Google" a lot on all my devices and this Liquid rom runs nicely on the Nook.
In addition, with the introduction of Lollipop, Google has revamped GN and it's even better to use than before.
Mike T

webdroidmt said:
You did it right. . . .
After reading your post, I just decided to see if it would work in reverse. I also got the same process phone has stopped error.
Click to expand...
Click to collapse
Good to know I'm not alone then. Oh well, it was a promising experiment.
(Last night I tried experimenting (hacking) to get zRAM to point to a swap file on /cache. Not really a LS thing, but I might write about it later.)

I tried installing this today and it ran really nice and smoothly, but it doesnt seem to have the full HD+ screen resolution. Seemed more like 720p than 1080, large fonts and icons, just a lower resolution. Am I missing a setting or is it not working at full resolution?