Develop Bugs

[App] LCD Density Changer v3.0 (update + link to new thread)

One last note: Users that have installed the previous versions should/ are adviced to download the new version from the other thread. The new version addresses the problem that one can't boot into the system because of a conflict between a particular density setting and a launcher and or widget.
The apk's attached to this post are now removed. Head over to the new thread to download the app.
Update v2.1 * addresses some problems other devices than the Galaxy S variants had with the former version. * some minor cosmetic changes. (note: I also opened a thread on the android developers forum, so other devices can profit from this tweak as well. I have decided to post my updates there and, of course, on the Android Market. The new thread can be found http://forum.xda-developers.com/showthread.php?t=765639
Update v2.0 * Added option to turn on/off compability settings for app scaling. * Possibility to restore default density setting (the default density that is stored is the density of your screen when you run the tool for the first time). * Added helpfile * Added option to reboot automatically after changing the density.
Update v1.1: a) Optimization of code: faster, more safe b) some cosmetic changes
I created a little app to play with the LCD Density Settings as described in this thread. The app lets you set the LCD Density Setting without edditing the build.prop file (directly).
Be aware that the tweak only will work with launchers like LauncherPro. It doesn't work with Samsungs own TouchWizardLauncher. (If you insist on experimenting with the TWLauncher, make sure that you have the USB Debugger enabled to get you out of the mess ).
Only requirements for this app to work is that you are rooted and have su, busybox and Superuser installed (in fact you have all those apps installed when you have rooted your device the "regular" way) AND that you like to experiment with things.. if you know what I mean.
Click to expand...
Click to collapse
Screenshots
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Instead of a donation you can consider to buy the app from the Android Market (0,75 euro). Search for LCD Density Changer or scan:
I will keep this app for free for download and always up to date here on this forum!
Future work
I will keep on investigating how the software environment can be made compatible with lower density settings. My intention is to update the app constantly with new tweaks and settings so that eventually it can function as a full control panel for the density tweak.
Thanks to jdsemler who discovered this tweak.
Note: if you don't want to take any risk, make sure you make a nandroid backup. Although the new version is reported to be error-free, it is always a good idea to create a full system backup before one is going to play with these kind of tools.
(also) thanks to
* bratfink for giving some very useful input
* Cutefox for bringing to our attention that turning of the compatibility mode via an app called "Spare Parts" solves the scaling problem.
* Nelson Mandela for bringing peace
* Mahatma Ghandi for his inspiration
* Bell for inventing the phone
* Samsung for the upcomming GPS fix
* and many, many others I forgot to mention.
Download history
LCD Density Changer.apk (16.3 KB, 223 views)
LCD Density Changer v1.1.apk (17.6 KB, 91 views)
LCD Density Changer v2.0.apk (28.9 KB, 264 views)

What are the standard values?

HDPI = 240 (Galaxy S default)
MDPI = 160
LDPI = 120
The larger the number, the larger the stuff on-screen is. The smaller the number, the smaller stuff is. The smaller numbers are great for getting more stuff on screen to see, like when using RSS readers to see more articles on the screen before you have to scroll.

jdsemler said:
HDPI = 240 (Galaxy S default)
MDPI = 160
LDPI = 120
The larger the number, the larger the stuff on-screen is. The smaller the number, the smaller stuff is. The smaller numbers are great for getting more stuff on screen to see, like when using RSS readers to see more articles on the screen before you have to scroll.
Click to expand...
Click to collapse
Yeah, it's such a nice tweak. Thanks again! Any progression on the scaling issue?

Nothing useful yet. I'm convinced that the /system.prop is the problem. Somehow, they are updating that file on every reboot, and it is impacting certain apps that are having the 240 value passed to them from that file, which makes them render in that set size.
Take Root Explorer for example. It runs in a very small area when not in HDPI mode on the Samsung device. I installed it on my Dell Streak, which natively is set to run in MDPI mode, and it goes full screen without issue. I then set it for LDPI, and it goes full screen again. Going to HDPI also makes no issue, so it is something that Samsung is doing, and if we can figure out what is updating /system.prop and stop it, I think we'll have it licked.
I think I'm way out of my league when it comes to debugging the Samsung's behavior though.

Can someone post the original build.prop because mine seems to be 0 byte and I can see anything on the screen.
Thanks.

jdsemler said:
Nothing useful yet. I'm convinced that the /system.prop is the problem. Somehow, they are updating that file on every reboot, and it is impacting certain apps that are having the 240 value passed to them from that file, which makes them render in that set size.
Take Root Explorer for example. It runs in a very small area when not in HDPI mode on the Samsung device. I installed it on my Dell Streak, which natively is set to run in MDPI mode, and it goes full screen without issue. I then set it for LDPI, and it goes full screen again. Going to HDPI also makes no issue, so it is something that Samsung is doing, and if we can figure out what is updating /system.prop and stop it, I think we'll have it licked.
I think I'm way out of my league when it comes to debugging the Samsung's behavior though.
Click to expand...
Click to collapse
nonetheless a very interesting problem. The thing that intrigues me is that some apps run full screen without any problem. I'm gonna decompile those apps later on to see how they have defined the layout.
BTW can you upload some of the dell streak prop files that may be relevant in this case?

lpsi2000 said:
Can someone post the original build.prop because mine seems to be 0 byte and I can see anything on the screen.
Thanks.
Click to expand...
Click to collapse
Did you use my app? Because in that case that's not good. What did you do?
Have you rooted your device, did you have busybox installed? Have you granted superuser permission?
Anyway, I attached the build.prop from my Galaxy S.
EDIT if it's right there's a copy of build.prop in the folder /data/data/com.beansoft.lcd_density_setting (or something like that). Can you look and see if that file is 0 bytes to? Otherwise, copy that back to the system folder

I attached my default (HDPI setting) Samsung build.prop and my current Dell Streak build.prop.
The Streak build.prop has a different fingerprint, because I'm using the 2.1 build and had to have a recognized (by Market) fingerprint to get to my protected apps.
The Streak does not have a /system.prop file, unlike the Samsung.

System.prob
It does seem that the dpi settings in system.prop are what seems to be the issue with some of these applications. I could be that the samsung framework explicitly allows 240 as the only acceptable dpi and thus restores the system.prop automatically if it finds a different value.
In this case if someone doesnt mind flashing or is currently using that vanilla custom rom that works on the SGS (Its in its Alpha stages) then it would be interesting to see if the changes are permant and accross the board when using vanilla. Anyone care to try?

bratfink said:
It does seem that the dpi settings in system.prop are what seems to be the issue with some of these applications. I could be that the samsung framework explicitly allows 240 as the only acceptable dpi and thus restores the system.prop automatically if it finds a different value.
In this case if someone doesnt mind flashing or is currently using that vanilla custom rom that works on the SGS (Its in its Alpha stages) then it would be interesting to see if the changes are permant and accross the board when using vanilla. Anyone care to try?
Click to expand...
Click to collapse
Makes sense. Question though, when do all these prop files load? Don't think it will work, but can an app at boottime change the system.prob values so that it doesn't affect the modified dpi value?

tried using your app to change the setting to 220, and the at&t logo pops up, the samsung sound goes off, and the screen stays blank. I can't get access to su in adb shell and all I can do is reboot. what's going on?

asrrin29 said:
tried using your app to change the setting to 220, and the at&t logo pops up, the samsung sound goes off, and the screen stays blank. I can't get access to su in adb shell and all I can do is reboot. what's going on?
Click to expand...
Click to collapse
I suppose you have a rooted device with the whole sjabang (SuperUser and Busybox) installed on it?

appelflap said:
I suppose you have a rooted device with the whole sjabang (SuperUser and Busybox) installed on it?
Click to expand...
Click to collapse
yes. when I try to use su I get
[1] Segmentation fault su

appelflap said:
Did you use my app? Because in that case that's not good. What did you do?
Have you rooted your device, did you have busybox installed? Have you granted superuser permission?
Anyway, I attached the build.prop from my Galaxy S.
EDIT if it's right there's a copy of build.prop in the folder /data/data/com.beansoft.lcd_density_setting (or something like that). Can you look and see if that file is 0 bytes to? Otherwise, copy that back to the system folder
Click to expand...
Click to collapse
Yes, the app is what I use and I can't even get su to work under adb shell. It looks like I am going to need to re flash.

Used the app, same result....
Reflashing now... Normally not a problem for me to reflash, but I didn't get to backup my text messages and notepad -_-
Oh well...

asrrin29 said:
yes. when I try to use su I get
[1] Segmentation fault su
Click to expand...
Click to collapse
that's weird. all I do in the app is trigger some shell commands like "su" and "busybox cp". But can't you try to do the rooting procedure again by "apply: /sdcard/update.zip" in adb?
Makes me wonder if there are any users, except me, who got this app working?

