Database Users

LINUX BOOTS at OPAL! Thanks to linwizard project!

Hi there,
I got Linux to boot at OPAL via linwizard project. Here are steps needed to get it work.
1) download image from:
http://tinderbox.x86.dev.gentoo.org/embedded/linwizard/gizard-20080602.tar.bz2
2) copy content of file to the microSD card
3) edit default txt and replace init=/linuxrc with init=/bin/sh
4) run haret and let it boot.
After a while you'll get to shell. No graphics.
Now you can attach microusb cable and connect it with your linux laptop (I recommend ubuntu)
and you will get usb0 interfece to start up.
Which IP to use to connect with OPAL I still must investigate.

Well ip connectivity now works:
ip=<client-ip>:<server-ip>:<gw-ip>:<netmask>:<hostname>:<device>:<autoconf>
Notas:/# ifconfig usb0 up 192.168.2.200 netmask 255.255.255.0
Listik:/usr/src/linux-2.6.27/Documentation# ping 192.168.2.202
PING 192.168.2.202 (192.168.2.202) 56(84) bytes of data.
64 bytes from 192.168.2.202: icmp_seq=1 ttl=64 time=2.95 ms
64 bytes from 192.168.2.202: icmp_seq=2 ttl=64 time=1.72 ms
And how to do it:
prolong "set CMDLINE" line with
ip=192.168.2.202:192.168.2.200:192.168.2.200pal:usb0
But in this image there doesn't seem to be any telnet/ssh server running. I will try cook image with ssh server support later

Download error
Were not able to re-upload

404 file not found error!!

http://tinderbox.x86.dev.gentoo.org/embedded/linwizard/
and open latest gizard-<date>.tar.bz2
or that I suppose.
The latest link should be http://tinderbox.x86.dev.gentoo.org/embedded/linwizard/gizard-20090703.tar.bz2

does this mean any chance of android working? anyone tried?

Hey,
I'm a new Opal user and I'm interested in getting *nix running on my device. I still haven't had the chance to mess around with this stuff but I'm excited to see this thread.
I was looking into the possibility of running Android on the Opal and it seems the closest thing is this thread bout running it on the Herald (it uses the same processor as the Opal).
I don't any experience in Linux porting so I thought I'd share this, in case anyone else is interested. And at the same time, I'll try to see if I can get something working based on what has been/is being done for other devices.
Sorry for the long post.

Hey Folks,
Any progress on getting Android on Opal? I am eagerly waiting to load one.
Kindly let me know, if this version of Linux when loaded, gives the UI.
Cheers'
Vijay
cijoml said:
Hi there
I got Linux to boot at OPAL via linwizard project. Here are steps needed to get it work.
1) download image from:
http://tinderbox.x86.dev.gentoo.org/embedded/linwizard/gizard-20080602.tar.bz2
2) copy content of file to the microSD card
3) edit default txt and replace init=/linuxrc with init=/bin/sh
4) run haret and let it boot.
After a while you'll get to shell. No graphics.
Now you can attach microusb cable and connect it with your linux laptop (I recommend ubuntu)
and you will get usb0 interfece to start up.
Which IP to use to connect with OPAL I still must investigate.
Click to expand...
Click to collapse

Android can boot on Opal
I have some good news, Android can boot on the Opal. This is just a proof of concept as it's missing tons of drivers and is completely useless.
Touchscreen and all keys except for the volume control (and obviously the reset button) are not working. So you basically can't do anything when you run it.
What I tried is the same as what's written in this thread about running Android on Gene. They're using the build made for the Herald/Wing (just as I was proposing in my last post) with customized initramfs and kernel.
You'll find all the necessary details in that thread. However, there's a newer build than the one mentioned there it's wing-linux-0.4pre2.cab. And the suitable kernel for that build is supposed to be the pre2 posted in this post but it didn't work on my Opal so I tried the older Gene kernel and it worked. The main difference between the two is bluetooth support, and that's obviously is of no use for us.
This doesn't effect the Windows rom, nor does it requires any special partitioning. Still it's best to have everything backed up before launching it, just in case.
This is the official site for the wing/herald build:
http://wing-linux.sf.net/
This thread on their forums about the Gene port will probably be of use to us:
http://sourceforge.net/apps/phpbb/wing-linux/viewtopic.php?f=4&t=4
I'm reading about the next steps but as I said before, I don't have any previous experience or knowledge about this type of things. If someone can give me hand, I would be more than grateful. At any rate, once I have better understanding of the concept I'll contact the people behind the Wing and the Gene ports.
P.S: If you do try to run this, keep in mind that this will take lots of time, specially for the first launch. And when you get an error saying something like "android sh: can't access tty" just ignore it and keep waiting. After a while you'll have a flashing "android" on the screen, and after some more waiting you'll reach the main screen.

Is this just THE BEGINNING
Sooper Stuff..!! So is this just THE BEGINNING??
How do we port the drivers and other required information in the build?
Cheers'
Vijay
www.msigeek.com

A Lil' help
I'm going through the Gene port thread here and on the Wing-linux sourceforge forums but I'm still a bit overwhelmed.
I would appreciate any help as I'm completely new to porting. I have some programming and linux knowledge but never attempted this type of things.
Click to expand...
Click to collapse
So am I.
Hmmm...
Right. Lets do it the way I did it.
1. Get the touchscreen working. Through HaRET, you must have got the GPIO interrupt whenever you pressed the touchscreen. You must have got two numbers corresponding to each press - a smaller number and a bigger number. The smaller number is the GPIO, and the larger number is, well, lets say a special GPIO value for the same pin.
Now checkout the Gene branch through git.
Goto /wing-linux/kernel/arch/arm/mach-omap1/board-htcherald.c
Scroll down to a block of code where you'll see the touchscreen code. Enter the smaller number in the .dav_gpio statement, and the IRQ number in the OMAP_GPIO_IRQ() statement below.
2. Follow the Kernel build instructions on the development section of the wing-linux wiki (the two make commands)
Copy the zImage into the linux folder on your SD card
Boot into wing-linux. The touchscreen should start working.
3. Now, hopefully, after the touchscreen's working, You would essentially just require two more buttons - the home button and the back button for minimum functionality. Everything else can be worked on by the touchscreen.
Then follow the instructions on the wing-linux forum (Page 2) to get the KEY(row,col) values of the keys on your handset. Hopefully you should get atleast a couple. Note down the corresponding keys and their KEY(r,c) values output.
4. Fire up board-htcherald.c again and goto the place where you have the KEY(r,c,KEY_blah) thing and replace the codes as per your obtained KEY(r,c,KEY_blah) values (The Home button is the one commented as Left Button)
5. That's all I can help you with as of now. I'm also figuring out a stable way of getting the DPad and the center select key to work, but It'll take some time.

Thanks kshaurya!
(This guy right here is the one who fixed the kernel for Gene, I asked him for some pointers).
I don't want to take my device apart just yet (I usually do my best not take to dismantle anything that I haven't owned for at least 3 months unless absolutely necessary) and I couldn't find a place that states what touchscreen it uses. I'm just hoping that it's the same a tsc2046 as well. [Is there anyone without a warranty and/or willing to check for us?]
I'm gonna double check the values I got from the touchscreen as for some reason I seem to have to IRQ values, probably forgot to get rid of some spamming irq. And, at the same time, I'm currently setting up a VM as a building environment, my main boot is Intrepid 64 and there's no 'psyco' package for 64 machines.
If anyone else have some experience and wants to try this, refer to: http://www.handhelds.org/moin/moin.cgi/HaRET_20Documentation (using haret to get the GPIO and IRQ values needed).
And to:
http://sourceforge.net/apps/trac/wing-linux/wiki/Development (acquiring the source code from Wing Linux and how to build it).
And a quick question for anyone that tried booting Android on the Opal, what screen did you get when Android finally finished booting?

I don't want to take my device apart just yet
Click to expand...
Click to collapse
Huh? where did that come from? Wing Linux will not touch your WM.
I seem to have to IRQ values
Click to expand...
Click to collapse
Do you mean two? Well, that's exactly what you should get. Even if it's just one, enter that value in the code.
my main boot is Intrepid 64 and there's no 'psyco' package for 64 machines
Click to expand...
Click to collapse
Oh no. dont tell me that you are building the entire thing. all you need to do is build the KERNEL! Please! Don't go into building the whole thing from scratch. Use the make ARCH ARM commands given on that page.

