Database Info

Paranoia, the internet, and your phone.

This is probably not that useful unless (a) you're paranoid or (b) you need access to a secured network from your phone, however I managed to build openvpn and stunnel against bionic and the onboard openssl library. These are available at http://g1.fnord.to/crypto
OpenVPN requires root access and busybox. With this you can conceivably route all IP traffic through a server somewhere by use of the 'route' command, after the VPN link is brought up. This has been tested, and does not seem to affect phone functionality.
stunnel doesn't require root afaik so you should be able to run it from /data/local. This should allow you to encrypt web traffic at least, by setting the proxy via the 'Proxy Settings' app that's available with AnyCut.

Some how I think T-Mobile might get mad if you did this... They say they allow tethering but if you go over your 10GB limit and they can't see your traffic I would think they would want to know what is up.
Good idea and I know some people are that paranoid... but I see this getting people in trouble... or maybe it is just me.

This is GREAT. I've been looking for this since the day I got my G1. I tried to compile a statically-linked binary a while back, but it was HUGE and wouldn't do much before segfaulting at me.
This gets a 4 smilies because this is how I access my work network remotely from my desktop, and now I can access some of these servers for maintenance remotely from my phone! (I would have given it a whole row of smilies, but apparently that is frowned upon.)
Thanks a million for getting this working!
I probably won't be using it as a default route, but it can be a static route to my office servers for sure!

Just got done testing this to vpn to my workplace and it works awesome. It also routes all traffic while tethering thru the vpn tunnel route.
This has been the best reason for me to get root yet.

Wow this is dope... trying to set this up now so now I can connect to my server on the go. I hope t-mobile don't even see this cuz they will be trippin over why do you need to hide your traffic but this is great no more keeping record of wat you do. Next is gonna be p2p and I will even fell back for t-mobile network lol Thanks this great

neoobs said:
Some how I think T-Mobile might get mad if you did this... They say they allow tethering but if you go over your 10GB limit and they can't see your traffic I would think they would want to know what is up.
Good idea and I know some people are that paranoid... but I see this getting people in trouble... or maybe it is just me.
Click to expand...
Click to collapse
It would probably help for wifi usage. I never connect to public wifi with my G1 for this very reason. I have openvpn running on my router at home so I can tunnel into it when i'm wifi-ing on the go. If the G1 is in an area where there is no 3G coverage but there is public wifi, this might just be what the doctor ordered.

Can the G1 auto connect to openvpn whenever it connects to a network (via wifi), i want it to automatically poll mail for me..

The openvpn daemon is designed to autoreconnect if a keepalive ping fails. I would think if it is running in the background and you changed from Edge/3g to Wifi that it would force a reconnect situation, and it would re-establish the vpn through the new connection.
I will test this right now and get back to you

After testing, it works as expected. ~60 seconds after starting wifi I got the following message:
Inactivity timeout (--ping-restart), restarting
After that it re-established the tunnel through the new interface, and I was able to access machines at my office again.

I didn't know if anyone used a shell script to start/stop their VPN but I made the following so that I can easily start and stop it
Code:
#!/system/bin/sh
case "$1" in
'start')
modprobe tun
/data/local/bin/openvpn --config /path/to/config.ovpn --writepid /data/local/openvpn.pid &
;;
'stop')
kill -9 `cat /data/local/openvpn.pid`
sleep 2
rmmod tun
;;
*)
echo "Usage: $0 [start|stop]"
;;
esac

Instead of keepalive for timeout detection, it would be nice to have hooks called on ifup/ifdown, just like debian's /etc/network/if-up.d/*.
It would allow immediate reconnection upon switching interfaces (between 3G and Wifi for example), and also prevent a situation where an interface comes up, sets the default route, and traffic goes cleartext for 60 seconds until vpn reconnection.
I can think of a lot of other uses for such hooks. Does android offer them?
If we're certain the hooks do not exist natively, I'll find a non-polling way to provide them.

I couldn't find an android interface for ifup, so I just used the netlink notifications, via ip(8). Note that you need the real iproute2 ip binary rather than the busybox one. Probably awk as well - I didn't check since I use debian binaries rather than busybox.
Here's how you use it:
Code:
ip monitor route | awk -W interactive '/^default/ {system("/data/local/bin/ifup " $5)}'
It'll execute /data/local/bin/ifup whenever the default route is changed, and pass the interface name as $1. For 3G/GPRS the interface name is usually rmnet0, whereas for WLAN it is if<num> where num is increasing on every insmod, probably indicating a leak in the tiwlan driver.
If you want it to reconnect openvpn whenver the route changes, you should probably
Code:
killall -USR1 openvpn
for any interface other than tap0 (or whatever you call your openvpn interface).
The above method can be used for earlier events such as link-up, but I figured a default route would be the best time to start openvpn. For extra paranoia, you might want to use iptables to prevent connections to anything other than openvpn on tiwlan0, and have an "up" line in your openvpn config file to set the default route through your vpn when it comes up.
When I get around to write a nice script that does the above, I'll post it here.

How much space are we talking about using with native iproute2, awk, and other binaries? I would think the amount of space used is getting rather large. I guess that it quickly becomes a good time to start using the SD card to store apps.
I've not wanted to repartition my card, but I could always make a FS image and mount it 'mount -o loop' style.
As for instant-on, I'm not using this for paranoia like some are, so instant doesn't really matter to me nearly as much as it could otherwise.

Space requirements - I don't know how much it takes with the libs since I just use it inside a debian chroot and it's all on the sdcard. I need debian anyway, to run certain X apps, etc, so for me it's not a waste of space. Anyway, if you just build iproute2 and awk, or even your own binary that just creates a netlink socket and blocks on it, it shouldn't take a lot of space. Or, if you happen to have python on the phone, it can be done in a few lines of script instead of another binary.
Re instant on, I find it better, not just for paranoia reasons (e.g. ensuring that I never send a cleartext pop3/imap password over wlan), but also for long-running connections such as ssh. If I run them over the vpn interface, I have a fixed IP and the connections persist. If, on the other hand, I create the connection directly over 3g/wlan/gprs, it'll die as soon as I change interfaces. Therefore, I'd rather run all long-running connections over openvpn. IP mobility RFC implementation would be more efficient but as long as it's not an option, a vpn will do.
By the way, do we currently have a way to tie a script/executable to an icon/shortcut, or do you run your script from a terminal?

My understanding is there are problems running apps from a gui shortcut.
http://forum.xda-developers.com/showpost.php?p=3142661&postcount=93
I run everything I do from a terminal.

I guess we need a small loader then. Something that calls Exec.createSubprocess(), just like Term.apk does. Each app will have a symlink to this ShellLoader.apk, which will execute scripts based on the name it was executed under. Another one for the TODO list