appelflap said:
that's weird. all I do in the app is trigger some shell commands like "su" and "busybox cp". But can't you try to do the rooting procedure again by "apply: /sdcard/update.zip" in adb?
Makes me wonder if there are any users, except me, who got this app working?
Click to expand...
Click to collapse
not sure that's going to work, because I can't get super user access until I grant it permission without a ui.

F_L_Abs said:
Used the app, same result....
Reflashing now... Normally not a problem for me to reflash, but I didn't get to backup my text messages and notepad -_-
Oh well...
Click to expand...
Click to collapse
I'm sorry ... The Android SDK isn't the best toolkit to do such low level system hacking. The security levels are high, and to break them you have to do all kind of weird stuff. Anyway, I changed the first post and put a extra warning in it.

Is there a way to use Odin 3 to restore the files changed?

Stop the Full Charge Notifications

For anybody who wants to run a stock (but rooted) ROM and wants to remove probably the dumbest feature ever: the Full Charge Notification. This is affectionately known as the 3am wake-up call.
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
If you don't know what I'm talking about, consider yourself lucky. If you know what I'm talking about, you have options. One way is to install an app to silence the notifications such as the free "Battery Charged Silencer" app (thanks JimSmith94 for pointing this out), this app allows you to silence the notification sound only. For the more adventurous types out there here's another way to put an end to it, which also allows you to choose whether or not to leave the screen-on and status bar notification:
1. Download Auto-Deodexer, http://forum.xda-developers.com/showthread.php?t=598026
2. Extract Auto-Deodexer
3. Copy /system/app/SystemUI.apk and system/app/SystemUI.odex to your sdcard
4. Copy /system/framework/ to your sdcard
5. Copy the contents of the framework folder from sdcard to the framework folder of Auto-Deodexer
6. Copy SystemUI.apk and SystemUI.odex to the app folder of Auto-Deodexer
7. Run deoall.bat, choose option 1 and wait for it to finish. Use option 6 to exit
8. Open deodexed_APK/SystemUI.apk with 7-zip and extract classes.dex to your root deodexer folder (the one with baksmali in it)
9. Open a command prompt and navigate to the folder where you have extracted Auto-Deodexer
10. Use the following command: java -jar baksmali-1.2.3.jar -o dexout/ classes.dex
11. Open dexout/com/android/systemui/statusbar/policy/StatusBarPolicy.smali in your favorite text editor
12. Find the .method private addFullChargeNotification method.
13. What you do next depends on your version of Android.
If you are running Android 2.3.4, remove the following lines:
to remove the sounds, remove: "invoke-direct {p0, v0}, Lcom/android/systemui/statusbar/policy/StatusBarPolicy;->playTone(Landroid/net/Uriv"
to stop the screen from turning on, remove: "invoke-direct {p0}, Lcom/android/systemui/statusbar/policy/StatusBarPolicy;->turnOnScreenWithForce()v"
to remove the status bar icon, remove: "invoke-virtual {v0, v1, v2}, Landroid/app/NotificationManager;->notify(ILandroid/app/Notificationv"
If you are running 2.3.6 (you have the EK02 update), remove the following lines:
to remove the status bar icon, remove: "invoke-virtual {v0, v1, v2}, Landroid/app/NotificationManager;->notify(ILandroid/app/NotificationV"
to stop the screen from turning on, remove: "invoke-direct {p0}, Lcom/android/systemui/statusbar/policy/StatusBarPolicy;->turnOnScreenWithForce()V"​
14. Use the following command: java -Xmx512M -jar smali-1.2.3.jar dexout/
15. Rename out.dex to classes.dex
16. Replace the classes.dex in the deodexed SystemUI.apk with the one you just created
17. Rename the new deodexed SystemUI.apk to SystemUI.apk.new and push it to your phone
18. Copy SystemUI.apk.new to your /system/app folder
19. Set the permissions for the file to owner: Read/Write, group: Read, others: Read (644 for those who know what that means)
20. Rename SystemUI.odex to SystemUI.odex.old
21. Rename SystemUI.apk to SystemUI.apk.old (you will start seeing frequent errors at this point, this is normal and expected. Don't panic just hit Force Close to dismiss the errors and continue)
22. Rename SystemUI.apk.new to SystemUI.apk
23. Reboot
24. Enjoy uninterrupted sleep.​
For anybody running stock 2.3.6 you can grab the file below and skip steps 1-16. This will stop both the screen-on and the status bar icon.
If you are running a custom ROM and you don't have this notification (I'm not sure why you read this far but...) please thank your dev. If you do have this notification, I imagine these steps would still work for you.
If these changes don't work for you, you find a full nights sleep to be annoying, you think sleep is for weak minded individuals, etc. you're in luck. Reverting back is simple:
1. Rename SystemUI.odex.old to SystemUI.odex
2. Rename SystemUI.apk to SystemUI.apk.new
3. Rename SystemUI.apk.old to SystemUI.apk
4. Reboot​
Thanks:
Thanks to pulser_g2 for fixing this issue on the international GSII
Thanks to Mic_88 for writing a portal article about pulser_g2's work), I also linked to the image you used
Thanks to Sboulema for your step by step directions (largely copy/pasted above)
Thanks to afilopou for some edits you made to those directions
Thanks to countless others here at XDA who freely share their knowledge and selflessly donate their time to make life better for others

reserved for future updates

Thanks, I wouldn't be surprised if this was some kind of federal regulation from the EPA or something like that. I noticed a lot of newer phones do this now, and tell you to unplug your phone. Like I really want to head to work with 80% battery.

LOL at the pics

phatmanxxl said:
Thanks, I wouldn't be surprised if this was some kind of federal regulation from the EPA or something like that. I noticed a lot of newer phones do this now, and tell you to unplug your phone. Like I really want to head to work with 80% battery.
Click to expand...
Click to collapse
That's crazy enough to be true.
I haven't busted out my DMM yet, but I'm pretty sure the phone throttles the charge current down once the charge hits a certain threshold (the brick cools down). It also takes *forever* to charge from 99% to 100%, I found that while testing this fix and waiting for the phone to fully charge. If the phone is throttling the charge current, there's no reason to expect it won't turn into a trickle to keep the phone at max.
It's also interesting that 2.3.4 had sound + screen on + status bar icon while 2.3.6 dropped the sound. I figured that change had to be in response to complaints, but couldn't figure out why they'd leave the screen on (since that can be just as annoying). Some obscure federal regulations would explain why the screen on was left in there. I wish policy makers didn't live such a sheltered life so we could get some common sense legislation.

This free "Battery Charged Silencer" app works well for me: https://market.android.com/details?id=cz.psencik.simple.silencer&hl=en

JimSmith94 said:
This free "Battery Charged Silencer" app works well for me: https://market.android.com/details?id=cz.psencik.simple.silencer&hl=en
Click to expand...
Click to collapse
Cool to have a app, but users shouldnt have to install a app to stop things like this. These little things should be options, the ability to turn them off should be in settings under "Display"
IMO

JimSmith94 said:
This free "Battery Charged Silencer" app works well for me: https://market.android.com/details?id=cz.psencik.simple.silencer&hl=en
Click to expand...
Click to collapse
You're absolutely right. I saw several people referencing that when I was looking around for how to do this. I will probably add this to the original post. If you want to use an app for this, that's your prerogative. We should be free to make our own decisions, but it's not really a choice if you only have one option to choose from. Speaking for myself, I'd prefer not to clutter up my device with a bunch of use-once-and-forget apps if there's an alternative.
I approached this wanting to learn how to do something for myself instead of always relying on the work of others, so I leaned heavily on the work of others. Once I had it working, I decided to pass it along in the hopes that somebody else can benefit.
I think Samsung gave us one hell of a phone to work with but there are a few things I find annoying: battery charge notification, camera sounds, etc. Thanks to XDA I'm confident I'll be able to tweak and tune this device until it meets my definition of perfect, what remains to be seen is how much of this other people help me with vs how much other people do for me. However, I'm not saying my approach is better than yours.

cordell12 said:
Cool to have a app, but users shouldnt have to install a app to stop things like this. These little things should be options, the ability to turn them off should be in settings under "Display"
IMO
Click to expand...
Click to collapse
Amen brother!
If I'd been able to add options to make it configurable, I think we'd all come out ahead in the end.

I do know there was a law passed a few years ago about camera sounds. That every phone with a camera must have a sound that can't be silenced when taking pics, for privacy reasons lol but we can have our keystrokes secretly logged and sent to an unknown server.
Thanks for this though, I think the charge light turning blue is plenty of notification that im %100.

is it bad for the phone or battery to leave the phone on the charger after it is fully charged for an extensive period of time?
if i'm running custom rom (calkulin's) will this have any adverse affects? will it potentially break anything?