kshaurya said:
Huh? where did that come from? Wing Linux will not touch your WM.
Click to expand...
Click to collapse
I mean to check the screen, in case it turned out to be different that what you have.
kshaurya said:
Do you mean two? Well, that's exactly what you should get. Even if it's just one, enter that value in the code.
Click to expand...
Click to collapse
Yeah, stupid typo.
I noticed now that one of them appears when I keep the screen 'touched' for a bit longer.
kshaurya said:
Oh no. dont tell me that you are building the entire thing. all you need to do is build the KERNEL! Please! Don't go into building the whole thing from scratch. Use the make ARCH ARM commands given on that page.
Click to expand...
Click to collapse
I'm not gonna build the complete thing. Seems like I got too exited and failed to notice that building the kernel only requires a cross-compile toolchain, te rest is for compiling the whole thing.
I'm not THIS stupid usually . Honestly!
Thanks again!

I'm not THIS stupid usually . Honestly!
Click to expand...
Click to collapse
Its pretty normal

Weird.
I've only changed the two touchscreen values and built the kenrel. It finished without any error but now it won't boot.
It gets stuck, even before the space allocation part, with this error: "sh: can't access tty; job control turned off". And then it displays a prompt.
I'll try modifying an older build, I'm pulling them from the repos at the moment.
After all, the pre2 kernel from Gene didn't boot on my device (although it got stuck later on).

Try doing a clean install - Remove the linux folder and try again.
Also, make sure that you're not forgetting to checkout the Gene branch.
Code:
git checkout Gene
Is your default.txt modified? And have you downloaded the modified initramfs.cpio?
check in the Gene forums for that.