From Term.java:
Code:
public void onCreate(Bundle icicle) {
super.onCreate(icicle);
Log.e(Term.LOG_TAG, "onCreate");
setContentView(R.layout.term_activity);
mEmulatorView = (EmulatorView) findViewById(EMULATOR_VIEW);
int[] processId = new int[1];
if (TEST_MODE) {
// This is a vt100 test suite.
mTermFd = Exec.createSubprocess("/sbin/vttest", null, null);
} else {
// This is the standard Android shell.
mTermFd = Exec.createSubprocess("/system/bin/sh", "-", null,
processId);
}
final int procId = processId[0];
final Term me = this;
final Handler handler = new Handler() {
@Override
public void handleMessage(Message msg) {
me.finish();
}
};
Can we use Exec.createSubprocess() as in this above but call "/system/bin/su /data/local/bin/APPLICATIONNAME" to make the Superuser app prompts for root among other things?
Maybe create a user interface that lets you enter what you want in the place of '/data/local/bin/appName' and then when it creates the shortcut also asks if that application needs root?
It could be a list of shortcuts that is selected from a list then. Look like a list of bookmarks perhaps?
I don't know enough of the android environment to know how realistically we could do something like that.

looks like that code example from above is old. Current source from git looks different, but the call looks similar enough. I will play with it here shortly.

Yes, we could do that, including su, but be careful with it
Re bookmarks inside a single loader, I think we can do even better:
We can have a single application called Loader, and call it with different parameters using AnyCut. AnyCut has a "make your own shortcut" option, where you can provide Action, Data and Type. I'm not familiar with the Android environment yet, but I guess the Action can point to the loader, and the Data can be a script name to be executed. This way, a single .apk can be used for starting many native programs.
If implemented that way, I suggest stripping slashes from Data and prepending with /data/local/scripts/ or a similar directory, so that it can only execute scripts the user meant for it to run, rather than arbitrary shell commands. /data/local/scripts/ can contain symlinks to scripts/apps the user wishes to execute from the Android interface. It's more secure that way, while retaining usability.
Makes sense?

Certainly does. You wouldn't want someone to be able to 'rm -rf /' or anything like that.
I think I like restricting it to /data/local/scripts and forcing us to symlink or place any scripts we want to be able run in that path.
Also agree with stripping slashes. There might be other sanitizing that we would want to do to keep malicious actions from being performed.
I would think strip any special characters that have special meaning to the shell * | < > ` etc. If we want to do anything that requires these, we put it in whatever shell script and then just call the script.
Maybe the best route is to just scan the /data/local/scripts folder and allow the user to select from a list.
In any case, whoever does this already has root, so it is just as easy to launch a terminal and break everything from there.
Just a few brainstormed thoughts.

Finally got a bluetooth keyboard working

I've had the little targus keypad (bluetooth HID; not SPP) and and Apple bluetooth keyboard (salvaged from an Apple loving friend after he let the battries leak). Now that I finally plucked up the courage to root my Nexus and install the hidd binary I can (with a little bit of effort) finally type effectively if I need to (mostly for connectbot when I need to ssh into remote servers)
I need to issue hidd --connect [BLUETOOTH ADDRESS] each time I want to connect, but I'm happy to do that until it gets a little more elegantly plumbed in.
In fact I'm using it right now

wanna d/l genesisoid or whatever its called and see if you can use that bluetooth keyboard to play some sega roms?

One of the upcoming Motorola devices lists HID as a supported profile. I am all hot and sweaty with anticipation hoping it will be part of Android and not something Motorola added. I am writing a SPP IME (there is KeyPro in the market but the IME is just a side benefit of the actual project) but would be so much happier with official HID support.

SilentMobius said:
Now that I finally plucked up the courage to root my Nexus and install the hidd binary I can (with a little bit of effort) finally type effectively if I need to (mostly for connectbot when I need to ssh into remote servers)
Click to expand...
Click to collapse
I'm trying the same. Where did you get the hidd binary? Or do you mind describing how you built it? Thanks in advance!

I go my info from here:
http://i-miss-erin.blogspot.com/2009/09/connect-bluetooth-keyboard-in-android.html
I already had hcitool from the extras package when I rooted, just needed the hidd binary.

Got mine working too! thanks for the help

Script / app for connecting this?
I just got mine working too!
Wish someone could write an app for this so I wouldn't have to use the console every time I want to connect..
If you have the think outside / igo bluetooth keyboard, word of warning! Be very very careful opening and closing this baby all the time. Don't let it get smashed in your bag. I'm on my 2nd one.. and this one is showing signs of failure. I have to bend the casing a bit to get my return / windows key to work. The inside cables have a tendency to slip out if things get mashed, and trust me, this is one keyboard you don't want to be opening up with a screwdriver..
I did.. got mine working again.. but only after bending the case after it was all put back together again. :-/
Great little keyboard though! Use it with my tablet pc too.
C

FYI the ASE allows you to execute shell scripts from home screen icons.
If you chmod the binary to suid it will run as root
chmod 4777 hidd
Then stick a script in /sdcard/ase/scripts
hidd --connect <BTADDR>
And long press on the home screen->shortcut->ase->your script

Cool. Any idea if it will work with portable bluetooth keyboards? Like the iGo Stowaway?

SilentMobius said:
FYI the ASE allows you to execute shell scripts from home screen icons.
If you chmod the binary to suid it will run as root
chmod 4777 hidd
Then stick a script in /sdcard/ase/scripts
hidd --connect <BTADDR>
And long press on the home screen->shortcut->ase->your script
Click to expand...
Click to collapse
I used gscript didn't have to do the chmod 4755 (has a run as root checkbox)
but still the same, thanks for the tip!

I would love to see a tutorial for the nexus one bluetooth keyboard pairing. I tried to follow the website but got nowhere. Whenever i run:
mount -o remount,rw -t yaffs2 /dev/block/mtdblock3 /system
on my mobile i get the error :no such file or directory. I even created the danm directory and still get nowhere.
Anyone give me a hint? i want to figure this one out!

ok i got past that problem dumb me and my spacebar.
Anyhow now im trying to adb push hidd but im getting an
error: device not found
i have a cyangenmod nexusone with a ubnuntu 9.10 machine.
Thanks!

Alright i just copied and pasted the three files to the folder that was specified. Now everything works other than hidd specificaly hidd -connect gives me a
hidd: not found
Im now stuck here

Draaktatsu said:
Alright i just copied and pasted the three files to the folder that was specified. Now everything works other than hidd specificaly hidd -connect gives me a
hidd: not found
Im now stuck here
Click to expand...
Click to collapse
did you change the permissions for hidd?
chmod 4755 hidd

Tried it just now, says:No such file or directory.
Maybe i have a bad file? Im stumped

LOL, I just paired and connected a Bluetooth mouse. LOL Not very useable though, moving the mouse is equivalent to rolling the trackball.
On cyanogenmod 5.0.4.1 I just had to push over the hidd program as the others were already there.
For everyone that's having problems, the methods described here work like a charm, make sure you turn off Internet Tethering (if you have it) and turn on development debugging mode.
Can't somebody write a simple keyboard pairing program for us? Seems like it would be fairly simple to write a root app that would do this but I'm no programmer, especially in Java.

BrandonG777 said:
LOL, I just paired and connected a Bluetooth mouse. LOL Not very useable though, moving the mouse is equivalent to rolling the trackball.
On cyanogenmod 5.0.4.1 I just had to push over the hidd program as the others were already there.
For everyone that's having problems, the methods described here work like a charm, make sure you turn off Internet Tethering (if you have it) and turn on development debugging mode.
Can't somebody write a simple keyboard pairing program for us? Seems like it would be fairly simple to write a root app that would do this but I'm no programmer, especially in Java.
Click to expand...
Click to collapse
Better yet would be to edit the source of the Settings app to put seamless support for HID in there. I'm going to look at writing a KB pairing program next week, I think.

The normal pairing in Android setting works for pairing keyboards just fine, its the android native hidd equivalent we need.

OK... finally got hidd recognised by deleting the .bin extension.
Now the problem is I get this error:
Can't open HIDP control socket: Operation not permitted
Anyone?

what is ase? i cant find it in market. i created the script and put it in the folder but i just need whatever ase is to create the shortcut

Market Fix - Froyo Apps + Tegra 2 Apps

In addition to the standard Market Fix to get protected applications working (clearing cache/data), we also need to trick Google to think we have a Tegra 2 device.
We simply need to change the following line in /system/build.prop
ro.product.device=olympus
This tells Google Market we are using a Motorola Atrix 4G and will give us the missing Tegra 2 apps when applying our market fix.
However, since we are mimicking a phone, Tablet specific apps will not show up (NYTimes app for Tablets is an example)
Cheers!
Edit:
It is well known that the Google Web Market is hit and miss on our GTablets. This thread indicates it may take a few days for our tablet's to show up on the web interface. However, what this fix does is allow you to download most of the Froyo + Tegra2 apps via the Market Application within our tablets. There will be applications that will refuse to install through the web market interface (if your tablet can actually show up on the darn thing) because of missing capabilities, but will install just fine via the Market app.
If you want to install apps using a web browser from your Desktop computer, I recommend the use of Appbrain to generate your list of desired apps and then syncing your list on the tablet to install.

Hi,
SUPER!!
This build.prop change, just by itself, on stock 3588, allows me to see a bunch of apps I haven't been able to see before, including Firefox, Flash, Tank Hero, etc. Didn't have to do anything else, no fingerprint changes, etc.
Thanks!
Jim

AWESOME! The only thing I can't find is message ease which is no great loss and I'm not seeing it on the web either -- I think they are pulling it on and off the market. But YES -- Laucher Pro, Saumari, Silver Creek games, Flash 10.2, tv.com, both opera browsers, dolphin HD -- all there. FANTASTIC. THANK YOU!
Even Vlingo shows up which was never found before. Truth is I don't even want it but it was one of my indicators.

wd5gnr said:
AWESOME! The only thing I can't find is message ease which is no great loss and I'm not seeing it on the web either -- I think they are pulling it on and off the market.
Click to expand...
Click to collapse
Are you looking for MessagEase?
https://market.android.com/details?id=com.exideas.mekb

Whoops! Helps if you spell it right. I always think that should be a faster keyboard but then I give up and go back to BetterKeyboard or the word predicting one which is great until you need to do Linux command lines and such.
Sorry for the confusion. I even found Astro Bluetooth Module another I used to have to switch for. Very cool.

Hmmm... the market.android.com site no longer shows my device since I made the above fix! It only shows my older device. I tried just clearing the market cache and rerunning but no go. I am now running the regular market fix (clear cache in market, stop, clear data in service framework, stop, reboot).
I did install things off the market, but it had to be from the device.
Ok tablet is booted back up.... drum roll....
Nope. And now I am -- for now -- only showing my paid apps off the market, none of the freebies I had previously installed.
UPDATE: I killed the market data and cache along with the service framework data and rebooted. This made no difference to the web site (unless it takes time for it to catch up) but it did -- after installing something else -- restore my existing apps. On the other hand, having the market working on the device beats the web site, but it still means something is "off".

How do we request this be made a sticky?
I know I've tried just about every market tweak for the last 3+ months and this is the only 1 that made a huge diff.
Jim

I haven't tried this fix (heck I don't even know how to apply it, someone mind helping a noob out?) but I had the same problem you did where the web market doesn't show your device. I tried spamming the regular market fix and still no good.
However I logged back into the web store today and it showed my device, weird.
Not sure how to fix it but yesterday I changed my password so I was forced to sign in again. Of course that didn't work at the moment but I guess it worked since I can now see my device now.
Hope this helped.
wd5gnr said:
Hmmm... the market.android.com site no longer shows my device since I made the above fix! It only shows my older device. I tried just clearing the market cache and rerunning but no go. I am now running the regular market fix (clear cache in market, stop, clear data in service framework, stop, reboot).
I did install things off the market, but it had to be from the device.
Ok tablet is booted back up.... drum roll....
Nope. And now I am -- for now -- only showing my paid apps off the market, none of the freebies I had previously installed.
UPDATE: I killed the market data and cache along with the service framework data and rebooted. This made no difference to the web site (unless it takes time for it to catch up) but it did -- after installing something else -- restore my existing apps. On the other hand, having the market working on the device beats the web site, but it still means something is "off".
Click to expand...
Click to collapse

Yeah I tried logging out of the web site and back in. I've tried forcing a google account sync. And I've tried making sure Talk is running (apparently the website uses talk to send things to your device.).
Just for fun I put my ro.product.name/device/board back to Vega and with no reboot or anything the web site immediately found the device.... curious....
Well now that I'm back on the web site, my market is back to how it was even after I put the olympus line in. Getting too late. Will look at it tomorrow :-(

Hachi2Go said:
I haven't tried this fix (heck I don't even know how to apply it, someone mind helping a noob out?) but I had the same problem you did where the web market doesn't show your device. I tried spamming the regular market fix and still no good.
However I logged back into the web store today and it showed my device, weird.
Not sure how to fix it but yesterday I changed my password so I was forced to sign in again. Of course that didn't work at the moment but I guess it worked since I can now see my device now.
Hope this helped.
Click to expand...
Click to collapse
I did the change by:
- get temp root via z4root
- make /system R/W via root explorer
- start a terminal
- cd /system
- Edit build.prop: busybox vi build.prop
- did regular market fix
- reboot
Jim

wd5gnr said:
Hmmm... the market.android.com site no longer shows my device since I made the above fix! It only shows my older device. I tried just clearing the market cache and rerunning but no go. I am now running the regular market fix (clear cache in market, stop, clear data in service framework, stop, reboot).
I did install things off the market, but it had to be from the device.
Ok tablet is booted back up.... drum roll....
Nope. And now I am -- for now -- only showing my paid apps off the market, none of the freebies I had previously installed.
UPDATE: I killed the market data and cache along with the service framework data and rebooted. This made no difference to the web site (unless it takes time for it to catch up) but it did -- after installing something else -- restore my existing apps. On the other hand, having the market working on the device beats the web site, but it still means something is "off".
Click to expand...
Click to collapse
You're right that having market work on the device beats the website! The web market issues may be a whole separate battle.
Jim

jimcpl said:
I did the change by:
- get temp root via z4root
- make /system R/W via root explorer
- start a terminal
- cd /system
- Edit build.prop: busybox vi build.prop
- did regular market fix
- reboot
Jim
Click to expand...
Click to collapse
I'm quite new to the Android OS so I'm not really sure how to do this.
I installed z4root and got temp root. I'm not sure if I needed it as I read somewhere that Vegan 5.1.1 (which I am using) gives me root already.
But I installed it and ran it anyways.
I'm stuck on giving my /system read and write permissions. Is this 'root explorer' app needed? Or can I use my 'iFileExplorer' app to do so, if so how? (It came with the vegan ROM)

Not sure if you meant to type ifileManger, but it will not get you write permissions. Root explorer will allow you to write. It looks as though you may have to
open a terminal up as discussed above, to change the build prop.
Hachi2Go said:
I'm quite new to the Android OS so I'm not really sure how to do this.
I installed z4root and got temp root. I'm not sure if I needed it as I read somewhere that Vegan 5.1.1 (which I am using) gives me root already.
But I installed it and ran it anyways.
I'm stuck on giving my /system read and write permissions. Is this 'root explorer' app needed? Or can I use my 'iFileExplorer' app to do so, if so how? (It came with the vegan ROM)
Click to expand...
Click to collapse

Hachi2Go said:
I'm quite new to the Android OS so I'm not really sure how to do this.
I installed z4root and got temp root. I'm not sure if I needed it as I read somewhere that Vegan 5.1.1 (which I am using) gives me root already.
But I installed it and ran it anyways.
I'm stuck on giving my /system read and write permissions. Is this 'root explorer' app needed? Or can I use my 'iFileExplorer' app to do so, if so how? (It came with the vegan ROM)
Click to expand...
Click to collapse
Hi,
If you don't have root explorer, there's a free app on market called something like "system mount r/w" that is free that will mount /system as r/w for you. Or, I think that you can do it using a terminal and a mount command (something like mount -remount....).
Normal file explorers won't do the remount.
Jim

mount -o remount,rw /system /system
Watch out for the spaces and you need to be root so do an su command first.
When done, repear the mount command but use ro instead of rw. You can do this with a terminal program or the adb.

Root Explorer is what, $3.99? Worth it for the time savings. I bought the Ti Pro too. $300+ on a tablet...spend $9 on some software to make life easier.

iam a noob. i have stock rom 3588. how do i get market working?

By the light of morning I got back to a full market! But it again broke the web site connection. Is anyone seeing this behavior? Or is it just me?
For the new guys.
1) This appears like it MAY break your connection with the market web site [Update: Wait a few hours and it appears to catch up with you]. It may have other unknown effects. If you are not comfortable with making mods you might wait until more people have reported success or failure with this. For the record I did NOT find this fix (thanks Isira -- see OP of this thread). Just writing up my take on what you need to do. This applies to VEGAn 5.1.1 with supplement. It has been noted that with a stock rom you may need to put "busybox" before commands like cp (which you don't need to use if you have Root Explorer, by the way). If you get this to work (or not) on a different ROM, report it in this thread.
2) That being said, you need a file explorer that will look at / and edit text files, an su utility (comes with your root kit; as far as I know all the custom ROMs are pre rooted) and a command shell/terminal. Or you could spring a few bucks and get Root Explorer which is well worth it and does all of these things. Others have suggested Absolute Root tools which I do not know about. You could also use adb for all of it (which is what I did) but if you know how to do that, you probably don't need me to tell you what to do. We will be changing your build.prop file in the /system directory.
IF YOU ARE NOT USING ROOT EXPLORER GO DOWN TO STEP 3B. IF YOU ARE, GO TO STEP 3A.
3A) Open root explorer. Find /system and press the "Mount R/W" button.
4A) Long press on build.prop and select Copy. Then navigate somewhere like /mnt/sdcard and press the paste button at the bottom of the screen. This is your backup. Please backup.
5A) Go back to /system
6A) Long press on build.prop again. The menu is scrollable. You want Open in Text Editor.
7A) Find the line that says ro.product.device=XXXX (where XXXX is probably Vega). Make it read:
ro.product.device=olympus
Don't change anything else.
8A) Save the file by pressing the menu key and selecting Save & Exit.
9A) Scroll to the top of the /system directory and press the Mount R/O button.
10A) Reboot your tablet. Wait for things to settle down on restart. Open Market. Look for Saumari 2. Look for LauncherPro, Opera Mobile, etc. It will all be there.
If you don't have root explorer:
3B) Open the terminal. At the prompt, enter (spaces and lower case matter):
su
mount -o remount,rw /system /system
HINT: If you think you will do this a lot grab Script Manager off of the market. You can put the mount line in a script, tell it to execute as root (which is the same as su) and then you can run the script when you want to make changes.
4B) Start your file manager and find the /system directory. Your file manager probably starts in /sdcard or /mnt/sdcard. You'll need to go "up" a directory or two to root and then back down. Either way, when you find it, make a backup copy of build.prop somewhere you can write to. Seriously. Do not skip this step. Make the copy.
5B) Edit build.prop. You are looking for a line that sys ro.product.device=XXXX (probably Vega; I don't know about other ROMs and if this works for other ROMs but for VEGAn 5.1.1 its Vega). Carefully replace whatever you have as XXXX to olympus. So the line should read:
ro.product.device=olympus
Note: Some of us had other changes to build.prop. Not clear if these had any effect or not.
6B) Save your changes. If your file explorer is not root, you probably need to save the file to where you can write (your sdcard for example) and the copy from a terminal, such as:
su
cp /mnt/sdcard/new-buildprop.txt /system/build.prop
or
su
busybox cp /mnt/sdcard/new-buildprop.txt /system/build.prop
7B) Open your terminal and enter:
su
mount -o remount,ro /system /system
Remember spaces and case count! Also if you are in the same terminal window as before you don't have to keep entering su since you stay root.
NOTES FOR BOTH SETS OF INSTRUCTIONS
I did the original market fix after saving the file, but some people say it is not necessary. But at least a few people have said they don't see much or anything in market until the redo the fix (the one where you delete the market cache and the google services framework data and reboot).
Things that appear to work:
1) Installing free programs
2) Updating existing programs
3) Amazon market web site oddly enough
4) The official market Web site AFTER WAITING SEVERAL HOURS
5) Buying an app off the build in application
Some of us had other changes to build.prop but I don't think any of them were significant. If you have trouble you might apply it (shouldn't hurt). Also, if your "my apps" only shows your paid apps (or nothing if you have no paid apps), try downloading anything off the market and that will usually restore it. There is also an update local cache key that might do the trick, but loading some freebie off the market is easier. Also check to make sure gtalk is logged in. You can try forcing a resync on your Google accounts (in the main menu under Accounts).
Hope that helps someone. Its early so I probably made mistakes and will edit any that are found.

wd5gnr,
I don't know how "unusual" it is, but on my Gtab, where I had 3452 for awhile, then now 3588, I've always noted that I don't have a "cp" command, so I have to use "busybox cp".
Just FYI, in case anyone encounters this when they try your instructions.
Jim

wd5gnr said:
By the light of morning I got back to a full market! But it again broke the web site connection. Is anyone seeing this behavior? Or is it just me?
Click to expand...
Click to collapse
Based on this thread ( http://forum.xda-developers.com/showthread.php?t=941205 ), it seems it may take a few days for the tablets to register on the market.
I have 3 tablets and I'm trying to change the identifier for each tablet through the ro.product.model and seeing if each of the tablets will show up on the market. So far, only one tablet is showing on the web market, but it's still using the old ro.product.model identifier (GTablet-TnT-Lite).
However, the web market is still pretty wonky. Certain apps may refuse to install through the web market because of missing capabilities on our tablets, but will install just fine through the market app.

Attaining root on Crystalview (Wondermedia) NB4-3/5788

Believe it or not, this netbook comes already rooted, but how to access it is hidden. The original adventure is posted below if you're interested,but I'll put the tl;dr up top.
You'll need to side load the app USB Debug by tatibana. This will shortcut to the hidden developer options. Slide the developer options on. You may or may not need to reboot, I was too focused on USB Debug to notice the SuperUser Options... The default is Always Deny. Set to Always Allow, then you can replace with your choice su manager (I installed Chainfire's SuperSU).
That's it. The rest below is my original posts up to this point, including getting a Linux working prior to figuring out root. Enjoy the read.
Edit 2: You can pick up new posts from this point by going directly to post #11.
Original Post:
---
Okay, this one is a bit puzzling and I haven't found any good info in searches. This is an Android netbook with Jellybean. Pointer control is a single point touch pad which makes zooming out on several apps impossible; I wish to attain root so I can install desktop Linux in parallel and use some desktop apps in place of some Android apps. I know I could use something like qemu but I'd rather install root and use arm binaries than take a performance hit using non-root methods.
This netbook comes with an installed su binary and busybox 1.19.4 but trying to invoke su results in
su: uid 10084 not allowed to su
Settings is also a bit crippled; no Developer Options section means no option to invoke USB Debugging. Anyone have any good ideas?
---
Sent from my C5155 using XDA Free mobile app

addendum
There also is no physical volume or photo buttons, and no obvious way to get into fastboot mode. My guess is that the original OS image was made in root mode, then the CV dev created a default user with almost no permissions, then backed it out effectively locking it out of root forever. I have also discovered that the busybox doesn't have access to the network as this user 10084, negating half its usability. No Play Store either (using Amazon instead), though I can (and have) install to my phone and copy to this if necessary.
This has a cool little form factor and I think has so much potential for a cheap device if I could just bust this major barrier. Does anyone know any sh or setuid tricks that might fake this thing into a root mode, or at least manage to give me enough permissions to edit /system files?
system seems to be owned by user 1003 and group 120, if that helps.
---

Mmmmmm, tasty foot...
So apparently this is normal behavior for the stock android su (see guys, I'm learning >P ); only the user shell (and root) can use su. This thing using a shared uid for apps might or might not have an effect, don't know yet. The normal way around it is to adb shell and su in, then overwrite with a custom su binary such as ChainsDD. I don't know if I have that option since there's no USB Debugging option, and I'm too tired to find out tonight. I will update this adventure later.

USB failed, but not anything to do with adb, didn't even get that far. The netbook failed to even register to the desktop (Linux)... lsusb didn't show anything. I don't know if it's a cable thing (tried direct A-A patch and the MiniUSB charge port- charge port predictably didn't support data and neither standard port showed any reaction) or a hardware limitation.
I also took a crack at adb over wifi but as usual it was the catch 22 of needing root to invoke adbd into tcpip to attain root.
Still open to suggestions... please?
---
Sent from my C5155 using XDA Free mobile app

Developer Options?
This is driving me up a new wall. Based on what I have been reading all day, Developer Options are a core function and cannot be removed, only hidden. This thing has not been giving me much confidence in that statement, however. I have been through the settings over and over again with a fine tooth comb and the whole thing eludes me.
This is Android 4.1.1. The 4.2+ trick (7 clicks on Build Number) doesn't work, and it's not in the App settings either, nor is there any sections renamed "Advanced" or the like. It may not be an end-all but I feel it would at least be a step in the right direction. I might be able to use an exploit such as Poot or Framearoot, which are currently ineffective.
I also haven't had any luck with getting into a recovery boot mode, not sure it's possible with this keyboard (I suspect it's soft driven; inactive until the kernel and modules are loaded). This seems to be just one shut down after another. I need more ideas, pointers, whatever. Don't forget, it can also help the next sap stuck with this model...

I decided to not lose sight of my original reasoning and move forward anyway with an app that claims to install Linux without root. I installed Gnuroot Wheezy which taught me some more f'd up things about this netbook but it at least in concept is working. What more things I have learned...
One of the issues with running Linux without root is the inability to use the external SD-card, at least native, because you can't mount an external partition/file that hasn't already been set up in the mount scripts outside of userspace. Gnuroot uses a chroot off the secure asec in /data. With about 3G user space available on this netbook, you'd think that wouldn't be a problem... but it is, because of another setup issue with this netbook...
See, while the external SD card does mount to /sdcard,/mnt/sdcard, that is NOT where Android app setup calls SDcard... there is a so called internal SDcard that is really a fake vfat via fuse mount off /data mounted to /mnt/local. This means it does no good to move my plethora of other apps to the "SD Card," actually, it makes the problem worse on this device. I imagine it was done so you could swap SD cards without affecting your apps, good move for flexibility but poor for expandability.
For those who would try it, that's also a big hint for getting it working. This device does not have access to the Play market*, so you will have to move helper apps from another Android device over. Don't bother with 3rd party repositories, you will not get everything you need. The biggest issue is the WheezyX obb file. It on install ONLY from the Play store will be located in /sdcard/Android/obb/champion.gnuroot.wheezyx/main.2.champion.gnuroot.wheezyx.obb , on this netbook the file must be moved to /mnt/local/Android/obb/champion.gnuroot.wheezyx or it will not be recognized, and because of the play store issue, can't be downloaded and gnuroot will exit with error.
Anyway, so now WheezyX is actually running and I am attempting to install an Openbox/LXDE desktop... the problem I am hitting now is the space limitation... It said it needed about 330 MB space and I had 360MB available on start... I'm now about 1/4 through and the netbook has come to a dead crawl due to... yep, very little space left (about 55 MB free on /data)... WTF! I feel like I am just not meant to win at like anything...
---
*Edit: Once rooted, the play store can be installed to the system partition and does work pretty good.
---
Sent from my C5155 using XDA Free mobile app

Some success with Linux
Well, it took quite a bit of monkeying and persistence but I do have desktop Linux running via the above described method. I found Synaptic was useful for finding packages but as the GNURoot author warned, for the love of all that's holy, use apt-get to actually install the packages. It seems trying to install a desktop environment via Synaptic totally overthrew the system. Also try installing only a few packages at a time and clean up after each one, especially where space is a premium.
What's left now is experimenting with vnc viewers a/o X11 environments. I'm presently using PocketCloud but it doesn't seem to like this keyboard (right shift = 6, no down arrow, Ctrl is sticky- forget combo keys; at least the included soft-keyboard does work, just a productivity killer) and getting a right mouse click is almost impossible, so I want to see if I can do better.
The environment is OpenBox with lxpanel and the background is set with qiv. I am confident now that providing space wasn't such an issue I could run pretty much any basic Linux program I want. I have not tested audio and I already know just being vncserver that motion video is a bad idea; this was mostly proof of concept until I can open up some space. I may now see how far I can take this (e.g. link large trees to the SD card, such as bin directories; since it's already running fake-root, I'm not too worried about user permissions. I may also experiment with fuse).
Edit:
This does not mean I don't still want to get a true root. If nothing else, even if I can't take Linux off the internal storage, root will allow me to force Android apps on to the external SD; either solves the current space issue and thus is still desirable. I'm just not as stuck in the mud now. Ideas still very much appreciated.
Done and done.

Just a quick update to say the project isn't dead, just dormant. I have successfully turned on USB debugging thanks to a shortcut app called "USB Debug" by Tatibana. Thank you
---
Sent from my C5155 using XDA Free mobile app

Framaroot, Universal Androot, and Poot have all failed.
:banghead:
Have yet to see if physical USB will now work... I don't exactly live alone.
---
Sent from my C5155 using XDA Free mobile app

SUCCESS!!!!!
IDFBT! I must have not been paying enough attention before or something, or maybe it was one of the half dozen greyed out options before... not sure, but after I was again unable to connect via direct USB, I decided to double check the developer options to make sure noting was reset by the last reboot.... and there in bright white last in the top section... Superuser Options (set to Always Deny)! I set it to Ask and tested, but it promptly rebooted as soon as I tried to su, and again on that boot, so I had to set to Always Allow. Amazon doesn't have SuperSU and last I knew ChainsDD Superuser is still adrift in the doldrums, so I'll have to sideload (as usual), but, I just wanted to share. This netbook does come rooted, you just need to turn on the hidden developer options, reboot, and go back and allow SuperUser.
Will report more as I progress. Banzai!!!

Adventures in Linux land
Well, I had mentioned before how space was an issue. Thanks in part to Link2SD, I managed to curb that problem.
Problem still though was my base graphical Linux install was taking 1G of my /data space. Since I made 2G available on the Link2SD ext4 (/data/sdext2) partition, I found I had about 1.3G available after moving most apps over, I decided I'd try a manual data move. I was slow with this since I didn't know how Link2SD or the system was going to handle it. That turned out to be a good thing.
When using Link2SD, one thing that should be obvious is to never move essential apps off the internal storage. These would be things like Link2SD itself, a Terminal emulator, and your superuser manager (e.g. SuperSU); basically, things you absolutely cannot lose access to even temporarily.
Okay, so, to test the behavior, I went into the emulator..
su
cd /data/sdext2
mkdir Linux
That's all. I then did a normal power off and restart. When rebooting, an "Android is Updating..." box came up and went away in a few seconds. The launcher came up and I waited for everything to load normally. Then I started getting a rash of "App is not installed" messages... uh oh. The only reason this turned out to not be a big deal is Link2SD and SuperSU were still on internal storage, and Link2SD is designed to deal with this problem. I simply launched Link2SD, clicked the tab bar on the upper left, and selected "Relink all application files," after which it requested a reboot, and I complied.
With a semi-disaster averted, I went back into /data/sdext2 to see if the Linux directory was still there. Hallelujah it was. Next was finding the GNURoot wheezyx root. This turned out to be fairly easy:
/data/data/champion.gnuroot/app_install/roots/wheezyx . I decided for potential future expansion to move the whole roots directory. Being cautious as I try, I do a copy.
su
cd /data/data/champion.gnuroot/app_install
cp -a roots /data/sdext2/Linux/
(... go make a sammich ...)
rm -R roots
(... go make and eat dinner ...)
ln -s /data/sdext2/Linux/roots roots
This appeared to work at first, until I tried to install something (abiword). I discovered that the permissions were not copied to the lib directories (android security quirk?). This would probably not be an issue if this were a true root install but being a fake root app install, it effectively prevented the installation of libraries. This was fixed simply by doing a chown and chmod on the lib directories.
Contined from above:
cd roots/wheezyx
chown 10102.10102 lib
chmod 771 lib
chown 10102.10102 usr/lib
chmod 771 usr/lib
*note: the app id number may be different on your copy. This will be fairly obvious with a simple ls -lh .
After that, the install completed and this thing is running pretty good. I am now considering this a complete success. While technically solved, I'll keep this thread open for questions or updates (for as long as the mods don't mind).
---
Sent from my C5155 using XDA Free mobile app

Screencap op
Assuming the uploads work this time, attached are some screencaps. Enjoy.

[SCRIPT][1.6+][WHATSAPP][14/11/08] Disable sending read-receipts for WhatsApp msgs

Shell script to disable read receipts for all your incoming Whatsapp messages
Even "better": Others won't see whether you've already read their message(s) or not. However, you will still be able to see the read receipts of others!
Code:
################################################################################
#
# Shell script to disable read receipts for all incoming Whatsapp messages.
#
# [ ANDROID AND ROOT ONLY ! ]
#
# Author: Stephan Schmitz <[email protected]>
# Source: https://gist.github.com/eyecatchup/9af90363732801b131bf
# Last Updated: 09. Nov 2014
#
# ABOUT
#
# You don't like that everyone in your Whatsapp contact list is now able to see
# whether you've already read their latest message(s) or not? Then feel free to
# use the following "work-around" that I found to disable sending read receipts
# globally. Once patched, whenever you get new messages, the senders will never
# see the 2 check marks in blue. They'll just stay gray, just like it was until
# recently. Well, almost. Because you'll still be able to see whether your chat
# partners have already read the messages you sent to them. ;)
#
# DESCRIPTION
#
# In early Nov. 2014, Whatsapp added a new "feature" - read receipts. It means,
# your chat partners will get a visual feedback (2 blue check marks) as soon as
# you've read their message(s).
#
# Unfortunately, Whatsapp's dev team forgot to implement a corresponding privacy
# setting for users to be able to turn off this feature. However, fortunately, I
# found it was fairly simple to disable the feature, since it is set in a public
# XML file in Whatsapp's app data directory.
#
# This script shall serve as a convenient wrapper for those Android users who do
# not live in userland - as well as for the lazy ones.
#
# PRE-REQUIREMENT
#
# Basically, all it needs is a working `sed` commandline utily in path.
# If you should not have "Busybox" installed yet, choose one of the available
# "Busybox" installer apps from Google Play Store and let it install busybox.
#
# USAGE
#
# - Save this script to your phone's sdcard as disable_whatsapp_read_receipts.sh
# - Open a terminal session on your device
# E.g. https://play.google.com/store/apps/details?id=jackpal.androidterm
# - In the console, login as root (type su, hit enter) and type:
# sh /sdcard/disable_whatsapp_read_receipts.sh
# (adjust the path, if required, to fit your's!)
# - Hit the enter button. Done. (Whatsapp will restart afterwards)
#
# If you get any error message a) make sure the /data partition is mounted /w rw
# permissions and b), if the permission for restarting WA is denied, 1st try to
# uncomment the last line of this script (append hash char "#" (without quotes))
# and run the again. Otherwise, consult me for help here:
# http://forum.xda-developers.com/android/development/script-disable-whatsapp-read-receipts-t2933467
#
# IMPORTANT NOTE
#
# The last successful test for this was run at 09. Nov. 2014 and on the Whatsapp
# Android version 2.11.399 and 2.11.432 only. Even though it should work for all
# Android versions, it was not tested. Also, Whatsapp might change their current
# implementation any time soon. So this work-around might stop working any time
# soon too. Keep that in mind!
#
################################################################################
Download
NOTE: This script requires the "sed" command line utily (ie "busybox") installed on the system, which pre-requires a rooted device!
NOTE: The gist requires an update, which I'll post tomorrow. For further details and a manual workaround see my post here: http://forum.xda-developers.com/showpost.php?p=56640205&postcount=9
External link to gist.github.com (see the inline comments for further instructions): http://goo.gl/EiOvO0
Download, run, done. Enjoy. Whatever.
PS: For those who understand German, here're some screenshots of testing this " hack". As you can see, my chat partners can't see the read status. http://imgur.com/a/kzQs3

Nice trick!
However, I've noticed that the preferences .XML files are reset to the original values once the application relaunches. So, basically, the changes do not stick.
Any workaround on this?

smartxdev said:
Nice trick!
However, I've noticed that the preferences .XML files are reset to the original values once the application relaunches. So, basically, the changes do not stick.
Any workaround on this?
Click to expand...
Click to collapse
That's kind of odd, since the script explictly restarts the Whatsapp package *after* applying the changes to the prefs xml. Which then, in turn, should result in no result at all (assuming a restart rewrites the xml), right!? But it does work. Now, the first question would be how you define restart (activity (re)launch, package force && start)?
Update: Just checked it and you're right. If I use the -S option on the am start call (to force stop Whatsapp before (re)starting the activity), running script has no effect at all - since the XML is being recreated. And that also means, that the change will gets lost with every device reboot.
The easiest solution I see here, to have a "permanent" effect, to wrap the script in a plain simple app and attach it an onboot service. (Also, looking at #4, some further checks should be added.) If Whatsapp will leave this current implementation of defining whether to send read receipts or not, I'll invest the time into an app version, I think. (Just don't want to have too much hustle with it. So want to wait whether it's worth to spend more time on this.) Thoughts?

hi, i have this problem:
{
"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"
}
can you fix it?

Dj Mauro said:
hi, i have this problem:
can you fix it?
Click to expand...
Click to collapse
I had permission error too.
In the terminal, try to first run "su" command (without the quotation marks), it will obtain root permissions for the terminal.
Then run the actual command. That solved the permission error for me.
Bexton said:
That's kind of odd, since the script explictly restarts the Whatsapp package *after* applying the changes to the prefs xml. Which then, in turn, should result in no result at all (assuming a restart rewrites the xml), right!? But it does work. Now, the first question would be how you define restart (activity (re)launch, package force && start)?
Click to expand...
Click to collapse
Actually it never worked for me (I mean, script ran successfully, but i have no success in disabling the "read recipient" when i tested it).
Then, I tried to do it manually:
- make a backup copy of the target file (/data/data/com.whatsapp/shared_prefs/com.whatsapp_preferences.xml)
- and then set: "read_receipts" to value="0" in the original file
- save it
- and when i open whatsapp app again, the XML file is restored to the older values, and the "backup" copy gets erased.
And for the "restart" question, i tried the following:
1 - swipe the app away from the recents, make XML modifications, and relaunch
2 - kill the app, make XML modifications, and run it again
I also tried to set XML file permissions to read-only, but it still was replaced by original config. once i opened the app.
-----
I was thinking about another workaround:
Since the read receipt (and delivery too) is usually done by transmitting a small message by the application, back to the sender, once the conversation window is opened.
It may be possible to just block this outgoing communication on your side by XPrivacy.
But, i have yet to hunt down the specific permission/address to block, without crippling the app..

Dj Mauro said:
hi, i have this problem:
snip
can you fix it?
Click to expand...
Click to collapse
As a quick fix, this should work for you:
1.) Add the following line above the line with the sed command:
Code:
mount -o rw,remount /data
2.) Change the last line of the script to the following (if it still compains replace the user id value in the command with that from the error message. and if it still complains, it might even work when you just comment out the line):
Code:
echo `am start --user -2 -n com.whatsapp/com.whatsapp.Conversation`
3.) Back in the console again, login as root (su, enter) and run the script.
Let me know if it worked.
As said in my update to post #3, I'll probably add some automatisms for such issues soon.

Bexton Tnx !

how about an xposed module?

smartxdev said:
I had permission error too.
In the terminal, try to first run "su" command (without the quotation marks), it will obtain root permissions for the terminal.
Then run the actual command. That solved the permission error for me.
Click to expand...
Click to collapse
Yeah, recognized already that I completely forgot to mention that at all (to run the script as root). I updated the inline instructions accordingly.
smartxdev said:
Actually it never worked for me (I mean, script ran successfully, but i have no success in disabling the "read recipient" when i tested it).
Then, I tried to do it manually:
- make a backup copy of the target file (/data/data/com.whatsapp/shared_prefs/com.whatsapp_preferences.xml)
- and then set: "read_receipts" to value="0" in the original file
- save it
- and when i open whatsapp app again, the XML file is restored to the older values, and the "backup" copy gets erased.
And for the "restart" question, i tried the following:
1 - swipe the app away from the recents, make XML modifications, and relaunch
2 - kill the app, make XML modifications, and run it again
I also tried to set XML file permissions to read-only, but it still was replaced by original config. once i opened the app.
Click to expand...
Click to collapse
Sheesh. Okay, I think I got what's wrong here.
As far as I understood, you didn't even got to the point where the file
Code:
/data/data/com.whatsapp/shared_prefs/com.whatsapp_preferences.xml
stored the modified value, correct?
When I was looking at your manual procedure I recognized a small but probably crucial difference! Let's have a look at it. My initial, manual approach was:
# Login as root
Code:
[email protected]> [B]adb shell[/B]
[email protected]:/ $ [B]su[/B]
# Copy the original prefs xml file to /sdcard/.
# NOTE: We use cp as root user, but with the --preserve switch to copy a file owned by Whatapp's OS user.
Code:
[email protected]:/ # [B]cp -p /data/data/com.whatsapp/shared_prefs/com.whatsapp_preferences.xml /sdcard/[/B]
# So, at this point, the copied file /sdcard/com.whatsapp_preferences.xml is still owned by Whatapp's OS user.
# Now, my last 2 steps were to modify the read-receipts settings value in /sdcard/com.whatsapp_preferences.xml and copy back the modified file to its original location, which I did as follows:
Code:
[email protected]:/ # [B]sed -i'.bak' 's/^.*\bread_receipts\b.*$/ <long name="read_receipts" value="0" \/>/g' /sdcard/com.whatsapp_preferences.xml[/B]
[email protected]:/ # [B]cp -p /sdcard/com.whatsapp_preferences.xml /data/data/com.whatsapp/shared_prefs/[/B]
So all together, this was:
Code:
[email protected]> [B]adb shell[/B]
[email protected]:/ $ [B]su[/B]
[email protected]:/ # [B]cp -p /data/data/com.whatsapp/shared_prefs/com.whatsapp_preferences.xml /sdcard/[/B]
[email protected]:/ # [B]sed -i'.bak' 's/^.*\bread_receipts\b.*$/ <long name="read_receipts" value="0" \/>/g' /sdcard/com.whatsapp_preferences.xml[/B]
[email protected]:/ # [B]cp -fp /sdcard/com.whatsapp_preferences.xml /data/data/com.whatsapp/shared_prefs/[/B]
So what happened with the last 2 commands that made it work for me, but breaks in the script version?
The core problem here is, as I just learned, that GNU sed's -i extension does not actually edit files in place (--in-place is a misnomer, in my opinion); it creates a temp file, deletes the original file, then renames the temp to the name of the original. The result is a new file - much possibly with a different owner.
So in my manual procedure, the result of the sed command worked fine except for the fact that it changed ownership on all the files it went through. The only problem is that these files (or at least the backup file) were owned by the root user - the user I run the command as. However, then I used the -f switch (to force overwrite) and the -p switch (to preserve permission, ownership and timestamps) to copy back the prefs file from /sdcard/ back to its original location in the Whatsapp data folder. That means, as a result, in the Whatsapp data folder there was a) no new file from another user (the backup file) and b) the modified prefs xml file still had its original ownership information. Basically, this kind of "fixed" sed's -i mode behaviour on the prefs file plus didn't created a new file in Whatsapp's data folder.
The last step to solve the puzzle is fairly simple. I just tried the procedure manually - as defined upthread - with all my friends' phones. Thus, I didn't noticed the sed behaviour. Plus, the friend Iinitially wrote the script for didn't told me that it wasn't working for him.
Anyway. Let's finally come to how to fix.
A quick look into the sed manual unveils that -c switch should do the trick:
Code:
-c, --copy
use copy instead of rename when shuffling files in -i mode
(avoids change of input file ownership)
Unfortunately, this switch is not enabled in all the busybox sed's for Android. Also, this would still leave us with a new file in Whatsapp's data directory. Even if all ownership information of existing files can be preserved, we should also not create any files in the folder that are not known to the Whatsapp app.
So basically my manual approach is the way to go:
a) Save the backup of the original prefs file somewhere on /sdcard/
b) Preserve ownership and permissions for /data/data/com.whatsapp/shared_prefs/com.whatsapp_preferences.xml
NOTE: Even if you got the value in the prefs xml saved to "0" and with no changes to ownership and permissions, you still need to restart any running Whatsapp process. Otherwise the change will have no effect! And, rebooting the device, resets the prefs xml file!
I'll post an updated version later. Until then, probably the easiest way to test this, is the manual way using a text editor app on your device.
- Open any text editor app with root capabilities (I used https://play.google.com/store/apps/details?id=com.maskyn.fileeditor )
- From the menu choose "Open file", navigate to /data/data/com.whatsapp/shared_prefs/ and open the file com.whatsapp_preferences.xml
- Find the line that reads <long name="read_receipts" value="SOMENUMBER" /> (SOMENUMBER is a placeholder, of course)
- Replace SOMENUMBER with 0 (zero), so the line reads <long name="read_receipts" value="0" />
- Save the file
- Now, close Whatsapp from the recent apps view and restart it.
- You can verify the change by running the following command (as root) from a terminal on your phone:
Code:
cat /data/data/com.whatsapp/shared_prefs/com.whatsapp_preferences.xml |grep read
- You can verify the ownership and permissions by running the following command (as root) from a terminal on your phone:
Code:
ls -l /data/data/com.whatsapp/shared_prefs/com.whatsapp_preferences.xml
smartxdev said:
I was thinking about another workaround:
Since the read receipt (and delivery too) is usually done by transmitting a small message by the application, back to the sender, once the conversation window is opened.
It may be possible to just block this outgoing communication on your side by XPrivacy.
But, i have yet to hunt down the specific permission/address to block, without crippling the app..
Click to expand...
Click to collapse
Sure, feel free to share any suggestions!

Ather said:
how about an xposed module?
Click to expand...
Click to collapse
I guess that'd be possible too. Just that I never looked into it yet.

Thanks, @Bexton for your detailed explanation.
Manual editing by Turbo Editor did the work for me.
I tested it, and the blue check marks were indeed blocked.
And btw, Turbo Editor has a nice "recent files" list on the startup, so reediting of the parameter on restart should be simple and easy.
Then, i did Restart (full restart to the device), and.... ...it still holds!
The parameter in the XML is unchanged and read notifications are still blocked
So, it made me wonder, why it didn't work for me before? I used ES Text Editor to edit the XML, it was fine, but then i made a backup copy somewhere inside the /data/data/com.whatsapp/ folder. And I think that "foreign" file caused full rewrite of the xml files by the app.
I hope it may hold permanently, but, we'll see..

Ahoy everyone!
We're 2 students from the University of Milan who created a repository [https://github.com/phosphore/whatsapp-blue/wiki]
for an Android app with the aim of getting rid of those blue ticks. We're currently
considering and testing out all the possible solutions including the modification
of com.whatsapp_preferences.xml (as found by @Bexton) or the filtering of the TCP
packet responsible for the read receipt.
Although using Bexton's method greatly simplifies the solution, it is just a
temporary workaround before Whatsapp fixes it.
Having a proxy filtering the requests should be a permanent solution. We are
reverse engineering FunXMPP (WA proprietary protocol) to find that particular request.
We're open to contribution!

smartxdev said:
So, it made me wonder, why it didn't work for me before? I used ES Text Editor to edit the XML, it was fine, but then i made a backup copy somewhere inside the /data/data/com.whatsapp/ folder. And I think that "foreign" file caused full rewrite of the xml files by the app.
I hope it may hold permanently, but, we'll see..
Click to expand...
Click to collapse
Some editors use a similar internal workflow as GNU's sed in -i mode and without the c switch. Resulting in "corrupted" files (in the sense of ownership & contex)..
Th3Zer0 said:
Ahoy everyone!
We're 2 students from the University of Milan who created a repository [https://github.com/phosphore/whatsapp-blue/wiki]
for an Android app with the aim of getting rid of those blue ticks. We're currently
considering and testing out all the possible solutions including the modification
of com.whatsapp_preferences.xml (as found by @Bexton) or the filtering of the TCP
packet responsible for the read receipt.
Although using Bexton's method greatly simplifies the solution, it is just a
temporary workaround before Whatsapp fixes it.
Having a proxy filtering the requests should be a permanent solution. We are
reverse engineering FunXMPP (WA proprietary protocol) to find that particular request.
We're open to contribution!
Click to expand...
Click to collapse
Could you hook up via email? I'm working on an app as well and currently considering the possibilities. Maybe it's worth sharing thought.. Please send to [email protected], thanks!

This is why I waited before investing more time into it, hehe. So, time to relax for everyone. Here is news:
Whatsapp will soon get the ability to turn off the blue checkmark read indicator, according to an alleged Beta tester of the application.
Click to expand...
Click to collapse
Original tweet: https://twitter.com/0xmaciln/status/530294585072025600
Via: http://www.myce.com/news/whatsapp-w...ble-privacy-sensitive-blue-check-marks-73438/
Looks like this thread will be obsolete very soon.

Bexton said:
Whatsapp will soon get the ability to turn off the blue checkmark read indicator, according to an alleged Beta tester of the application.
Original tweet: https://twitter.com/0xmaciln/status/530294585072025600
Via: http://www.myce.com/news/whatsapp-wi...k-marks-73438/
Looks like this thread will be obsolete very soon.
Click to expand...
Click to collapse
Nice!
I think whatsapp(facebook?) expected this to come, they already had some bad experience with the "last seen" issue some time ago.
And it is already implemented as a simple switch inside XML prefs...

Bexton said:
Looks like this thread will be obsolete very soon.
Click to expand...
Click to collapse
Hm, maybe I was wrong and it will not become obsolete. Maybe I will still build an app for it. Why? I found more news on the matter, that pointed out a major difference to me.
The same person who confirmed the additon of the on/off toggle for the read receipts, Ihlan Pektas, actually blogged about the feature already a few days ago. The essential information given in his blog post here (in German language) for me is, that he says that early alpha builds already have an implementation for it, and when you disable sending your read status (so that others can't see if you've read a msg), you will, in return, NOT be able to see the read status of your chat partners! (What makes perfectly sense, becausee it's the same way they do it for the "last seen" status.)
That being said, I think there'll be interest in an alternative. An alternative that is capable of disable sending one's own read status, while still being able to see the read status for one's own msgs, sent to others?!
Well, we'll see. (But the party ain't over yet.. )

Thanks Bexton. Tried your manual method with ES File Explorer, without making a backup, and it works. Even survives a full reboot.

Bexton said:
That being said, I think there'll be interest in an alternative. An alternative that is capable of disable sending one's own read status, while still being able to see the read status for one's own msgs, sent to others?!
Well, we'll see. (But the party ain't over yet.. )
Click to expand...
Click to collapse
I see your point, but to make this happen, we need to look at another approach. Because, now we disable it by the pretty obvious flag in the pref. file, and once they release a "feature" it will be probably the same flag that will cause you not the deliver read receipts either.
The thing is, that in fact I barely use whatsapp, for various reasons. I'm here to help some non-techie friends of mine.
Anyways, I use Open WhisperSystems' TextSecure mostly (less polished and fewer features, but free, opensource, and actually secure).
So, a short while ago, they've introduced "delivery receipts". And for some reason, only I was able to get others' delivery receipts, but when others send me messages, they didn't receive a delivery receipt from me. (That's basically what we are trying to do here, just with read receipts)
At first, I was sure there is some bug in this. But then it turned out that I tuned XPrivacy too tight on restrictions, and this new feature could not get through and send the delivery notice. (unfortunately I don't remember what exactly the troublesome restriction was)
That's why i first thought about XPrivacy for this case as well.
Logically, the mechanism here might be the same, and once we find out what activity or address to block it will do the trick without letting the app itself know about it.
And it seems like @Th3Zer0 guys have the same direction in mind.
Bottom line: sounds like a good idea to find out how to "cheat" those things, and maybe build Xposed module/app on it

This seems to be the equivalent of downgrading whatsapp, letting you see blue ticks but other's cant see
It seems that it disables the part where you can highlight your own message and see who has seen the message though.
Working on 2.11.432.
Whatsapp just enabled a new feature a la Telegram where you can see who's typing in a group.

Contradictory to my previous report, I'm noticing that over time the "read_receipts" parameter keep reverting to a original value. What's weird though is that i was unable to pinpoint when it actually happening, since it happens without any kind of full phone restart in between.
Have you (@Bexton?) any insight on it?
And by the way, as I was talking about the sadly unpopular, but security-wise superior TextSecure, this post came out: Open Whisper Systems partners with WhatsApp.
Sounds promising, but it still remains to be seen how it all gets implemented and how much of a metadata leakage will be going on, since it is very unlikely that a proprietary and closed source SW company as WhatsApp will kill their business value (which is an insight on near 700M users' data) just like that.