gershee said:
is it bad for the phone or battery to leave the phone on the charger after it is fully charged for an extensive period of time?
if i'm running custom rom (calkulin's) will this have any adverse affects? will it potentially break anything?
Click to expand...
Click to collapse
Unless your using an SBC kernel (which our phones don't have yet), no you'll be fine. The circuitry in the phone controls the voltage to the battery when its full.

gershee said:
is it bad for the phone or battery to leave the phone on the charger after it is fully charged for an extensive period of time?
if i'm running custom rom (calkulin's) will this have any adverse affects? will it potentially break anything?
Click to expand...
Click to collapse
I don't believe so for a couple reasons:
1) Different types of rechargeable batteries perform differently. Where Ni-Cad batteries would develop a memory if you only discharged them to a certain level (if you frequently drained them to 75% before you charged them, eventually you'd only get 25% use out of them). Continuously charging a Ni-Cad battery to keep it topped off would result in a battery that wouldn't hold a charge. The batteries in our phones are Li-ion. I think Li-ion batteries are supposed to operate better at full charge and last longer when they get frequent charges instead of running them down before charging them back up.
2) While I haven't seen any specific discussion on the topic, I believe the phone throttles down the charge current as it approaches 100% (the transformer brick cools down because there is less current flowing through it). If that is the case, I would hope the Samsung engineers have the phone either turning off the charge current or only allowing a trickle charge when the phone reaches 100%.
However I'm not an battery engineer, so feel free to do your own research.

phatmanxxl said:
Unless your using an SBC kernel (which our phones don't have yet), no you'll be fine. The circuitry in the phone controls the voltage to the battery when its full.
Click to expand...
Click to collapse
yea i figured as much. as long as it's not sbc kernel the battery protection should suffice.
now, my 2nd question, will this have an adverse affects if flashed on a custom rom? i'm running calkulin's

Since I don't know whether or not calkulin has a modified SystemUI.apk, I think it would be safer if you made the changes manually but you're welcome to try it. Caulkins is pretty popular so if you find out it works you'll save a lot of people a lot of grief. Switching back and forth is pretty simple, just a matter of renaming files and rebooting.

AwfulFaded said:
Since I don't know whether or not calkulin has a modified SystemUI.apk, I think it would be safer if you made the changes manually but you're welcome to try it. Caulkins is pretty popular so if you find out it works you'll save a lot of people a lot of grief. Switching back and forth is pretty simple, just a matter of renaming files and rebooting.
Click to expand...
Click to collapse
wish there was an easier way to edit the settings to try this. i am at work and don't have access to a computer to deodex.. any other way to modify these settings in the systemui.apk?

Upload your files, the apk and odex, and I'll take a look. It might not work if you're still on 2.3.4 or caulkin has made significant changes to the framework.
I wish I'd kept my 2.3.4 files and framework...
Sent from my SPH-D710 using xda premium

AwfulFaded said:
Upload your files, the apk and odex, and I'll take a look. It might not work if you're still on 2.3.4 or caulkin has made significant changes to the framework.
I wish I'd kept my 2.3.4 files and framework...
Sent from my SPH-D710 using xda premium
Click to expand...
Click to collapse
i must be deodexed because i dont have any odex files in my /system/app..
will my systemui.apk help you?
UPDATE:
latest calkulin's 2.0.1a is 2.3.6 btw (that's what i am on).. and i mentioned this mod in his thread.. and maybe this thread should be moved to android development? also, thanks alot! i hit the button.

It looks like the sound and screen-on is gone so I removed the status bar icon.
1. Copy this SystemUI(Calkulin).apk to your /system/app folder
2. Set the permissions for the file to owner: Read/Write, group: Read, others: Read (644 for those who know what that means)
3. Rename SystemUI.apk to SystemUI.apk.old (you will start seeing frequent errors at this point, this is normal and expected. Don't panic just hit Force Close to dismiss the errors and continue)
4. Rename SystemUI(Calkulin).apk to SystemUI.apk
5. Reboot
6. Enjoy​
Please try this out and let me know how it works. Thanks!

AwfulFaded said:
It looks like the sound and screen-on is gone so I removed the status bar icon.
1. Copy this SystemUI(Calkulin).apk to your /system/app folder
2. Set the permissions for the file to owner: Read/Write, group: Read, others: Read (644 for those who know what that means)
3. Rename SystemUI.apk to SystemUI.apk.old (you will start seeing frequent errors at this point, this is normal and expected. Don't panic just hit Force Close to dismiss the errors and continue)
4. Rename SystemUI(Calkulin).apk to SystemUI.apk
5. Reboot
6. Enjoy​
Please try this out and let me know how it works. Thanks!
Click to expand...
Click to collapse
OK, done. much appreciated. now i have to wait till i get home and charge my phone. will let you know in a few hours. also will give me time to see if i get any adverse effects! so far so good!

[TWEAK][APK][CWM] [update2.0.0] Seeder entropy generator to provide lag reduction

FULL CREDIT TO lambgx02!
Original Post | CWM
Guys check this out
Best result on Android 4.+
Description
Hey everyone,
So, I was experiencing significant lag as we all do from time to time, and decided I was going to get to the bottom of it.
After tracing and debugging for hours, I discovered the source of 90% of Android's lag. In a word, entropy (or lack thereof).
Google's JVM, like Sun's, reads from /dev/random. For all random data. Yes, the /dev/random that uses a very limited entropy pool.
Random data is used for all kinds of stuff.. UUID generation, session keys, SSL.. when we run out of entropy, the process blocks. That manifests itself as lag. The process cannot continue until the kernel generates more high quality random data.
So, I cross-compiled rngd, and used it to feed /dev/urandom into /dev/random at 1 second intervals.
Result? I have never used an Android device this fast.
It is literally five times faster in many cases. Chrome, maps, and other heavy applications load in about 1/2 a second, and map tiles populate as fast as I can scroll. Task switching is instantaneous. You know how sometimes when you hit the home button, it takes 5-10 seconds for the home screen to repopulate? Yeah. Blocking on read of /dev/random. Problem solved. But don't take my word for it .. give it a shot!
Update!
I've built a very simple Android app that bundles the binary, and starts/stops the service (on boot if selected). I'll be adding more instrumentation, but for now, give it a shot! This APK does not modify /system in any way, so should be perfectly safe.
This is my first userspace Android app, so bear with me!
Note that this APK is actually compatible with all Android versions, and all (armel) devices. It's not at all specific to the Captivate Glide.
Click to expand...
Click to collapse
Quote Original Post link - Click Here
Requirements
An Android device! No iPhone's allowed!
Need Root
[Optional]-Root File manager
Ryuinferno said:
Before doing anything, please read the first post of this thread to understand how this thing functions!
Read it here: First post
First things first I am not the OP but things need to be sorted out...Ok...this thread is starting to get more and more attention, which is good because with more people to test things out, the more feedbacks and the more improvements can be done...however, the thread is now cluttered by tons on unhelpful posts, like "how to use this", "do I need root" etc...useful posts get pushed wayyy behind, until it is hard for people who are really trying to discuss to keep track...so I am here to answer the basic questions:
Do you need root for the app?:
Yes
Can it work on xxx device?:
Yes, as long as your device is arm based
Where to download the app?:
Here: http://forum.xda-developers.com/attachment.php?attachmentid=1640660&d=1358063993
Or search Play Store for a donate version...
The other 2 attachments are the rngd binary and a diff patch, which are not really required for end users...
How do I know that it is working?
Prior to starting seeder entropy generator through the app (v1.2.4 onwards), the bar below will only show numbers around 100-200++. After you start it, if the bar fills up and the value shoots up to 4000++, then it is working.
Do I have a risk of bricking my device?
No because the app won't modify system files at all...anything just uninstall...
For the zip, it only adds files to your system partition...does not modify any, so if you want to stop using this, you can disable it via the extended menu script...
It does not do anything/It is placebo/I see no improvements/It is awesome!/Wow!:
Well, this is not constructive or helpful...NOT AT ALL...keep in mind that this is still a WIP...research and discussions are still going on...if it is not working or you feel no change or a great improvement, please describe more and explain...which a lot of others are already doing so......keep it up!
Seems that certain people are so bugged by the app...so...for those who prefer to run this via a script and init.d, read on...(the script works the same as the app, but with a few extra features)
=======================================================================================================================
UPDATE: Seeder_v7 is out, as suggested by pepoluan, it now detects for qrngd (built in rngd for Qualcomm Snapdragon-based devices), if it is there, then it will not start as rngd may conflict with it...the rngd binary is also using the latest version (it is turned off when screen is off)...users of previous versions can just flash it over...
INSTALLING
You need init.d support for this!
Download and flash:
http://www.androidfilehost.com/?fid=9390248398092764755
How to use this script?:
After flashing, launch terminal emulator and type
Code:
su
seeder
You will get a menu like this:
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
NOTE: There will be NO app after flashing! This only installs the necessary binaries and scripts...
For those who cannot install via recovery:
You get a status 0 error -> replace the update-binary in Seeder_v6.zip with one from another zip that works with your device
OR
Use the new installation method!
Instructions:
1. Download Seeder_v7_non-CWM.zip from here:
http://www.androidfilehost.com/?fid=9390248398092764756
2. Extract the zip, you will get a folder named "install"
3. Place the folder in the root of your sdcard (/sdcard)
4. Launch terminal emulator, type:
Code:
su
cd /sdcard/install
sh install.sh
5. Ignore any error messages (those are only warnings, only happens to current users)
6. You are done! The script will auto-delete the "install" folder as it is not required anymore...
Sample output:
UNINSTALLING:
And now for the way to clean up Seeder_7:
Via recovery:
Flash Seeder_v6&7_Uninstall.zip:
http://www.androidfilehost.com/?fid=9390248398092764753
Via terminal:
1. Download Seeder_v6&7_Uninstall_non-CWM.zip:
http://www.androidfilehost.com/?fid=9390248398092764145
2. Extract it to the root of your sdcard (/sdcard), you should get a file named uninstall.sh
3. Launch terminal emulator and type this:
Code:
su
cd /sdcard
sh uninstall.sh
4. You are done! Everything gets cleaned up, including uninstall.sh...
Click to expand...
Click to collapse
Updates
There has been a lot of controversy about Seeder/rngd. In newer versions of Dalvik, nothing touches /dev/random, and yet many users (including myself) still notice a lag reduction. There are theories ranging from kernel lock contention to UI polling load when crediting the entropy pool to simply kicking the governor. And many who believe it's all placebo. I'm trying my best to figure out what exactly is happening, and others are as well.
Someone asked how I arrived at the conclusion I did when I started the thread back in November, and I posted this; I think it might be better served here:
A while back one of the webapps I was hosting on Tomcat (server-side) was experiencing some inexplicable latency and while stracing java I saw it frequently hanging on read()'s from /dev/random. I checked the available entropy, and it was constantly under 250 or so. It was a VM, no HWRNG, so I decided to use rngd to push urandom->random.
Dropped session creation times under load from 5-10 seconds to less than a second.
It's worth noting that Linux is one of very few OSes that have a blocking RNG device. Free/OpenBSD, Windows, etc.. essentially only provide urandom. It's generally considered secure, even for long-term crypto keys, so long as the initial seed is big (and random) enough.
Checked on my device, and saw a few processes grabbing /dev/random. /proc/sys/kernel/random/entropy_avail reporting depleted input pool. Figured it was worth a shot, so I rebuilt rngd for arm (with a few patches, linked on first page), and tried it out. It made a significant difference. Posted it up on this thread, and had a lot of positive feedback. Wanted to get into Android development, so figured.. why not wrap a little UI around it. More positive feedback, so I threw it on the market as well.
I had no idea it would take off like this and was shocked when I saw it Thursday morning. I'm in the awkward position now of explaining why it seems to work for some people, and not for others, especially given the fact Dalvik doesn't have references to /dev/random as of ICS. Theories abound, but it looks like it might be an issue of polling the UI for input events when the entropy pool drops (which never happens so long as rngd is running).
I'm doing this as a hobby. I'm a *nix admin by trade, and can only spend time working on this stuff on evenings and weekends, and the last few weeks have been kinda nuts.
I want to stress to everyone that:
a) It doesn't work the way I thought it did on later Android builds, but it does reduce latency for me and many others even on these builds,
b) I'm offering (and always will offer) Seeder for free to everyone on XDA,
c) Like I say in the market description, if anyone has purchased it and it isn't working, PLEASE email me for a refund (and let me know what device you're on if you're willing).
I was one of the first to root the Captivate glide (my first Android phone), and submitted the A2DP bitpool patch; I was active in the n900 community. I hope everyone understands that I'm doing my best here!
I hope the technique proves useful to people, and if there is in fact contention at the kernel level, I hope it's solved so we all benefit.
Version 2.0.0 attached. No changes.
Version 2.0.0b1 attached. New performance profile selector, I/O queue extender, and power saving control. Improved root checking.
Version 1.4.0 attached. Major refactoring. Service control now fully asynchronous.
Version 1.3.1 attached. No changes from 1.3.1-beta.
Version 1.3.1-beta released. New root check method during ANR-sensitive code.
Version 1.3.0 attached. Proper IntentServices for process control, and notification on upgrade / loss of root / autostart failure.
Version 1.2.9 attached. Yet another update to the upgrade/autostart code.
Version 1.2.8 attached. Asynchronous startup of rngd during boot; this should solve the remaining autostart problems some users have reported.
Version 1.2.7 released. This version introduces a much more efficient suspend-on-sleep mode for rngd.
Version 1.2.6 released. This version reverts the suspend-on-sleep rngd change which may have been contributing to new latency. I'm sorting out a better way of implementing it.
Version 1.2.5 released. This version should fix the autostart failure some users have seen.
Version 1.2.4 released. This version implements a progress bar displaying your currently available entropy, as well as automatic rngd restart on upgrade.
Version 1.2 released. This version implements rngd suspend-on-sleep, and contains minor user interface updates, more robust process and superuser checks, and a new icon (thanks Nathanel!)
Version 1.1 released. This version uses the release signature, so you will need to uninstall the old XDA version first!
Download and flash this if you dont know what to download xD Click here!