Already tried the clean install, no dice. The default.txt is untouched and I'm using the modified intramfs. What happened this time is different from what happens using the original one, it's not asking me to specify the partition size but instead it's waiting for a command. I could probably ssh via usb but I have no clue how that might help.
And I've already checked out the Gene branch from the beginning.
I've tried compiling the kernel for pre1 (after changing the screen values) from SVN and it did boot (both using the cabs for pre1 and pre2) but no touch screen yet. All in all, I'm guessing that there's too much hardware difference here.
And the button for lowering volumes didn't work either, it seems like whatever you changed for getting it to work on Gene is the same as what we need here, but I'll think about that later.
I only have two ideas left:
- Trying to go back to a more stable build (with lesser features and lesser possibilities for errors). Maybe 0.3.
- Trying to create some kind of hybrid kernel using this alongside the HTC Vogue build as it probably has closer hardware to the Opal (obviously, I'm talking about everything beside the MSM7500 400MHz processor that it has). I'm hoping it won't get to this cause I'm definitely under qualified for that at the time being.

What happened this time is different from what happens using the original one, it's not asking me to specify the partition size but instead it's waiting for a command.
Click to expand...
Click to collapse
Could you post a screenshot?
I've tried compiling the kernel for pre1 (after changing the screen values)
Click to expand...
Click to collapse
I'm assuming you mean the touchscreen values? Try interchanging and see.
Trying to go back to a more stable build
Click to expand...
Click to collapse
I wouldn't recommend that. Defeats the whole purpose.
Why don't you try getting in touch with darkstar?

kshaurya said:
Could you post a screenshot?
Click to expand...
Click to collapse
A friend borrowed my digital camera, I tried my laptop's webcam but the text it too blurry. Couldn't fix it using gimp either. So here's exactly what's showing on the screen:
Code:
mdir: Cannot creat directory `/mnt' : File exists
modprbe: could not parse modules.dep
initramfs: Creating device nodes:
initramfs: Loading /initrd.d/10-initfs.sh module
initramfs: Loading /initrd.d/30-wingboot.sh module
Selected:
ROOT_DEVICE=/dev/
CMDLINE=debug quiet psplash=false loglevel=7 init=/sbin/init console=tty0 video=omapfb:accel fbcon=rotate:3 4 root=/dev/
initramfs: Loading /initrd.d/80-loopboot.sh module
initramfs: Loading /initrd.d/85-blockboot.sh module
booting from: /dev/
mount: Mounting /dev/ on /mnt failed: Invalid argument
Unable to mount rootfs device
sh: can't access tty; job control turned off
/ $
And after the prompt, on the same line, there's a flashing '_' waiting for input.
Using the original zImage (from the pre2 cab) it's right around here that the screen clears and the Wing Linux installation script kicks in.
kshaurya said:
I'm assuming you mean the touchscreen values? Try interchanging and see.
Click to expand...
Click to collapse
Will try that next.
kshaurya said:
I wouldn't recommend that. Defeats the whole purpose.
Click to expand...
Click to collapse
I meant it as just a temporary test to till the cause of the incompatibility is figured out. With less things that could go wrong, it'll be easier to locate the ones that are going wrong.
kshaurya said:
Why don't you try getting in touch with darkstar?
Click to expand...
Click to collapse
You're right. I should post a thread on the project's forums asking for his help.

[Android] AOSP 2.0.1 Proof-of-Concept Build. Assistance appreciated.

Tonight I managed to get my first Android build, 2.0.1, compiled myself from AOSP, up and running on the Vogue from NAND.
I made some small changes, most notably, updating the build.prop to adjust the DPI to 120 and adding the libhtcgeneric_ril.so library, as well as adding the necessary (or.. is it necessary?) build.prop entry to get the radio functioning.
I proudly present my first Android build.
NOTE: This is purely for testing/evaluation purposes.
Working:
Radio
Data
Screen resolution is accurate
Not Working:
Audio
Power Functionality (buttons do not wake the phone?)
GPS
Anyone up for pointing out what I need to do differently to get the non-working aspects functioning? Any tips on optimization? Clues to setup and take full advantage of build.prop?
Additionally, do we have a central repository of Vogue (or MSM7k) drivers that've been ported as source, ready to be compiled for different versions?
There's probably a lot missing here that I'm not even considering.. so please feel free to make any comments, give any advice, or point me towards any documentation.
All help is appreciated. Thanks!

I think this is the repo you're looking for:
http://androidhtc.git.sourceforge.net/git/gitweb-index.cgi
It contains Audio & GPS drivers, among other things. Can you wake the phone over adb shell with the command echo "wake" > /sys/android_power/request_state ? I'm also interested in getting an AOSP build running from source, I'd like to get the camera working for Eclair.
EDIT: Also, in the zenulator's eclair mod, the /system/etc/keychars directory contains these files:
Code:
htcvogue-ts.kcm.bin
qwerty2.kcm.bin
qwerty.kcm.bin
sapphire-keypad.kcm.bin
trout-keypad.kcm.bin
trout-keypad-qwertz.kcm.bin
trout-keypad-v2.kcm.bin
trout-keypad-v3.kcm.bin
tuttle2.kcm.bin
vogue-ts.kcm.bin
Perhaps that vogue binary is needed? That's my shot in the dark.

Those files are just for the keymapping, nothing more..
polyrhythmic said:
I think this is the repo you're looking for:
http://androidhtc.git.sourceforge.net/git/gitweb-index.cgi
It contains Audio & GPS drivers, among other things. Can you wake the phone over adb shell with the command echo "wake" > /sys/android_power/request_state ? I'm also interested in getting an AOSP build running from source, I'd like to get the camera working for Eclair.
EDIT: Also, in the zenulator's eclair mod, the /system/etc/keychars directory contains these files:
Code:
htcvogue-ts.kcm.bin
qwerty2.kcm.bin
qwerty.kcm.bin
sapphire-keypad.kcm.bin
trout-keypad.kcm.bin
trout-keypad-qwertz.kcm.bin
trout-keypad-v2.kcm.bin
trout-keypad-v3.kcm.bin
tuttle2.kcm.bin
vogue-ts.kcm.bin
Perhaps that vogue binary is needed? That's my shot in the dark.
Click to expand...
Click to collapse

What's responsible (or handles) power management, then?
And why are there so many keymapping files? According to AOSP, Android will default to qwerty.kl, and certainly with the Vogue being as simple as it is, a single qwerty.kl set up for the Vogue would be sufficient.
So what gives? Or are these files all leftover as this was "ported", and they existed to support previous devices, etc.?

first off great job. this is exactly how i started out by building my own builds from source and then taking apart others to see what fits together. if i have time this weeked i'll have a look at it.

There are an awful lot of moving parts in power management in Android (and any OS, really) - there's the kernel's power subsystem which controls deep sleep / suspend, and which Android attaches a "wakelock" system to, each radio lib (Bluetooth, WiFi, phone) has power management (which hooks up to kernel interfaces), there's the panel driver which controls brightness, etc.
I think the keymapping files are just there so that no matter which one the framework looks for, it always finds one, speeding things up - rather than having to try to find each one and failing down until it finds its eventual failsafe qwerty, it loads the Vogue one straight away.

Awesome man, way to go!
Can you throw in links for rootfs/zimage, I will try later today on my wife's phone.

Thanks sshark, I would, but I've been tweaking that image continuously and at it's current state, it's broken.
Here are the major hurdles I'm facing right now:
How do I determine which drivers are and are not necessary in a build? If we use an AOSP build, or someone else's port, obviously we don't want audio drivers from the Nexus One or generic Goldfish sensors from AOSP, so how can we know what we need to be able to keep images clean?
Along the same vein, how does one incorporate drivers accordingly, such as audio?
Is power management really a dark art right now? Plemen's AOSP build is fantastic, but I typically have to push the power button four times to get the OS to wake up, whereas a 2.1 build I just played with on the Vogue would power up right away on one click. What gives?
When compiling images using genext2fs, does 80000 vs 160000 matter, NAND vs HaRET booting? What's the maximum?
Lastly, I've recently tried unsquashing others images, making changes, and then trying to re-ext2 them, mount them, and squash them. However, when I do this, my images no longer boot fully on my Vogue--instead they'll get as far as the boot animation, it'll run for a bit, and then the boot animation will pause for a second or two, and restart. This happens endlessly. Is this a problem with my process, be it ext2, sqsh (sqsh version, perhaps?) anyone have an idea?

Shidell said:
Thanks sshark, I would, but I've been tweaking that image continuously and at it's current state, it's broken.
Here are the major hurdles I'm facing right now:
How do I determine which drivers are and are not necessary in a build? If we use an AOSP build, or someone else's port, obviously we don't want audio drivers from the Nexus One or generic Goldfish sensors from AOSP, so how can we know what we need to be able to keep images clean?
Along the same vein, how does one incorporate drivers accordingly, such as audio?
Is power management really a dark art right now? Plemen's AOSP build is fantastic, but I typically have to push the power button four times to get the OS to wake up, whereas a 2.1 build I just played with on the Vogue would power up right away on one click. What gives?
When compiling images using genext2fs, does 80000 vs 160000 matter, NAND vs HaRET booting? What's the maximum?
Lastly, I've recently tried unsquashing others images, making changes, and then trying to re-ext2 them, mount them, and squash them. However, when I do this, my images no longer boot fully on my Vogue--instead they'll get as far as the boot animation, it'll run for a bit, and then the boot animation will pause for a second or two, and restart. This happens endlessly. Is this a problem with my process, be it ext2, sqsh (sqsh version, perhaps?) anyone have an idea?
Click to expand...
Click to collapse
i cant answer all of those questions, with that said ill tackle the last two
4. when using genext2fs to compile builds it doesnt matter what the -b count is we just use
Code:
genext2fs -d ./system -b [B]180000[/B] -a system.ext2
to make sure we could fit a ~180 mb system so if your system folder is ~120mb(uncompressed), using -b 125000 should work.
5. make sure you arent using squashfs-tools 4.0 because it isnt supported in our kernel version. so use 3.3 or 3.1 .
5b. when you see the boot logo looping, that means the build has crashed and like i said to you before i strongly recommend you setup adb on you box so you can run logcat to see what the phone is actually doing and to debug what went wrong and why it is looping

Thanks Jamezelle. So NAND users need to make sure it's -b 90000 (or less), as NAND only supports 90 mb. max, correct?

Shidell said:
Thanks Jamezelle. So NAND users need to make sure it's -b 90000 (or less), as NAND only supports 90 mb. max, correct?
Click to expand...
Click to collapse
right i would keep it around 88 to be safe.

I'm trying to get ADB to work (using ubuntu 9.10) and I've followed the instructions here, including restarting udev, but even still when I try to start adb, I get "command not found" in terminal.
Any ideas on what I'm missing?
EDIT: I'm missing a ./. I'm really starting to wish I could do this natively in Windows.. geeze.

Shidell said:
I'm trying to get ADB to work (using ubuntu 9.10) and I've followed the instructions here, including restarting udev, but even still when I try to start adb, I get "command not found" in terminal.
Any ideas on what I'm missing?
EDIT: I'm missing a ./. I'm really starting to wish I could do this natively in Windows.. geeze.
Click to expand...
Click to collapse
did you make sure you added the path to adb in .bashrc
# On Linux, edit your ~/.bash_profile or ~/.bashrc file. Look for a line that sets the PATH environment variable and add the full path to the tools/ directory to it. If you don't see a line setting the path, you can add one:
Code:
export PATH=${PATH}:<your_sdk_dir>/tools
Click to expand...
Click to collapse
that should clear up the "Command not found" issue

jamezelle said:
did you make sure you added the path to adb in .bashrc
that should clear up the "Command not found" issue
Click to expand...
Click to collapse
Yep, that was the issue. It needs to be there, or launched as ./, I presume.
Thanks much for your help tonight, Jamezelle.. I'm happy to report that I'm steadily making progress for a working release.

Shidell said:
Yep, that was the issue. It needs to be there, or launched as ./, I presume.
Thanks much for your help tonight, Jamezelle.. I'm happy to report that I'm steadily making progress for a working release.
Click to expand...
Click to collapse
thats great to hear, also thanks for your additions to the libgps.so! its nice to still see some android enthusiasm in this community

[GUIDE] Getting the most out of your SGS [UPDATED: 28.02.2011]

I will try to set up a guide to contain all of the information to get the most out of your I9000 Galaxy S. First the fineprint:
I am not responsible for any damage that any of these instructions may inflict to your phone, computer or any other device that is used in the processes described herein. I am also not responsible if you lose your warranty by flashing your phone with unsupported firmware or if any of these instructions brick your phone, if it will rape your wife or if it will eat your liver with some fava beans and a nice chianti.
I didn't test any of the programs specified herein for viruses/trojans/etc. I run Windows in a VirtualBox that doesn't have access to the internet and doesn't contain any private data, so I don't care for viruses, if you care for your OS though, you should check the programs for viruses before running them.
Use common sense when following such instructions, some of the things may differ because of different program versions, different operating systems or different setups.
Some of these instructions are based on a stock firmware, if your firmware is modded in any way, some of the things described herein may be inappropriate for your device.
1. NOT bricking your phone.
--Why, when, where: Everyone's afraid of bricking their phone. I see the term "bricking" is being a bit overused in these forums though. Everyone is using it, even for the case where the phone can actually be "repaired" with a few simple hacks, IMHO the term "bricking" should only be used in the case where you get your phone in a state where it is inoperable AND you can not in any way repair it yourself.
--Prerequisites: A bit of common sense.
There are a few simple steps that you can follow, to get the risk of "bricking" (as in, you can not repair it yourself and need to somehow get Samsung to either repair it for you, or give you a new device) to a minimum:
1.1. Before trying any of the other steps, make sure that you can get to both the "Recovery mode" and the "Download mode" using the 3-button-combo. If this doesn't work for your device you can try following the steps described here: http://forum.xda-developers.com/showthread.php?t=810686
1.2. Try to avoid flashing stuff that contains a bootloader. The only way to permanently brick your phone so that you can not repair it yourself (at least AFAIK) is to flash a bootloader and then interrupt that flashing. If the bootloader didn't get flashed properly and it's broken, there isn't much you can do about it, and you need to somehow get Samsung to either repair it or give you a new one (if you're lucky). If the bootloader is fine, there is almost always a way to "repair" your phone yourself.
1.3. Do not interrupt the flashing processes. When using Odin or Heimdall to flash stuff to your phone, there is always the risk of bricking it if you interrupt the flashing process. If the bootloader is fine though and you can get into the "Download mode", you might be able to repair it.
If you follow these simple advices, it might save you money, nerves and also some time without your phone (the time that it takes Samsung to repair it, which can sometimes, depending on country, be even a couple of months).
2. Flashing stock firmwares.
--Why, when, where: You should usually do this if your phone doesn't work with your current firmware, if there is a new firmware out that might work better or if you just want to go to a stock firmware.
--Prerequisites: Odin, a stock firmware (from www.samfirmware.com for example).
NOTE: Apparently there are people that report that using Odin v1.3 might interrupt the flashing and leave you with a soft brick and that v1.7 doesn't have this problem. I have always used v1.3 and never had problems because of it, but if v1.3 isn't working for you, you might give v1.7 (or even heimdall) a try before giving up.
The steps to flashing a stock firmware are already described in a couple of other threads, like: http://forum.xda-developers.com/showthread.php?t=818556
Nonetheless, here a quick sum-up of what you have to do:
2.1. Open up Odin.
2.2. Put your phone in the "Download mode" with the 3-button-combo (Volume Down + Home + Power).
2.3. Connect your phone to your computer (DO NOT CONNECT THE PHONE BEFORE OPENING ODIN OR THIS WILL NOT WORK).
2.4. Odin should recognize your phone and one of the "com" boxes should light up yellow. If this isn't the case, try repeating the previous steps and eventually connect your phone to another USB port.
2.5. Select your firmware in Odin.
2.5.1. --OPTIONAL-- If you want your phone to be like new, you can select "Re-Partition" in Odin, which will make it repartition your Internal SD. In this case you also have to use a .pit file (WARNING -- you will lose all of your installed applications and settings).
2.6. Take a deep breath and click the "Start" button.
2.7. Wait for the firmware to be flashed and for the device to be restarted.
2.8. You now have a stock firmware. If you also selected "Re-Partition" in Odin, all your programs and settings will be gone and your device will be like new.
3. Rooting your phone and flashing a custom Kernel.
--Why, when, where: Rooting your phone will get you super-user permissions to Android (super-user is Linux's equivalent of "Administrator rights" in Windows). This will allow you to execute some programs that need root permissions, access partitions that you otherwise couldn't and do other cool stuff with it.
--Prerequisites: Stock firmware (as most --if not all-- of the custom ROMs or kernels have root permissions already), Odin or Heimdall.
There are many ways to get root permissions on your device, like with special apps (OCLF for example), with CWM (aka ClockWork Mod) or, my preferred method, flashing a kernel that has this built-in. For this example I will use the SpeedMod Kernel, which is my preferred one. If you have another kernel that you like and that has root built-in, you can use that one.
3.1. Download your preferred kernel (the version for Odin, not the one for CWM).
3.2. Open up Odin or Heimdall.
3.3. Put you phone into "Download mode" and connect it to your computer (DO NOT CONNECT THE PHONE BEFORE OPENING ODIN OR THIS WILL NOT WORK).
3.4.1. If you are using Heimdall, unpack your kernel until you end up with a file called zImage. Select that in Heimdall in the box for "Kernel (zImage)" and click Start.
3.4.2. If you are using Odin, select the file you downloaded in the PDA box and click Start.
3.5. After your Phone reboots, go into "Recovery mode" and go to "Advanced Speedmod ULK features" -> "ROOT / Install Superuser".
3.6. After rebooting the phone again, you should have root permissions.
4. Deodexing your apps and framework.
--Why, when, where: The system applications and the framework files on the Android OS are normally 'odex'ed. By deodexing, you will get rid of the .odex files that come with every apk and jar file and you will be able to edit the apks like any other apk. It will also save you a wee bit of space, and make your apps launch a wee bit faster.
--Prerequisites: Stock firmware (as most --if not all-- of the custom ROMs are deodexed already), xUltimate (this is what I found to be the easiest, if you know any software that is better, please let me know), root permissions.
You can download xUltimate from here: http://www.droidforums.net/forum/xeudoxus/47283-release-xultimate.html
There are more ways to deodex your apps, but I found xUltimate to be the easiest.
4.1. First of all, you need to get the files from "/system/app" into the subdirectory "origi_app" and all of the files from "/system/framework" into the subdirectory "origi_frame". Both "origi_app" and "origi_frame" should be in the folder you extracted xUltimate to. If they don't exist, create them yourself. There are actually two ways to get the files there, either with xUltimate itself (options 1 and 2) or by copying them to your SD with "Root Explorer" for example and then copying them from your SD to your computer (or with adb of course).
4.2. Deodex the apps and framework with xUltimate, options 3 and 4.
4.3. After deodexing is finished, the deodexed files will be located in the directories "done_app" and "done_frame" in your xUltimate folder. You have to get these files back to their original directories, in /system/app and /system/framework. Again, there are a couple of ways to do this, either with adb (MOST RECOMMENDED ONE), or with "Root Explorer". For the adb method, you should open a command prompt and execute following code:
Code:
adb shell
su
stop
mount -o rw,remount /dev/block/mmcblk1p21 /system
rm /system/app/*.odex
rm /system/framework/*.odex
cp /sdcard/done_app/* /system/app/
cp /sdcard/done_frame/* /system/framework/
mount -o ro,remount /dev/block/mmcblk1p21 /system
reboot
5. Optimizing and zipaligning your apps.
I wasn't yet successful at optimizing or zipaligning. Optimizing (aka Compressing) the apps gave me a lot of FCs, optimizing the framework files gave me bootloops. If anyone has any advice on this, I'd be very thankful.
Also, see post #2
6. Protecting your screen.
--Why, when, where: This is not about protecting your screen from scratches, but rather about protecting it from degradation over time. As you might already know, AMOLED screens are prone to the "burn-in" effect. To elaborate a little: AMOLED uses Organic LEDs to display the amazing graphics you see on your display. These OLEDs are very good at displaying bright, colorful pictures, they have a downside though -- they fade over time. That means, the more a specific OLED is used, the less light it emits. If the whole screen would degrade at the same pace, that wouldn't be such a BIG problem, but the very nature of the OLED screens makes them degrade unevenly. That means the OLEDs that are used more frequently (like clock, phone signal, wifi, notification bar), get dimmer faster and this leads to ugly "shadows" on fullscreen apps. To be able to keep your screen as beautiful as new, I got a couple of tips, so that the display degrades more evenly and you avoid the ugly "shadows".
!! Most users won't even notice these degradations, also they won't be noticeable in 90% of use-cases and they will only appear after longer use (6 months+), but you can still use these tricks if you want your display to be almost as good as new a couple of years from now !!
6.1. Don't set brightness to 100%. At least not all the time. You should best be using a brightness setting that fits your ambient light, or the "Automatic brightness" setting. This will ensure that the OLEDs don't wear out as fast (the brighter you use them, the faster they will degrade).
6.2. Use a grey notification bar. The notification bar is the biggest "static" element on the screen. Most apps that are not fullscreen, will also show the notification bar, and this leads to an uneven degradation in that area if it isn't a neutral color. If you use a white notification bar, the OLEDs there will get dimmer faster and you will get an ugly shadow when using fullscreen apps, if you use a black notification bar, it will not degrade as fast as the rest of the screen and that area will be "brighter" in fullscreen apps, that's why I recommend a medium grey.
6.3. Use as little static elements as possible. If you don't need the clock in the notification bar, get rid of it. Get a theme that uses grey or green icons (see next step why) and try not to leave the phone on over night displaying the same static image.
6.4. Avoid blue. As you can see here for example: http://img24.imageshack.us/img24/8057/new1ls.png the blue OLEDs are degrading at a much faster pace than the green or red ones, this is why you should avoid using blue wallpapers or blue themes, they will make your display degrade faster than if you use a green theme and a green wallpaper for example.
These tips won't make your screen live forever, it will degrade too, but by using these tips, at least you can assure that you will have the most of your awesome display even in a year or two from now.
7. Theme-ing your phone.
Coming soon...
8. Unlocking your phone.
--Why, when, where: If you bought your phone with a contract, chances are that it might be locked in that specific network. If you want to also use other SIM cards in it, that are from another provider, you will have to unlock the phone (!! WARNING !! in most cases this will lead to a void warranty, please consult your contract).
--Prerequisites: Root privileges, adb.
8.1. Get the /efs/nv_data.bin file from your device to your computer. You can do this either with adb or by copying the file to your SD card with "Root Explorer" and then copying it over to your machine from the SD (Be sure to keep a backup of this file and the /efs/.nv_data.bin.md5 file.)
8.2. Open up the file in a hex editor, go to the address 0x181468, where you will see something like this:
FF 01 00 00 00 00 46 46 46...
We are interested in that first '01', that means the phone is locked. Just change it to '00' and save the file. Copy it back to your SD card and then with "Root Explorer" back to it's original location (or 'push' it directly with adb). Then remove the .nv_data.bin.md5 file and restart the device (Again, be sure to make copies of these files before modifying or deleting them!). After this, you should be able to insert any SIM card into your device and it should work without the need for any further hacks.
9. Setting up 'adb' on your machine.
--Why, when, where: adb (aka "Android Debug Bridge") is a tool that will let you execute remote commands on your android device. It is useful for debugging, accessing and copying files from/to your device and much more.
--Prerequisites: The android SDK, which you can download from here: http://developer.android.com/sdk/index.html and the USB drivers for your phone, which you can get by either installing Kies or by downloading and installing these drivers: http://www.mediafire.com/?a6ni32dk6nn953b (password is 'ragin' -- I didn't test them, so feedback on these is welcome).
9.1. Unpack the downloaded android-sdk.
9.2. Go to the unpacked directory and launch the SDK Manager.
9.3. Go to "Available packages" -> "Third party Add-ons" -> "Google Inc. add-ons" and tick the box next to "Google Usb Driver package" and the click on the "Install Selected" button. This will download and install the Google USB Drivers.
9.4. Whenever you want to connect to your phone through adb, make sure that you have enabled "USB Debugging" under "Settings" -> "Applications" -> "Development".
9.5. You should now be able to open up a command line ("Start" -> "Run..." -> Type "cmd" and click "OK"), cd to the subfolder "platform-tools" under the folder where you unpacked android-sdk and run "adb" in there.
Take some time to get used with the commands that adb offers, as these will help you to debug problems when you encounter some.
10. Lagfixing
--Why, when, where: It is said that the default filesystem that is being used for the partitions on the SGS (RFS) is having slow read times and thus the programs launch a bit slow, sometimes perceived as "lag". This can be fixed by converting the filesystem on the most used partitions to a more modern filesystem, like the ext filesystem, which not only has a bunch of improvements over such old filesystems like RFS, but also seems to be a bit faster.
--Prerequisites: A kernel that supports lagfix.
10.1. Since every kernel has it's own way of converting your FS, you should best look into the documentation of your kernel on how you can apply a lagfix. Some even apply it automatically for you (as in, "lagfix on" is their default setting).
11. Do NOT overcharge
--Why, when, where: Almost all new batteries have an overcharging protection. This means that the protection that is built into the battery will not let it charge to 100%. This is a feature, not a bug! This will help prolong your battery life while also keeping it safe from overheating/explosion/etc. Do not try to trick it and unplug and plug again until you see 100%, just get used to the fact that you can't have 100% battery anymore and live with it, or you risk destroying your battery.
12. Call recording
--Why, when, where: Most Galaxy S firmwares don't have the ability to record both streams of a call. This is not a bug, it was designed like this because in most countries it is illegal to record someone without their permission. Yes, there are apps that will let you record a call, but without software support, it will record the other end from the microphone, which will result in low quality, but there is a workaround.
This might be illegal in your country! I'm not responsible if you get sued for recording someone without their permission.
--Prerequisites: Root permissions, adb/root explorer, a 2.2.1 firmware.
12.1 Download the attached "CallRecord.zip" and unpack it.
12.2 After unpacking you should have 3 .so files. You need to get these files into your /system/lib folder with either adb or by copying them to the phone and then using "Root Explorer" to copy them to the proper folder.
12.3 Reboot.
12.4 After the phone has rebooted, you can use most apps that are on the market to record calls properly (that means not from the microphone). I use AllCallRecorder because it is simple and does the job. There are also Phone.apk's that have call recording built in, you could also install one of those and record your calls with it.
That is all for now. I will add more information as time goes by and I hope this will become a full guide on how to make the best out of our devices. If you have constructive criticism, questions or any ideas or tips on how to improve this, please let me know. If you don't have anything constructive to add to this thread, please DO NOT post. If my troll alarm goes off, I WILL ignore you.
Thanks goes to:
ragin for the USB drivers.
I have learned most of the stuff I put here from various searches on Google and the xda forums and I may not remember the exact threads I got them from. If you feel I have copied your work without giving you credit, I am very sorry for that. Please let me know via a post or a PM and I will link you in the "Thanks".
I am sorry if my English is bad, it's my third language though. I hope that the post is understandable by most people.

This post will contain instructions for *nix based operating systems
Because I am using Linux myself and because it is much easier to do stuff in the command line on Linux than it is on Windows, I will mostly post instructions for *nix systems. If anyone wants to help out by "translating" them over for Windows machines, I can include it in the next post.
Optimizing and zipaligning
I have managed to Optimize and zipalign the apps in /system/apps with the following code.
You need to run this on a *nix distribution (I used Ubuntu) with at least the following packages installed: bash, zip, unzip, optipng. Put all the .apk files from /system/app in a folder on your machine, cd to that folder and execute this code snippet.
Also, beware that some of the apps might not work (I had for example FCs with the camera and the phone app), I'll try to figure this out and make it pretty much foolproof. Currently everything but the .9.png files are optimized (the .9.png files are some special files that can't be treated like normal png files).
Code:
for apk_file in *.apk; do
file_name=`echo $apk_file | sed -r s/.apk//`
echo -ne "Unpacking\t$file_name.apk... "
mkdir $file_name
unzip -qq $file_name.apk -d $file_name
cd $file_name
echo -ne "Done.\n"
echo -ne "Optimizing\t$file_name.apk... "
for pngfile in $(find . -name '*.png' | fgrep -v .9.png); do
optipng -quiet -o 5 $pngfile
done
echo -ne "Done.\n"
echo -ne "Repacking\t$file_name.apk... "
zip -q -0 -r ../$file_name.apk *
cd ..
rm -rf $file_name
echo -ne "Done.\n"
echo -ne "Zipaligning\t$file_name.apk... "
zipalign -fv 4 $apk_file $apk_file.za
mv $apk_file.za $apk_file
echo -ne "Done.\n"
done
EDIT: I added the -0 flag to the zip command, since you should never "compress" apk files, because this leads to the FCs I was experiencing.

Post also reserved.

Last reserved post. You can start flaming now.

shantzu said:
Last reserved post. You can start flaming now.
Click to expand...
Click to collapse
Posted in the wrong place... try reading the faq's about where this belongs.

davidf said:
Posted in the wrong place... try reading the faq's about where this belongs.
Click to expand...
Click to collapse
Well, the rules of the development section state: "Rom Development - only meant for very advanced technical discussion directly related to ROM development activity and the delivery of actual ROMs and ROM components ONLY."
I'd regard this as an "advanced tehnical discussion", since it also contains information on how to deodex and (to come soon) optimize/zipalign your apps, that's why I thought it would belong here. I would also like this to be a place for advanced discussions on best practices on deodexing, theme-ing, and otherwise modifing a stock ROM manually. If the moderators still think that this doesn't belong here, I'm sorry, and would like to ask them to move it to the proper Forum.

Sticky Material.
Don't you think your Title is misnamed? The thread contains much more than just a guide getting most out of our SGS.
Very good effort anyway.

ragin said:
Sticky Material.
Don't you think your Title is misnamed? The thread contains much more than just a guide getting most out of our SGS.
Very good effort anyway.
Click to expand...
Click to collapse
Well, I didn't know what else to name it, and didn't want to use a really long name. I think this title best describes what it's about...
Thank you for your reply!

very good post. It'll be extremely helpful for new users i reckon.

question
can this method be used on almost any samsung galaxy? (i have galaxy 551)
and about deodexing...is xUltimate a general app for any Android phone or only for SGS ?

Awesome stuff thanks for this cleared up a few things

waveboy2u said:
can this method be used on almost any samsung galaxy? (i have galaxy 551)
and about deodexing...is xUltimate a general app for any Android phone or only for SGS ?
Click to expand...
Click to collapse
Well, the program seems to be posted in the "Motorolla Droid" forum, so I don't think it was even intended for the Galaxy S. If I were to guess, I'd say it might work on any Android device. Just be sure to make a backup in case anything goes wrong.

Thanks alot! Never knew the degrades display.
Sent from my GT-I9000 using XDA App

Shantzu, first, thank you very much for this valuable contribution!
While I agree that it is related to "highly technical discussion", it's not directly connected to ROM cooking/development. In fact, this is the kind of thing that people should read before they start mucking about in the dev section
I've gone ahead and moved it to the general section and made it a sticky topic for now. However, those are starting to pile up in this section, so we'll likely roll up several useful threads like this one into one unified reference sticky here soon.

sirphunkee said:
Shantzu, first, thank you very much for this valuable contribution!
While I agree that it is related to "highly technical discussion", it's not directly connected to ROM cooking/development. In fact, this is the kind of thing that people should read before they start mucking about in the dev section
I've gone ahead and moved it to the general section and made it a sticky topic for now. However, those are starting to pile up in this section, so we'll likely roll up several useful threads like this one into one unified reference sticky here soon.
Click to expand...
Click to collapse
I was thinking about this guide as some kind of "cook your own ROM directly on the device", that's why I was also including tips on how to deodex the apps and I'd also like to include tips on how to set up themes (not install third party themes, but rather explain where each icon can be found and how it can be modified) and other mods. Anyway, if you think it better fits in the General section, I'm fine with that, as you can see I'm pretty new in these forums and not that experienced (for example I have also seen a guide on how to manually unlock the phone that was stickied on the Developers section).
Anyway, sorry again for the trouble and thanks for clearing it up!

Very good post. Thank you!!

Very good work. One thing i noticed though: you use ext fs for the system rw remount. This i think will only work for ext converted system partitions not the original rfs system.
Sent from my GT-I9000 using Tapatalk

liraindon said:
Very good work. One thing i noticed though: you use ext fs for the system rw remount. This i think will only work for ext converted system partitions not the original rfs system.
Sent from my GT-I9000 using Tapatalk
Click to expand...
Click to collapse
I know, it normally shouldn't work, but it actually does. I don't have any lagfix applied and it works just fine. I will try and see though if I can come up with a more general command that 100% works in all cases.
EDIT: ok, not specifying any filesystem at all works too. I will have to see if this also works with a lagfix enabled, but I guess there shouldn't be any problems.
Thanks for your comment!

whoa didnt know about degradation... thanks!

nice
very good write up.. +1

[TUTORIAL] XFCE4 on Webtop -Straight, Simple Guide for Noobs like Me

Hey Everyone, Good News- I finally figured out how to get XFCE on webtop, and take off Awn Dock. (Er, disable it.) I realize that its been done before and that there is a guide, but the guide I found ( http://forum.xda-developers.com/showthread.php?t=1054213 ) seems to be kind of outdated, and a little unclear. So this is an attempt to help people take their webtop to a whole new level.
To be clear, this is all the work of others, I take no credit, I urge you to hit the thanks button on all the threads I link to. These guys work their butts off. This is simply a guide making it dead simple to do something I know a lot of people want, but isnt exactly super clear. Lets begin.
Remember, guys, it helps if your Rom actually has Webtop. No CM7, no MIUI, No AOSP. Some of the Blur Roms also don't have webtop, but that can be solved by flashing it through these links:
For 2.3.4 Roms http://www.multiupload.com/H4UW3JTL22
For 2.3.5 Roms http://www.multiupload.com/R39VKRPJU5
For 2.3.6 Roms http://www.multiupload.com/3PD53CQRZA
(These are all Fruit Cakes, found here. Go give Sam some love, hit the Thanks button.)
Step 0
Do a Nandroid Backup. Please.
STEP 1
Ok, so first off, youre going to need to run webtop2sd, which can be found here. Run that, follow instructions, and try not to destroy your SD card. (Not that I did. Not that I destroyed 3 of them. No way.) That should take a bit, so be patient. Remember to say thanks to Sogarth, the Webtop Champion.
STEP 2
After that's over and done with, go ahead and start up Webtop, either through a Lapdock or Webtop Hack, it doesn't really matter. I will say that this is kinda pointless to do if you don't have a lapdock, but whatever!
After webtop is started, start the Webtop Configorator (Has the same icon as the Webtop2sd apk). Its going to pop up with some questions, click yes on both of them. Don't panic when it seems like the program freezes, its not frozen, it just takes an unsettlingly long time. Thatll finish up, then will present you with a menu, offering to install LXTerminal, and Synaptic Package Manager. Install both of them, by clicking install. When they finish, close the configorator. Now, this part is weird, open the configorator back up, and make sure that both programs are really installed, by clicking install again, just for good measure. For some reason, Synaptic would say it installed, then not really be installed. So yeah, up to you.
STEP 3
Alright, almost done, but then, not really. As of now, you have all the tools to get XFCE (Or whatever environment you choose, I recommend XFCE4). But right now, dependencies and packages are really really effed up, and its borderline impossible to install anything fun.
So to fix this, go to this thread here. This is a guide to for fixing apt-get dependencies. Show some love to Arvati, hit the thanks button, the guide is really simple, easy to do, and the installer is fully automatic. I recommend following his guide, then coming back here for the rest.
Helpful hint, to save you some thread searching, in the installer, type Yes on all the questions.
STEP 4
Home Stretch! At this point, you're ready to run Synaptic. In LXTerminal, type
Code:
gksu synaptic
We're going to install a couple things here. Well, actually a lot of things, but we're only going to click two things, and the rest will fetch themselves. In the search bar, type in xfce4 (or whatever desktop environment you like). It should be the top of the list, named "xfce4". Click the white box, and hit Mark for Installation. Click Yeah, you want to install the other stuff that comes with it.
After that, search for gedit. (For non linux familiar people, gedit is the linux equivalent of notepad. Its also got some color coding, so you could compare it to Notepad++.) Mark that for installation too, and you're set. Click apply at the top, and wait for that to install.
STEP 5
This final portion follows this guide. Go show your thanks to YellowGTO.
Once that finishes, go back into LXTerminal. Type in
Code:
cd /osh/usr/local/bin/
And after that, type
Code:
sudo gedit start-oshwt-2.sh
Gedit is going to open. Scroll down to where it has some lines that say
Code:
sfalv -i "awm-autostart"
sfalv -i "webtop-wallpaper"
These have to do with the current Window manager. We're not deleting them or removing them, just making them not start when Webtop does.
Put hashes (#) in front of them, so they now look like
Code:
#sfalv -i "awm-autostart"
#sfalv -i "webtop-wallpaper"
After that, add a line at the bottom of the chunk that says
Code:
sfalv -i "startxfce4"
Save and exit.
STEP 6
Go back into LXTerminal and type in
Code:
Startx
. This SHOULD finish it up by restarting webtop, but if it doesnt, pull the phone out and reboot it.
And you're done. This has essentially turned your phone and lapdock into an extremely handy netbook. You can install programs through Synaptic or apt-get. From here, you can play around. I recommend doing another Nandroid backup so that you don't accidentally restore to the one without your fancy new webtop.

Thanks a lot man.
Is it the same for lxde? I would like to try both on webtop.
Sent from my MB860 using Tapatalk

Jack'O said:
Thanks a lot man.
Is it the same for lxde? I would like to try both on webtop.
Sent from my MB860 using Tapatalk
Click to expand...
Click to collapse
Yes, im theory it should work, just type startlxde instead of startxfce. Post results on performance and usability, id like to know if theres anything that works better than xfce for this.

are your tzdata or samba-common packages broken by any chance?
I had both broken doing the standard wedtop2sd install method (stock ROM), was able to work around tzdata but not samba-common

teeth_03 said:
are your tzdata or samba-common packages broken by any chance?
I had both broken doing the standard wedtop2sd install method (stock ROM), was able to work around tzdata but not samba-common
Click to expand...
Click to collapse
Ahh I have no idea, it should've been fixed in the dependency fix script. When do you encounter this error?

http://forum.xda-developers.com/showthread.php?t=1397583

tzdata would give an error when trying to install most packages from synaptic (openoffice.org is one I'm pretty sure), and samba-common throws an error when trying to install it, if you are trying to install a package to access file shares for example. But you can just try to install samba-common itself and it still doesn't install correctly.

Gnome also works!
After many hours of trial and error while following many of the tutorials, I managed to make gnome work to my liking on my webtop. I can even change themes as you can see on the screen captures.
I followed this tutorial made by aaron.a
I renamed the default gtk-2.0 Webtop theme to gtk-2.0-bak which is located on /osh/usr/share/themes/webtop-theme
I then edited the start-oshwt-1.sh file as follows:
# start OSHWT 1 scripts
update-font.sh
sfalv -w "webdaemon -d -n"
gnome-settings-daemon
# sfalv -i "xscreensaver"
sfalv -i "aiw -d"
sfalv -i "docking_manager"
fcitx
I edited the start-oshwt-2.sh file as follows:
# start OSHWT 2 scripts
# sfalv -i "awn-autostart"
# sfalv -i "webtop-panel"
# sfalv -i "webtop-wallpaper"
sfalv -i "gnome-panel"
sfalv -i "evbridge"
sfalv -i "window_switcher"
sr-test avahi_start &

What's the difference between
sfalv -i "startxfce4"
and
sfalv -i "xfce4-session"
I've been using the latter, but the former makes more sense to me. Though I've not been into doing this for very long.

cpuchip said:
What's the difference between
sfalv -i "startxfce4"
and
sfalv -i "xfce4-session"
I've been using the latter, but the former makes more sense to me. Though I've not been into doing this for very long.
Click to expand...
Click to collapse
I have no idea, thats probably something with XFCE itself.

ripin150 said:
I have no idea, thats probably something with XFCE itself.
Click to expand...
Click to collapse
You're right! wrong thread for this kind of question, I just noticed differences. I'll let you know if I discover the difference.

STEP 6
Go back into LXTerminal and type in
Code:
Startx
. This SHOULD finish it up by restarting webtop, but if it doesnt, pull the phone out and reboot it.
Click to expand...
Click to collapse
This step didn't work until I typed in "startx" vs your line of "Startx".

Is it normal for webtop to be finicky? I experience sometimes that webtop loses the top panel or doesn't wake up properly or just become unstable. Does anyone else experience? I mean, it usually works but sometimes, like one in ten times, webtop is wonky and I have to restart my phone.

jamesc760 said:
Is it normal for webtop to be finicky? I experience sometimes that webtop loses the top panel or doesn't wake up properly or just become unstable. Does anyone else experience? I mean, it usually works but sometimes, like one in ten times, webtop is wonky and I have to restart my phone.
Click to expand...
Click to collapse
Yes, I it's normal.... Just like your desktop pc or laptop, sometimes we need to start fresh with a reboot.

wingmanjd said:
This step didn't work until I typed in "startx" vs your line of "Startx".
Click to expand...
Click to collapse
Hey thanks for saying, I wasnt aware it was case sensitive. I guess thats why it was being finicky for me. Webtop as a whole is pretty awkward, Ive just been plugging jokersax's ICS into the lapdock and that works fine. But whatever works, you know?

ripin150 said:
Hey thanks for saying, I wasnt aware it was case sensitive. I guess thats why it was being finicky for me. Webtop as a whole is pretty awkward, Ive just been plugging jokersax's ICS into the lapdock and that works fine. But whatever works, you know?
Click to expand...
Click to collapse
How do you like jokersax's build with the lapdock? I've been holding out on it since I've bought the MM dock and the Lapdock.

Help.... I'm running DarkSide and the 2.3.6 Webtop. I can't run Webtop2sd 2.0.1 - thea pp throws a "process net.toreishi.webtop2sd has stopped unexpectedly" when I try to open it. Any ideas? I haven't been able to find anything!

fjhuerta said:
Help.... I'm running DarkSide and the 2.3.6 Webtop. I can't run Webtop2sd 2.0.1 - thea pp throws a "process net.toreishi.webtop2sd has stopped unexpectedly" when I try to open it. Any ideas? I haven't been able to find anything!
Click to expand...
Click to collapse
Ive gotten that problem, but I dont remember how I fixed it...
I guess just try clearing your cache and dalvik, maybe fix permissions. I may have gone so far as to flash a fruitcake with webtop, but Im not certain. Id read all up on the webtop2sd thread.

fjhuerta said:
Help.... I'm running DarkSide and the 2.3.6 Webtop. I can't run Webtop2sd 2.0.1 - thea pp throws a "process net.toreishi.webtop2sd has stopped unexpectedly" when I try to open it. Any ideas? I haven't been able to find anything!
Click to expand...
Click to collapse
Install busybox by JRummy16 from 'Market' Google Play, install busybox, leave default settings and try again
It seemed to work for me, I'm running NottachTrix 1.29b

princeandy63 said:
Install busybox by JRummy16 from 'Market' Google Play, install busybox, leave default settings and try again
It seemed to work for me, I'm running NottachTrix 1.29b
Click to expand...
Click to collapse
Thanks, you rock. Problem solved!

How to access my Nook Glowlight 3 without registration?

Hello everyone,
Could you show me how to access my Nook Glowlight 3 without registration ?
Current firmware: 50.0.117
Thank you!

Well, I usually bypass the registration by popping the thing open, hooking up a 3.3V UART interface and getting a root console.
I've never really looked into if there were secret hand signals to bypass the registration.
So I looked at the disassembled code to see what was there.
All the OOBE (Out-of-box-experience) stuff is in /system/priv-app/bnereader.apk
The welcome screen is com.nook.app.oobe.o.WelcomeIntroActivity
This calls com.nook.viewutils.KeyHeldHelper to see if a particular button is held down
and also com.nook.viewutils.MultiClickListener to see if you tap three times.
I held the button and tapped three times and I got com.nook.app.util.DiagnosticActivity (as in the screen grab).
(You can also get here if you had a shell with)
Code:
# am start -n bn.ereader/com.nook.app.util.DiagnosticActivity
The problem? The key you have to hold down while tapping is the volume up key.
What? You don't have a volume up key?
The way I held down the volume key was with a USB keyboard, but that can only be done when you're rooted.
You could also pipe raw events to the input system if you were rooted.
I'm certainly interested in someone contradicting me, but this seems like a dead end.

Ok, I'm going to contradict myself.
As I said, the Welcome Intro screen needs the volume up key and a triple tap.
There is also the com.nook.app.oobe.RegisterUserLogin screen
This can be bypassed by holding the Lower Left and the Upper Right and giving a triple tap.
Obviously, this would only work on the Glow3 which has buttons.
Unfortunately, the Glow2 has the exact same code.
I can't seem to get this one to work on an (already rooted) Glow3.
If you have a Glow3 try the LL/UR/triple tap.
Yes, this should work on the Glow3 if you are at a page with email/password/etc.
I can't get there because I'm intercepted by the WiFi page.

It's not working
Hello
I have Nook Glowlight 3, I tried the LL/UR/triple tap many times on login screen. but it don't work
Thank you!
Renate NST said:
Ok, I'm going to contradict myself.
As I said, the Welcome Intro screen needs the volume up key and a triple tap.
There is also the com.nook.app.oobe.RegisterUserLogin screen
This can be bypassed by holding the Lower Left and the Upper Right and giving a triple tap.
Obviously, this would only work on the Glow3 which has buttons.
Unfortunately, the Glow2 has the exact same code.
I can't seem to get this one to work on an (already rooted) Glow3.
If you have a Glow3 try the LL/UR/triple tap.
Yes, this should work on the Glow3 if you are at a page with email/password/etc.
I can't get there because I'm intercepted by the WiFi page.
Click to expand...
Click to collapse

dnt83 said:
I tried the LL/UR/triple tap many times on login screen. but it don't work
Click to expand...
Click to collapse
You know, there are more secret touches and broken code all over.
I found another one, but I can't seem to get this to work either.
It's on this screen. There are four touch spots.
The bottom two when pressed and held should show a version number at the top center of the screen.
The top two, in some pattern (that I'm still looking at) should respond with the Easter Egg which gets you to the Diagnostic.
I'm working on it, but you can try too.
Ok, the top two spots, tap: L-R-L-R-L-R-L-R-L-R and you'll get to the Easter Egg.

Renate NST said:
You know, there are more secret touches and broken code all over.
I found another one, but I can't seem to get this to work either.
It's on this screen. There are four touch spots.
The bottom two when pressed and held should show a version number at the top center of the screen.
The top two, in some pattern (that I'm still looking at) should respond with the Easter Egg which gets you to the Diagnostic.
I'm working on it, but you can try too.
Click to expand...
Click to collapse
Thank you very much for your support
The bottom two it showed version.
I tried the top two it no work

dnt83 said:
I tried the top two it no work
Click to expand...
Click to collapse
Ok, the top two spots, tap: L-R-L-R-L-R-L-R-L-R and you'll get to the Easter Egg.

Renate NST said:
Ok, the top two spots, tap: L-R-L-R-L-R-L-R-L-R and you'll get to the Easter Egg.
Click to expand...
Click to collapse
Yes, it worked
Thank you very much!

Renate NST said:
Ok, the top two spots, tap: L-R-L-R-L-R-L-R-L-R and you'll get to the Easter Egg.
Click to expand...
Click to collapse
Hello
Could you show me next step to root it?
Thank you!

Renate NST said:
Ok, the top two spots, tap: L-R-L-R-L-R-L-R-L-R and you'll get to the Easter Egg.
Click to expand...
Click to collapse
Hello
I rooted and can work in adb shell, could you show me how to skip oobe?
Thank you!

dnt83 said:
how to skip oobe?
Click to expand...
Click to collapse
You need to install a launcher so that you have something "Home" to run.
Also:
Code:
# pm disable com.nook.partner/.oobe.WelcomeScreenActivity

Renate NST said:
You need to install a launcher so that you have something "Home" to run.
Also:
Code:
# pm disable com.nook.partner/.oobe.WelcomeScreenActivity
Click to expand...
Click to collapse
Yes, Thank you
I already installed custom firmware
Thank you very much for your support!

And if anybody is wondering, this works on all 5.0 Nooks, Glow2, Glow3, Glow4

Hi, I just picked up a new Nook Glowlight Plus (the 2019 7.8" model) and am trying to get started using it without the compulsory registration. My understanding from the start of this thread is that I should be able to root it, install an alternate launcher, disable the oobe.WelcomeScreenActivity, and I'm off to the races.
I have gotten as far being able to see the device with adb and connect to it, but I can't root it. adb seems to be working as normal (e.g., I can "adb shell" in as I would expect) but any attempts to push files with "adb push" fail. After attempting adb push, the device disconnects from adb and can no longer be seen until I physically unplug and re-plug it. Interestingly, adb push of a directory _does_ create the directory structure on the Nook -- just not any of the actual files...
Any help debugging this is appreciated...
A log of what I'm seeing is here:
https pastebin.com / ti4qB6Xr
(Sorry, I can't post direct links yet, and didn't want to spam the thread with a wall of text...)
Thanks!
---------- Post added at 02:58 AM ---------- Previous post was at 02:52 AM ----------
I should also mention that if I start to go through the on-device Welcome screen (choose timezone, choose wifi network and enter password), before actually getting to the login screen, I'm prompted to allow it to download a firmware update. I did not allow the update, in case a) the update changes something that would make rooting or installing a new launcher more difficult, and b) I don't want to miss the opportunity to note the download link and fetch an extra copy of the update in case it's useful later.
But if the download link is already known to the community, and if the update is unlikely to change anything that rooting/launchers depend on, I would also try letting it download, and then going to the login screen and trying the lower-left+upper-right+triple-tap bypass mentioned earlier in the thread.
Please let me know if I should try this.
Thanks.

So "adb push" is still not working, but I was able to root the device with shell chicanery. I tarred/gzipped the exploit payload, base64 encoded it, and used a shell loop to transfer it a line at a time:
Code:
c=1
cat nookrooter.tgz | base64 -e | while read line
do
echo "$c" >&2 ; c=$(expr $c + 1)
echo "$line" | adb shell 'busybox head -1 | busybox tee -a /data/local/tmp/nookrooter.tgz.b64 > /dev/null'
done
At ~64k base64-encoded lines, it took a bit over an hour to transfer. After base64-decoding, checking the md5 on both sides, and untarring in the right spot, it rooted just fine:
Code:
frappe/home/chris/nook/root-glp/rootGLP-3-13998# adb shell id -u
uid=0(root) gid=0(root)
That said, I'd still love to get some guidance on this device from folks who are familiar with it. Any idea why adb push might consistently fail? Is my basic understanding of how this whole process works is correct? Does it matters if I allow the device to complete the OTA firmware update before going farther?
My intent for the device is to use it as a standalone e-reader. I don't want to ever connect it to a network, nor to run any apps on it other than an e-reader. Public domain e-book content will be converted to EPUB (or, occassionally, CBZ or PDF) with Calibre (specifically the ebook-convert CLI) and copied via USB. I don't need to use "shelves" or whatever the Nook paradigm is for organization, nor will I "manage" the device with Calibre; "management" as such will be strictly copying individual files into a flat directory structure from the shell. I'm not too fussy about fonts, and don't need (or want) much more than the ability to click on a book and page-up/page-down through its contents.
I'm an experienced C/Unix developer, but have never used Android before.
Any help and pointers are much appreciated.
Thanks!

CrisCraigMorgan said:
But if the download link is already known to the community...
Click to expand...
Click to collapse
Yes, the manifest of the updates is discussed here: https://forum.xda-developers.com/nook-touch/general/software-updates-wifi-t4136097
CrisCraigMorgan said:
So "adb push" is still not working...
Click to expand...
Click to collapse
Strange. Why didn't you try adb install on the apk?
Maybe the adb on your host is broken. Try this.
adb push something
Did it fail?
adb devices, is it "gone"?
lsusb, really?
adb kill-server
adb devices, is it "back"?

Renate NST said:
Yes, the manifest of the updates is discussed here: https://forum.xda-developers.com/nook-touch/general/software-updates-wifi-t4136097
Click to expand...
Click to collapse
Thanks!
Renate NST said:
Strange. Why didn't you try adb install on the apk?
Click to expand...
Click to collapse
I'll try installing some apk that way. But in the case of the root payload, there are other files in addition to the one APK.
Renate NST said:
Maybe the adb on your host is broken. Try this.
adb push something
Did it fail?
Click to expand...
Click to collapse
Yup, I tried experimenting with other files, smaller files, individual files rather than directories -- all files failed (though, as noted, directories were created in the case of trying to push a local source directory).
Renate NST said:
adb devices, is it "gone"?
lsusb, really?
adb kill-server
adb devices, is it "back"?
Click to expand...
Click to collapse
I can run some more experiments later. The pastebin log above shows what I saw: immediately after any attempt to use "adb push", "adb devices" showed no devices. I didn't check usbconfig (FreeBSD here, not Linux, but that shouldn't matter), but there were no kernel messages about the device detaching (until I physically pulled the USB cable), so I suspect that the device would still have shown as attached.
Thanks!

So having rooted my Nook, I went ahead and installed the l2.apk launcher posted here https://forum.xda-developers.com/nook-touch/general/normal-launcher-nook-t3966911; disabled com.nook.partner/.oobe.WelcomeScreenActivity; renamed the bootanimation file; and rebooted.
When the device rebooted, it just displayed a message that said, "Unfortunately, com.nook.partner has stopped" and nothing else. Re-enabling com.nook.partner/.oobe.WelcomeScreenActivity restored it to its original boot-up behaviour.
So I think I must be missing something basic about the boot process, or rooting generally.
Should it be sufficient to just have another launcher installed? Do I have to do something particular to invoke it during the boot process?
Should I install TWRP? Alternate firmware, as described here: https://forum.xda-developers.com/nook-touch/general/gp-g3-gp7-8-twrp-alternative-firmware-t4074347 ?
Another question I have is about keeping root access across reboots. I can unpack the exploit in rootGLP-3.zip (from https://forum.xda-developers.com/nook-touch/general/how-to-root-set-nook-glowlight-3-t3802331) and run it to gain root; but when I reboot the device, I lose root again until I re-run the exploit. I tried setting /system/bin/busybox suid root, but then "busybox su" returns "unknown user root" -- I'm guessing because it's calling getpwuid(), but there's no /etc/passwd so the call fails. Could I just create /etc/passwd to define root? I also tried copying the "su" binary in the exploit dir into /system/chris/bin/ and setting it suid root, but this also fails (with no output). I could just write the three-line version of su that calls
Code:
setuid(0); exec("/system/bin/sh")
, but I have no idea how to compile code for this thing. Anything I'm missing here?
Thanks.

I played around a bit more with adb push. Still consistently failing, but restarting the local adb server does at least re-establish connectivity without unplugging/re-plugging the device. Definitely sounds like a problem with my local adb install rather than the device. Considering that I have a(n admittedly super-janky) method to transfer files, I don't feel a strong need to debug it right now.
Code:
frappe/home/chris/nook-13599# usbconfig | grep 1.6
ugen1.6: <BarnesAndNoble BNRV700> at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (2mA)
frappe/home/chris/nook-13600# adb devices -l
List of devices attached
MY_SERIAL_NUMBER device usb:1:6 transport_id:19
frappe/home/chris/nook-13601# adb push ReLaunchX_2.1.5-app-debug.apk /data/local/tmp/
adb: error: failed to copy 'ReLaunchX_2.1.5-app-debug.apk' to '/data/local/tmp/ReLaunchX_2.1.5-app-debug.apk': couldn't read from device
ReLaunchX_2.1.5-app-debug.apk: 0 files...ped. 7.6 MB/s (131056 bytes in 0.016s)
frappe/home/chris/nook-13602# usbconfig | grep 1.6
ugen1.6: <BarnesAndNoble BNRV700> at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (2mA)
frappe/home/chris/nook-13603# adb devices -l
List of devices attached
frappe/home/chris/nook-13604# adb kill-server
frappe/home/chris/nook-13605# adb devices -l
* daemon not running; starting now at tcp:5037
* daemon started successfully
List of devices attached
MY_SERIAL_NUMBER device usb:1:6 transport_id:1
frappe/home/chris/nook-13606# adb shell
[email protected]_6sl:/ # id
uid=0(root) gid=0(root)
[email protected]_6sl:/ # ^D

CrisCraigMorgan said:
Anything I'm missing here?
Click to expand...
Click to collapse
There's all sorts of "rooting" stuff here, but I just prefer a simple replacement of adbd in the ramdisk with one that doesn't switch to user "shell".
I don't want/need/like the chainfire stuff hanging around.
Sorry, I've lost track of where everything here is as I've never used any exploit method.
As for your launcher stuff, did you check logcat to see if there is any obvious reason why partner.apk is dying?
Code:
adb logcat
Have you tried:
Code:
adb shell am start -n com.android.launcher/com.android.launcher2.Launcher
Was the Launcher even installed correctly?
Code:
adb shell pm list packages -f launcher