if this really works... wow
then it should be included in all custom ROMs from now on and a patch merged into AOSP

Holy crap dude! Using it now on my Gnex. Gunna give a few to see if it really does increase performance. As far as I can tell since installation scrolling in tapatalk has increased tenfold.
Sent from my Galaxy Nexus

Holy crap! Gonna try this now!
EDIT: I've got TWRP, will the CWM zip work in it?

Larry94 said:
Holy crap! Gonna try this now!
EDIT: I've got TWRP, will the CWM zip work in it?
Click to expand...
Click to collapse
I've not tried on TWRP but should work! Flash it! This works on any device also
Sent from my Nexus 7 using xda premium

bradman117 said:
I've not tried on TWRP but should work! Flash it! This works on any device also
Sent from my Nexus 7 using xda premium
Click to expand...
Click to collapse
Hmm, only files I have in xbin after flashing is bttest, dexdump, and su. :/

Larry94 said:
Hmm, only files I have in xbin after flashing is bttest, dexdump, and su. :/
Click to expand...
Click to collapse
U need to do it manually then with root explorer. Look at bottom of my post. Or try redownload and flash
Sent from my Nexus 7 using xda premium

I just use the app... It seems to work just fine
Sent from my Galaxy Nexus

ÜBER™ said:
I just use the app... It seems to work just fine
Sent from my Galaxy Nexus
Click to expand...
Click to collapse
I got tired of turning it on every reboot that's why I used flash.
Sent from my Nexus 7 using xda premium

Just unzip flash and download other file I put up under were I put were the files go. Place and fix the files permission
Sent from my Nexus 7 using xda premium

bradman117 said:
I got tired of turning it on every reboot that's why I used flash.
Sent from my Nexus 7 using xda premium
Click to expand...
Click to collapse
It has a set on boot option.
Sent from my Nexus 7

bradman117 said:
I got tired of turning it on every reboot that's why I used flash.
Sent from my Nexus 7 using xda premium
Click to expand...
Click to collapse
Would you mind doing me a quick favor? The permissions look a little different in ES File explorer. Would you install it, navigate to the different files, long press, properties, and select permissions and grab a screen shot?

I don't feel any improvements on my Nexus7, someone yes¿
Br.

Seems to work for me. Modern Combat 4 used to lag before, flashed this and played a match with no lag. You have my thanks
Sent from my ParanoidAndroid/franco.Kernel powered Nexus 7 with XDA Premium

Nothing for me either and everytime I go into the app it shows it as off.

I flashed the CWM version because the app wouldn't stay on or switch on at boot. Haven't really noticed any difference yet, because I don't have any game that lags, including vice city on max settings, and I'm not over clocking yet either.
If MC4 has the occasional stutter then I'll try installing that and see.
Edit: forgot to mention, I also put it on my galaxy s1, and I can tell you that I do notice a definite difference on that.
Sent from my Nexus 7 using Tapatalk HD

I think I need a kernel with init.d support right?
Don't work on stock...
\\\... send with the Nexus 7 3G ...///

IAmNice said:
Above check set on boot
Sent from my E15i using xda app-developers app
Click to expand...
Click to collapse
I did. It didn't work for me.
Sent from my Nexus 7 using Tapatalk HD

DominatingSystem said:
I think I need a kernel with init.d support right?
Don't work on stock...
\\\... send with the Nexus 7 3G ...///
Click to expand...
Click to collapse
ya u need custom kernel that supports init.d.

knuckles1978 said:
I did. It didn't work for me.
Sent from my Nexus 7 using Tapatalk HD
Click to expand...
Click to collapse
thats why i put files on manually. set on boot didn't work for me
----EDIT---
Updated post, added downloads if you want to do it manually

Full Settings app

First off, THIS COULD DAMAGE/BRICK YOUR GLASS! I'm not responsible for anything that happens to your Glass directly or indirectly caused by this app.
I've spent the last few days getting a build environment set up to build APKs that require the internal and hidden APIs for Glass. As a test I've built the stock 4.0.3_r1.1 Settings.apk with as few modifications as possible. In particular I've made the following changes:
1) Removed as many theme references as I could so that the menus would feel at least reasonably glass-like.
2) Removed HOME intents (used by CryptKeeper; I would not recommend trying to encrypt Glass, and receiving this intent was messing up Glass every time I turned the screen back on)
3) Removed android.uid.system shared user ID. Based on my minimal knowledge of these things, I don't think you can install the APK as the system user unless the APK is signed with the same signature as the ROM.
4) Added various permissions to AndroidManifest.xml to make a few more things work since the app isn't installed as the system user.
I haven't done much testing; really I've only tested things like the About screen, view installed apps, and the battery stats. If you try to actually change any settings, you'll probably get a crash due to some missing permissions because the app isn't running as system. Also anything that uses a seek bar is broken, so setting brightness, volume, etc seems broken. Really, don't expect much of anything to work. Google has changed several things under the hood, and I haven't really customized this app for Glass beyond just making it work. It is kind of neat seeing the About screen though.
To install: Use adb. You don't need root.
To run: I've been using Launchy

dpw13 said:
First off, THIS COULD DAMAGE/BRICK YOUR GLASS! I'm not responsible for anything that happens to your Glass directly or indirectly caused by this app.
I've spent the last few days getting a build environment set up to build APKs that require the internal and hidden APIs for Glass. As a test I've built the stock 4.0.3_r1.1 Settings.apk with as few modifications as possible. In particular I've made the following changes:
1) Removed as many theme references as I could so that the menus would feel at least reasonably glass-like.
2) Removed HOME intents (used by CryptKeeper; I would not recommend trying to encrypt Glass, and receiving this intent was messing up Glass every time I turned the screen back on)
3) Removed android.uid.system shared user ID. Based on my minimal knowledge of these things, I don't think you can install the APK as the system user unless the APK is signed with the same signature as the ROM.
4) Added various permissions to AndroidManifest.xml to make a few more things work since the app isn't installed as the system user.
I haven't done much testing; really I've only tested things like the About screen, view installed apps, and the battery stats. If you try to actually change any settings, you'll probably get a crash due to some missing permissions because the app isn't running as system. Also anything that uses a seek bar is broken, so setting brightness, volume, etc seems broken. Really, don't expect much of anything to work. Google has changed several things under the hood, and I haven't really customized this app for Glass beyond just making it work. It is kind of neat seeing the About screen though.
To install: Use adb. You don't need root.
To run: I've been using Launchy
Click to expand...
Click to collapse
Is your Launchy still working after the XE12 update?

Yep, seems to be working fine.
* Update: I should note that I built Launchy from source this past weekend, and I don't use it through the settings card; I use it by either saying "ok glass, run an app" or by tapping on the clock and scrolling to "Run an App".
Sent from my HTC Vision using xda app-developers app

deleted.I was totally off topic

Adding to my Repo
dpw13 said:
First off, THIS COULD DAMAGE/BRICK YOUR GLASS! I'm not responsible for anything that happens to your Glass directly or indirectly caused by this app.
I've spent the last few days getting a build environment set up to build APKs that require the internal and hidden APIs for Glass. As a test I've built the stock 4.0.3_r1.1 Settings.apk with as few modifications as possible. In particular I've made the following changes:
1) Removed as many theme references as I could so that the menus would feel at least reasonably glass-like.
2) Removed HOME intents (used by CryptKeeper; I would not recommend trying to encrypt Glass, and receiving this intent was messing up Glass every time I turned the screen back on)
3) Removed android.uid.system shared user ID. Based on my minimal knowledge of these things, I don't think you can install the APK as the system user unless the APK is signed with the same signature as the ROM.
4) Added various permissions to AndroidManifest.xml to make a few more things work since the app isn't installed as the system user.
I haven't done much testing; really I've only tested things like the About screen, view installed apps, and the battery stats. If you try to actually change any settings, you'll probably get a crash due to some missing permissions because the app isn't running as system. Also anything that uses a seek bar is broken, so setting brightness, volume, etc seems broken. Really, don't expect much of anything to work. Google has changed several things under the hood, and I haven't really customized this app for Glass beyond just making it work. It is kind of neat seeing the About screen though.
To install: Use adb. You don't need root.
To run: I've been using Launchy
Click to expand...
Click to collapse
Hello, I have tested this application out and it works very well with Google Glass! Thank you so much for this, I will be sure to add this to my Open Source Google Glass Development Repository: https://github.com/jaredsburrows/OpenQuartz
I'll make sure to keep a link to this thread for updates!

[NST/G] Salvaging CM 11

First, the tease.
Note: This video was prepared before I thought about/tested Aldiko Classic as a replacement (and improvement) for Overdrive. See post #2 for more information.
Disclaimer: I am not responsible for any damage that might result to your device by improperly using the files I have provided. Do not charge your device while reading in the bathtub. Do not use your device as a projectile. Read safely.
I've been working with the abandoned sdcard-based CM 11 ROM for a couple of months now, trying to see if anything could be done with it. Having never tried it back in 2015 when @kfazz was actively working on it, I wasn't sure what to expect, but having worked with an 8 gb Nook Tablet ("only" 512 mb RAM) for a long time and with various resource-hungry ROMs, I wasn't expecting much.
First, two myths to dispel:
1. It will NOT "burn" spots in your display. Trust me, if it hasn't done anything to mine in the endless hours I've spent swearing at it, it won't hurt yours.
2. It does NOT leave your stock internal storage entirely alone, but the change is minimal. An "Android" folder is placed in /media and a few apps may store a little data there.
Here's a short list of issues I found, in no particular order. Some are just annoying and can be addressed peripherally. Others are more granular in nature and are beyond anything I could fix. It may now be impossible to address the issues directly if this post is any indication. Of course, the Cyanogenmod folks have moved on to Lineage so the build components may not be accessible any longer.
1. it is sloooooow
2. it is not nice to look at (all Themes I tried destabilized the ROM--so live with it)
3. it does not understand the whole screen off/sleep/wake routine
4. it doesn't really seem to understand the whole e-ink thing
5. it drains battery power like a Black Hole app has been installed
6. it is a nuisance to swap out the sdcard to boot this ROM
7. it is a little unstable....
8. booting into TWRP can be very frustrating
9. the shutdown screen is a crapshoot (all white, the current display, a garbled mess, etc.)
I could go on, but as I worked with the ROM my perspective changed repeatedly until I finally realized that rather than complaining about what it could not or would not do, it would be more helpful to see if it could be used to do something that the stock NST no longer could. For example, NoRefresh doesn't work on the CM 11 ROM but it works wonderfully on the stock NST. There is some issue with screen overlays in KitKat and they are used in the NoRefresh app. Also, there is no USB Host in the CM 11 ROM, although this was mentioned early in the original postings. But USB Host (and Audio) works famously on the NST. Etc. So perhaps the real issues should be:
1. Is there any reason to run the CM 11 ROM?
2. If CM 11 is not fit to be a daily driver, could it be possible to go back and forth between stock and CM 11 easily?
Also, the two ROMs share a common partition: /media (called sdcard1 on the CM 11 ROM). This means files can be shared between them. So I can use a more modern browser (but not very modern....) on the CM 11 ROM to download a PDF of the newspaper (something Opera Mobile cannot negotiate on the stock ROM), move the file to the shared partition, then reboot into the stock ROM and read the file using EBookDroid with NoRefresh Or, I can download an app using the Yalp Store (which should run on the NST but does not), move the file to the shared partition, reboot and install the app on the stock ROM (if it runs on Android 2.1).
What I've done
I have worked mainly with build 2 of the CM 11 ROM. Initially I found build 3 to be markedly less stable, but it may be worth it to revisit my work at some point now that I'm not going to be trying truly crazy stuff. These are the changes I have made:
1. Removed Calendar and Calendar Storage. If you want a local calendar, you can extract the apps from the original build 2 ROM zip or any other CM 11 ROM.
2. Removed Sound Recorder (duh)
3. Removed Trebuchet launcher. It's just hopeless for the NST display.
4. Removed a bunch of Wallpaper and Theme stuff. Face it, plain white (included) is best for the wallpaper.
5. Removed Bluetooth app (duh)
6. Replaced the broken Gallery
7. Restored People (contacts) for local use (load in a .vcf file)
8. Restored the stock AOSP Email app
9. Added a custom boot splash screen (whoopee!)
10. Added ADW Launcher to replace Trebuchet
11. Added AdAway
12. Added the Yalp Store (fork)
13. Added a re-themed RotationLocker (you can actually read the options!!!)
14. Added the updated kernal files and recovery files suggested in the original thread
15. Added the Boot Nook OS app (this, with a companion app for the stock NST allows a form of "dual boot")
16. Added the Screensaver app (this works--mostly--like on the stock NST)
17. Added an NLP app for Location, if turned on
18. Enlarged the /userdata partition to 1 gb
19. Slightly edited build.prop so apps that try to ID the NST can succeed
And, of course, I've combed through the settings for both the ROM and launcher, trying to minimize animations, kill background processes, etc. Anything to calm the OS down.
I have prepared two sdcard image files (see downloads section below). Unlike the images in the original post, these are installed and pre-configured so they are ready to try as soon as you write them. Of course you may not agree with all my settings/tweaks, and are free to take my work as a starting point. I'm hoping that this post may revive some interest in this ROM and people with more knowledge than I will run with it, or at least offer a few more tips and tweaks.
"Dual Boot"
I looked at this issue for a long time. In the development work on the Nook Color someone eventually produced a mod to enable booting to either internal or sdcard ROMs by holding down the "n" button during boot for one of the options. Eventually someone else came up with a boot menu. These innovations involved u-boot and kernals. This is arcana to me, way beyond my pay grade. I did make a desultory binary comparison of some files and eventually gave up. Then one day an outside-the-box idea came to me. What would happen if the device could not boot from the sdcard for some reason? The answer is: it would boot from the internal stuff. A quick renaming of u-boot.bin on the sdcard confirmed this. So, how to rename this file going from either ROM? Coming from the stock ROM it's easy because the "boot" partition of the sdcard is a FAT32 partition and the only part of the card the stock ROM can see. Then just add a reboot command. Done.
Coming from the CM 11 ROM it is more complicated because the "boot" partition is invisible. With the help of @Renate NST I was able to sort out a series of shell commands which mount the "boot" partition, rename the file (I finally settled on renaming MLO rather than u-boot.bin), and execute a reboot. So a different but simple app for each ROM and you can go back and forth without shutting down and swapping cards. The added advantage is that you can put the NST to bed on the stock ROM where it will not use so much power, rather than shutting it down entirely.
Setting up "dual boot" requires a little work if you want to maintain your existing stock files on the sdcard. Here are the steps:
1. Copy the contents of the regular sdcard you use in your NST to a PC.
2. Insert the CM 11 sdcard you have prepared by burning one of the two images I supplied into the card reader of your PC.
3. Start MiniTool Partition Wizard.
4. Identify the sdcard in MiniTool Partition Wizard. You will see that there are four partitions. The "boot" partition is the first and active one. Right-click on this partition and select "Extend". When the dialog appears, drag the sizing indicator all the way to the right (i.e., use up all the unallocated space).
5. When you've got all the changes set up, be sure to hit "apply" so that it all really happens.
6. Close MiniTool Partition Wizard.
The card is now fully accessible to the stock ROM except for the three hidden CM 11 ROM partitions, /system, /cache, and /userdata. Copy the contents of your regular sdcard that you previously saved on your PC onto the newly adjusted CM 11 card. Voila!
The only drawback (besides the loss of about 2 gb of space) is that the files in the "boot" partition will be visible when you use a file manager from the stock ROM. I use ES File Explorer on my stock NST and it allows me to hide files and folders I don't need to access and don't want to look at. Otherwise, you just need to ignore them (and certainly don't delete them!).
Oh, and you need to install the "Boot CM 11" app on your stock NST (download section below). This is a Tasker-generated app. If you already have one of my other Tasker-generated apps or have previously installed GApps, you don't need the two Google maps library files included in the zip and can delete them. If you do need them, copy the two files into the locations shown below (remember, these are for the stock NST--the CM 11 ROM already has these files):
/system/etc/permissions/com.google.android.maps.xml
/system/framework/com.google.android.maps.jar
Set permissions for both files to rw-r--r-- and reboot. Without these files resident, the app will not install.
Apps
I went pretty much nuts at the beginning of my work, installing all kinds of stuff. A lot didn't work. This ROM is not a panacea for all the issues surrounding the aging (but beloved) NST and certainly not the place for fancy screen tricks and cute widgets. There just isn't enough RAM. There are other issues, but that is the big one. I recognize all the signs from my work with the RAM-poor 8 gb Nook Tablet. Of course, the processor is also slow. And there are display issues with the e-ink that some apps just can't get past, not to mention a rather odd screen size and aspect ratio. Here's what I learned:
Stock apps
The stock apps I left on the ROM all work "OK". I don't much care for the File Manager because there is no simple way to get out of it and contrast seems unneccessarily poor, but ES File Explorer (the 3.x series) runs more slowly and gets confused about the emulated and internal storage. It also interacts poorly with the package installer, taking a very long time to install apps. Email works fine and easily adds Gmail accounts. Others might require a little more work. Of all the system apps, the Browser is the most impacted in performance by the device and ROM limitations. I have found this to be true with all the ROMs I have worked with on the Nook Tablet. For KitKat the problems are exacerbated by the outdated Webview. Some sites (like XDA!) cannot display properly. Form input and even response to touching "buttons" is just really awful. If you are patient and don't madly tap over and over to get the attention of the device, you can use the stock Browser, but it is prone to freezing and crashing. That said, it can do some surprising things. For example if you are signed in to Google (painful in itself), it is able to display your full calendar (the only way to see it on the non-microG version), but it takes a long time. I left the app on the ROM, but you could remove it. I use it to access the newspaper, but only to get to the point where I can download a PDF, not to actually try and read it in the Browser. If the stock Browser has any other saving grace it is that the page-up and page-down commands (lower two hardware buttons) move the display. This compensates somewhat for the lack of NoRefresh and the rather overenthusiastic swipe-scroll response of the ROM.
I tried oh-so-many other browsers. I can't begin to count. The performance of most all was dismal. In the end, I settled on Opera Mini (but not the version that runs on the stock NST). I'm not a big fan of Opera Mini. There are many sites it can't display, but this version, which includes an ad-blocker, works really well with library OverDrive sites (yes, you read that correctly!) and generally sails through forms and interactive screens. Unfortunately it does not respond to the page-up/down commands.
Other user apps
I tried all the typical readers before I realized that was just stupid. Most work very well, although you need to up the version on a few to achieve full-screen reading, and the readers with bookcover screensaver actions need modifying to find the correct folder. I did this successfully with the current PlayStore version of AlReader but had less success with CoolReader. The FBReader version for the NST cannot display full screen, but the ICS version (available from the FBReader website) works well and can run the PDF plugin (presumably the DJVU as well). No version of Kindle runs well--if at all. The closest thing is Kindle Lite 1.9, but it is quite slow and cannot read local .mobi files. The right version of OverDrive runs reasonably well once the book is loaded. If you want to run OverDrive, be sure to look at the second post in this thread. News apps were possible but just really, really slow. Any app that needs to assemble a complicated Webview is a problem--this includes the in-app library browser of OverDrive. And then there is the issue with GSF (Google Services Framework). We don't really run into this with the stock ROM because all of our apps are so old. But with KitKat you begin to get apps that refuse to run or run poorly because you don't have GApps installed. Even the NPR News app....
So let's talk Google. First, NO GApps. Never. No. Just no. The ROM, as configured, runs with about 60-90 mb of free RAM (at least according to the information shown in Settings), a little more if you forego Email. In an extended moment of folly, just to see, I did struggle with GApps, after enlarging the /system partition on the card. It took two days, much searching on-line, and many words that do not come from children's books, but I did get a pico GApps package installed. That left about 30 mb of free RAM and absolutely nothing would work. I knew that would be the result from my work with the 8 gb Nook Tablet, but I just wanted to say, authoritatively, NO.
However...my work with the Nook Tablet also eventually led me to microG. Could that even work on this ROM? The short answer is yes. I have successfully enabled signature spoofing (but only for microG) and installed and configured microG.
microG, at its most basic level, spoofs the signature of GSF that many apps look for. At that level of service it adds very little overhead to the system. The next step up is adding an actual Google account. This does increase system activity but only a little if you don't go crazy with things. With an account you can run some Google apps like Books and Drive, assuming you can find versions that will work.
I've identified working versions of Google Play Books and Google Drive (included in the apps download below), but I don't guarantee they will work forever. Even after I thought I had found a good version of Google Play Books I got an email from Google saying they were going to stop supporting that version "soon". So I tried a few more recent versions and found another. No emails so far...
You could theoretically run the PlayStore at this level of microG, but it just won't work on this device. Google insists on updating it and while a Jellybean version might run quite well, it won't be around long and then after the automatic update it will be a useless burden on the system. Fortunately, the fork of the Yalp Store (which should run on the NST but does not) works well on the CM 11 ROM, although not with a generic Yalp Store account. I opened a Google account just for this purpose when I started working with the 8 gb Nook Tablet and this is the only thing I use the account for. I suggest you do something similar, just in case. This will give you PlayStore access, although you will not be able to purchase apps. If you select the microG version be sure to take a look at post #3 below.
That's about it. I tried a Crossword app, and a few other oddities, but in the end I still feel that running things on this ROM that function perfectly well (or better) on the stock ROM does not make a lot of sense. It should be all about the stuff you otherwise could not do--within reason
Lastly, a word about my Screensaver app. I've attempted to "solve" or work around a number of issues using this app. The screen off/sleep/unlock cycle only works "correctly" when the device is plugged in (AC or USB). Otherwise, waking the device requires a tap on the power button followed by a press of the "n" button. Perhaps that's a "feature". When I finally understood the situation I tried to figure out how to work around it. Eventually I hit on the idea of spoofing the battery state at "screen off" if the device is not charging. So the app monitors the screen and when it detects the screen-off state it tells the system that wireless charging has begun (if there is not already charging happening). Then the app pushes an image to the screen (which would otherwise be either black or the last current display--at random). Tasker (which I used to create the app) cannot overlay the nav bar so you will still see that. That means screensaver images are about 600x752 rather than 600x800. This generally works quite well, but there are two issues I have not been able to solve. Sometimes the first screen off goes to black. After that it all works fine. Also, pushing the image to the screen seems to reset the lock timer. So if your timeout is set to 5 minutes, the screen remains unlocked for roughly another 5 minutes after the image is displayed. During this time a simple swipe across the image in any direction will clear the screensaver (and reset the battery state). Otherwise, after lock, a press of the "n" button, followed by a swipe over the image will both unlock and clear the image (and reset the battery state). I tried sending a lock code myself after the image was displayed but that always resulted in a black screen. You can change the screensaver folder as long as you place your images in a folder inside /storage/emulated/0/Screensavers. If there is more than one image in the folder you select, the app will cycle through them, just like on the stock NST.
As a hopeful afterthought I also tried to address the random shutdown image. A careful reading of the original thread indicates this is supposed to be a white screen. The developer admitted this was subject to perfect timing, racing against the clock before parts of the system shut down. I attempted to force a blocking overlay onto the screen when shutdown is detected. A blocking overlay cannot cover either the status bar or nav bar, but at least you could tell the device is off. When it worked. For the time being I have removed this feature because it's almost as random as the native ROM itself. I'll keep picking at it, but I'm out of ideas at the present.
Getting going
1. Download one of the two images below, choosing whether you want the simple version or the one with microG installed. Each image is just over 2 gb so you will need at least a 4 gb sdcard to burn, probably larger if you plan to run "dual boot". I generally use 16 gb cards with most of my devices (a few have 32 gb cards), but that's probably overkill for the NST.
2. Use Win32DiskImager or similar to burn the image you downloaded to the card.
3. If you intend to run "dual boot", follow the directions above to extend the "boot" partition over the unallocated section of the card and copy your existing stock ROM sdcard files to the card. You will also need to install the "Boot CM 11" app on your stock NST (the companion app is already on the CM 11 ROM).
4. Shut down your NST, insert the CM 11 card and power up. The device will boot into CM 11 in three "stages": a splash screen, a white screen, a black screen. A very few apps have been pre-installed and some general configuration has been done. The rest is up to you!
Note: you don't have to be concerned about the hardware information like serial number, MAC address, etc. When the CM 11 ROM boots it apparently reads these from the internal storage. I tried this by switching my working cards to another NST and found that the values were correct for the currently running device.
TWRP
Remember the disclaimer at the beginning? That bit about not using your device as a projectile? That is about TWRP. Works great if you can get to it. From power off, or on reboot, press and hold the two lower hardware buttons as soon as you see the splash screen. Count to ten (not too slow, not too fast....) and then release the buttons. If you are successful, the boot process will briefly pass into the white screen and then TWRP. If you have an NSTG, the light will come on at some point (but that may not mean ultimate success). I've looked at this quite a bit to see if there could be a way to construct a simple app to force a reboot into TWRP without the button business. Just before posting all this I took another look through the original thread and there was the answer staring me in the face. But it's not a good answer. I have put together a small app to "force" a reboot into TWRP. It does this by mounting "boot", renaming boot.scr to boot.scr.bak, making a copy of twrp.scr named "boot.scr" and rebooting. This has a better success rate than the traditional method (at least for me), but it does occasionally hang at the splash screen (which is what the button method does for me about 80% of the time). In the two installations I have tried it failed on the first try, perhaps because of the delay in obtaining SU permission. Then it was fine. More importantly, the device is going to keep booting into TWRP unless you undo what the app did before you leave TWRP. It's lame, I know. The directions are given in the dialog box called up by the app. I did not include this app with the images because it really is just barely a "fix". If you want to give it a try, you can get it from the downloads section below.
If you want to flash any zips place them in /media on the stock NST, then mount /media when you enter TWRP.
If you want to make a backup it's tricky. This version of TWRP is coded to see only "internal" storage. But that's not what you might think. It's the sdcard, but only part of it. Despite having loads of free space on my sdcard it keeps showing me "569 mb" or similar. That is obviously not enough space for a 2+ gb backup, although of course the actual file contents are less than that. I believe this space measurement is the free space in the /userdata partition since backups appear in /storage/emulated/0/TWRP/BACKUPS/<serial_number>. So one approach is to enlarge this partition enough to accommodate a full backup. But that makes an image painfully large to download. My idea so far has been to make one or two backups, depending on how much is in userdata. So maybe system+cache, and userdata. Or, if there is enough space, all three at once. After each, I reboot and copy off the file to my PC, then delete it on the device. I successfully did a two part backup and then restored it, system+cache first, then after a reboot, userdata. This worked. The "boot" partition is easy enough to backup manually because your PC can see all of it.
"This was all a waste of my time. How can I recover my sdcard?"
Insert the card into the card reader of your PC and copy off the files from the stock ROM to restore to a clean card. Start MiniTool Partition Wizard. Identify the sdcard and right click on the three partitions: /system, /cache, /userdata, and delete them. Apply. This leaves only the active "boot" partition and some "unallocated space". Right-click on this partition and Extend it over the freed up space. Apply. You should now have a single space equivalent to the size of the card in a single partition. At this point the card can be reformatted with Windows or something like SDFormatter.
Downloads
NST_CM11.img (2 gb)
NST_CM11_microG.img (2 gb)
Boot_CM11.zip (for the stock NST)
Boot_TWRP.apk
CM11_Apps.zip

OverDrive (and Aldiko)
I was originally thinking about making another video but I am still recovering from the drama/trauma of making and posting my first YouTube video...so maybe later. Or not.
One of the things that first made me look at the CM 11 ROM was the potential promise of OverDrive. I've always thought the abandonment of the NST was one of the unkindest cuts. Unfortunately this is not a story with a totally happy ending. You can use the CM 11 ROM to run a version of OverDrive and you can checkout books from your library, but you have to go about it just right or it will drive you into hurling your device across the room. And then there is the issue with the actual book loading time, as seen in the infamous video in the first post. I can't do anything about the latter, but I have developed a method for checking out books that is actually pretty painless. Here is a step-by-step description of the process. YMMV.
0. You need to authorize the OverDrive app with your Adobe ID. If you're doing a lot of experimentation, be careful with this. I eventually used up my account allotment by carelessly uninstalling versions that did not work properly without first de-authorizing them. When I appealed to Adobe to reset my count (as I had read I should) I got a string of people who had no idea what I was talking about and apparently had no comprehension of the English language. I eventually just gave up on my old account and opened a new one.
1. Navigate to your library OverDrive website using Opera Mini. Sign in with whatever information you normally use (library card number, OverDrive account, etc.). DO NOT attempt to use the OverDrive app to search for your library and browse it. That way madness lies.
2. Find a book you want and go through the usual steps to check it out, eventually ending with the "Download EPUB". Some sites use pop-ups or overlays for the checkout process. Occasionally these end up "off the screen", i.e., you need to scroll back to the top to see them. After the first time you'll know better what to expect.
3. The download of the .acsm file is very quick and you'll see the notification appear briefly. DO NOT EXIT OPERA MINI AT THIS POINT! This will cause the notification to disappear. Although the activity picker *should* open OverDrive when the .acsm file is selected in the File Manager, it does NOT. Instead, pull down the notification window and tap on the "Download Complete".
4. OverDrive opens and the book is downloaded.
The process is similar if you select a Kindle (.mobi) format book, except there is no download. Instead you need to head over to Amazon.com and arrange for delivery of the book to your device (the stock NST). This is totally doable with Opera Mini. On my device I have added both my local library OverDrive site and the device and content management section of Amazon.com to the Speed Dial and also as shortcuts on my home screen. ADW Launcher allows you to edit both the text and icon for a shortcut (double tap on the icon to edit) or any other icon, for that matter, so you can dress things up how you like.
Aldiko
As I was wrapping up the materials for the first post a few of my little grey cells whispered "aldiko" to me. Duh! I had forgotten about that particular reader app with the ability to download Adobe DRM books. The old version that "runs" on the stock NST can't do that anymore, but could a new one...?
Here's what I have found out so far. I downloaded and installed the final version of what is now called "Aldiko Classic" from the Yalp Store. First run is a little cranky (true of many apps) but it settles down. After authorizing it with my Adobe ID I tried the actual in-app library browser. This was actually almost bearable, certainly much faster than OverDrive which is hopeless. I eventually completed a checkout completely inside the app and fulfilled the book. It would probably be easier starting with Opera Mini, although I'm not sure how the .acsm file would be handled. I still need to test that. The good news is that the book opened and displayed in a timely manner, just about like any of the other non-OverDrive readers I had tried before.
The bad news is that there was a mysterious notation on the library OverDrive site which I had never seen before. Something about my device no longer being able to access digital content after 10/30/2020. There was a link but the in-app browser refused to follow it.
Edit: here is a sequence that works for me with Aldiko using Opera Mini
1. Navigate to your library OverDrive site using Opera Mini and sign in.
2. Select a book to download.
3. When the .acsm file has downloaded you can exit Opera Mini.
4. Using the File Manager, go to the Download folder and tap on the .acsm file. The activity picker will show Aldiko as one option. Tick the "always" (or whatever) option and select "Open".
5. Aldiko begins downloading the book and places it on the bookshelf. It may have trouble opening it the first time, but that could just have been a hiccup on mine. Otherwise, a very smooth and satisfactory process.
This might be a better option than OverDrive. It certainly opens the books quickly.
Edit-Edit: I tracked down the mysterious message. It's not good. Basically people with custom ROMs (or even just ROMs that for some reason do not receive updates) are being shafted unless they have some way to do a TLS 1.2 update. Remember that? Thought it was done? Apparently the folks at OverDrive disagree. I'm guessing you don't see the message in Opera Mini because it is actually Opera's up-to-date servers that are accessing the website. So it may remain possible to download the .acsm file but it's a guess whether Aldiko will be able to fulfill the book. The rather fussy and technical message suggests that OverDrive apps on devices not updated will not be able to fulfill books. Time will tell.
An update on DRM books with Aldiko.
As of mid-November 2020, I have still been able to fulfill Adobe DRM books from the library using Aldiko as described in post #2. So either Adobe is a little behind the curve (not hard to believe...) or else the security chops of this ROM are sufficient for them--for now.

microG (and Calendar)
If you're not familiar with microG, here is a quick run-down.
If you just don't want to have any trouble with apps that use GSF, you can use the CM 11 image with microG installed. You don't need to do anything else.
If you want to run a Google app like Books or Drive, you will need to add a Google account. This can be done through the microG settings app or via the CM 11 Settings app. The process is slow and keyboard response is temperamental, so be prepared. You will also need to enable Google device registration in the microG settings app.
Calendar Edit: 9-30-22: This no longer works. Calendar is, in fact broken.
Never say never. I was pretty sure this was broken, although I thought it once worked. It turns out I was right on both accounts. More importantly, the version of microG which worked with Calendar still appears to work overall, but there is a catch. Here's what you need to do:
1. The existing com.google.android.gms........apk needs to be replaced with com.google.android.gms-19420020.apk
2. Calendar.apk needs to be added back to /system/app (permissions: rw-r--r--)
3. GoogleCalendarSyncAdapter.apk needs to be added to /system/app (permissions: rw-r--r--)
4. CalendarProvider.apk needs to be added back to /system/priv-app (permissions: rw-r--r--)
5. Reboot
The catch: you must add the Google account while trying to start Calendar. This will happen automatically when you try to open Calendar. Adding the account in this way makes it work for everything on the device. Adding it as described above makes Calendar ignore the account. Go figure.
If there is any interest in Calendar, I can put together a zip package to download the needed files.

Discoveries
7-13-22
1. Alternative launcher: Simple E-ink Launcher is just what it says. I came across it while reading about the alternative firmware developed for the Nook Glowlight series. This launcher is part of the package. Very spartan. Nice if you only have a few apps. See image below.
2. General purpose reader: Yeah, I remember what I said, but I was surprised at just how well Koreader performed on the ROM--once you change one setting.
The setting in question has to do with "flash-back" (i.e.,visual cue that you touched something). The ROM does not like this setting at all, but if you can live without it, it all works great. Image attached below shows how I have those particular settings (found from gear-->screen-->E-ink settings).

support!

Thank you for posting. I was trying to see if I could refresh my nook without glowlight, and got here. suprised that someone is working on it after all these years. All the best!

Hyped as **** for this!

This is awesome! It runs well on my Nook Simple Touch with Glowlight from a 16gb micro SD card. There are a few issues but I can live with most, however one is quite annoying. The issue I have is that I can't charge my Nook while in Android 4.4. If I boot it to the original OS (version 1.2.2) then it charges fine. The other major issue is that the battery percentage reported in Android 4.4 does not match the one shown in the stock OS at all. The stock OS reported 6% battery while the Nook OS said 16%. These issues are both seemingly random since sometimes it does work. It will say it's plugged in but not charging in the battery section of settings in Android 4.4 and I can always tell by the LED light. If it's not charging but should be, it will be green, if it's charging when it should be then it's yellow. It does work sometimes but requires some rebooting and messing with things to get it to be functional. Otherwise I love it! My nook also has a brand new battery and does last a long time, though it would be cool to see battery life improved in Android 4.4.

ELECTROHAXZ said:
The issue I have is that I can't charge my Nook while in Android 4.4. If I boot it to the original OS (version 1.2.2) then it charges fine. The other major issue is that the battery percentage reported in Android 4.4 does not match the one shown in the stock OS at all. The stock OS reported 6% battery while the Nook OS said 16%. These issues are both seemingly random since sometimes it does work. It will say it's plugged in but not charging in the battery section of settings in Android 4.4 and I can always tell by the LED light. If it's not charging but should be, it will be green, if it's charging when it should be then it's yellow. It does work sometimes but requires some rebooting and messing with things to get it to be functional.
Click to expand...
Click to collapse
Unfortunately the power/charging/sleep/screensaver are all tangled up together. With the screensaver app I made the way it is supposed to work may not always be the way it works. But you can humor it. Try this:
Only plug in to charge with the screensaver dismissed (i.e., before the device has gone to sleep). Before disconnecting from charge, dismiss the screensaver. This seems to be the biggest stumbling block as the ROM wants to change the way the "n" button works if it's in a sleep cycle. The screensaver app is trying to work around that, but there is this grey area of charging when asleep. Try it and see if that helps (you'd need to do a fresh boot, though, if the device shows charging when it is not plugged in before you adopt this regimen).
This may also clear up the battery % discrepancy you are seeing between stock and CM11. I haven't had a chance to run mine long enough today to check on that, but I don't remember seeing the problem during the original shakedown. If I see that later today, I'll report back. (you can expect to see minor differences depending on how close the percentage is to changing when you go from one OS to the other as the boot process does gobble up some electrons)
Edit: I ran my NST on the CM11 ROM for most of the day, doing some charging and some cleanup here and there of things that had changed since I last booted it up. Everything was fine as long as I observed the sequence described above for charging and unplugging. The battery indicator on the CM11 ROM showed 85% when I booted back into the stock ROM. There it showed 84%. Probably the squirrely behavior you observed was tied to the bolluxed charging indicator/screensaver issue. It's just touchy and if you want to use it you need to learn its foibles for the best overall experience.

nmyshkin said:
Unfortunately the power/charging/sleep/screensaver are all tangled up together. With the screensaver app I made the way it is supposed to work may not always be the way it works. But you can humor it. Try this:
Only plug in to charge with the screensaver dismissed (i.e., before the device has gone to sleep). Before disconnecting from charge, dismiss the screensaver. This seems to be the biggest stumbling block as the ROM wants to change the way the "n" button works if it's in a sleep cycle. The screensaver app is trying to work around that, but there is this grey area of charging when asleep. Try it and see if that helps (you'd need to do a fresh boot, though, if the device shows charging when it is not plugged in before you adopt this regimen).
This may also clear up the battery % discrepancy you are seeing between stock and CM11. I haven't had a chance to run mine long enough today to check on that, but I don't remember seeing the problem during the original shakedown. If I see that later today, I'll report back. (you can expect to see minor differences depending on how close the percentage is to changing when you go from one OS to the other as the boot process does gobble up some electrons)
Edit: I ran my NST on the CM11 ROM for most of the day, doing some charging and some cleanup here and there of things that had changed since I last booted it up. Everything was fine as long as I observed the sequence described above for charging and unplugging. The battery indicator on the CM11 ROM showed 85% when I booted back into the stock ROM. There it showed 84%. Probably the squirrely behavior you observed was tied to the bolluxed charging indicator/screensaver issue. It's just touchy and if you want to use it you need to learn its foibles for the best overall experience.
Click to expand...
Click to collapse
Good to know. If it's an issue I will try that. I have since discovered that a much easier solution to get things in sync is just to reboot the thing. Frankly that seems a lot easier than the whole thing you said about when to charge and lock/unlock so that's what I've been doing. I just hope it actually is charging when the OS is making the charging LED green and saying not charging despite it being less than 100%. Guess I can find that out with my USB power meter. Thanks for the response!