Database Info

ssh issues

I have a freebsd server on my home network that i used to be able to ssh into from my G1 using connectbot, but this recently stopped working. using the command line ssh program i get the following warning:
"Reading the random source seems to have been blocked. If you are experiencing problems, you probably need to find a better entropy source."
one thing i cam across while researching this was to replace /dev/random with a sym link to /dev/urandom, but i definitely want to ask an expert before i go messing around with device files.
i'm currently running JF1.42 RC33. I'm also a fairly experienced linux user, but by no means an expert. Thanks so much in advance for all your help, xda rocks!
note (for all you note lovers ): i think this stopped working when i upgraded to JF1.41 RC33, but I have no idea if that has anything to do with it. I also reinstalled freebsd around that time.

I'm using JF1.41 RC33 and have no trouble using connectbot or command line ssh. Are you able to ssh to your bsd server from something other than your G1?

yup, i'm able to do it from my main box. i'm having some trouble gettin rsa keys set up, but ssh itself is working

I updated to 1.42 and was not able to duplicate the error. Here is how those devices look on my phone:
$ ls -la /dev/*random
crw-rw-rw- 1 0 0 1, 8 Feb 12 22:30 /dev/random
crw-rw-rw- 1 0 0 1, 9 Feb 12 22:30 /dev/urandom

my devices and permissions are the same (damn lol). do you think that renaming /dev/random and making /dev/random a symbolic link to /dev/urandom would cause any problems? i'm gonna do some more research on the differences between the two, but any input would most definitely be appreciated

I'm not familiar enough with how Android as a whole works to say if that change would be ok. My concern would be about something else affected by this change.
Because of that, I would think the choice would be better made on an application level. Maybe this is an option that the connectbot developers would be willing to add as a program setting?
Perhaps there is a workaround. Some of the information out there suggests that if the random source is software-only, running more applications which access the network may cause it to unblock. After getting the error, I'd try pulling up a web page, signing into IM, searching in maps, etc. and then trying ssh. While not really a solution, if it works it would confirm the above information.

Well, I did some web browsing, messaging, and maps work, as well as installing Debian from the easy install thread, and it half worked: the terminal ssh program now works, but connectbot still doesn't. i tried 'use any unlocked key' and 'don't use keys', to no avail.
all i'm getting is a quick flash with a WARNING message that pops off the screen to fast for me to read. I think it's a different issue for connectbot? i wish i could hold onto that connectbot screen before it kicks me off...

[script] holdapp.sh: cheesy but effective browser-kill prevention

TLDR:
holdapp.sh is a shell script that keeps the browser (or another app) from being killed. Prevents the page-reload problem.
Why:
The madness of android's system architecture means that in low-memory situations, the kernel oom-killer tends to merrily slay any app the user flips into the background, to make more room for whatever is java process is launched, and the HORDE of stuff that was automatically launched and allowed to occupy memory idle - even if that stuff is utterly useless crap that some market app spawns. In theory, murdered apps are supposed to be given enough time to record their state so that they can recover.
Unfortunately the browser does not do this, in my experience. This is especially a problem on the G1, and even moreso on the bloated pig that is android 2.x. You'll be browsing wikipedia, get a text message, flip to mms, respond, flip back, and discover that the page is reloading...or worse, the page - and all opened windows, and history - are gone, leaving you with just your homepage (laughing at you). Meanwhile, the clock app that was spawned an hour ago in response to NTP...is still there.
Screw that, I rigged it to behave with duct tape.
App murder is controlled by /proc/(pid)/oom_adj. The higher the number, the more likely something is to be killed when the kernel (hatchet in hand) goes foraging for memory. Foreground apps are 0, thus rarely killed. Connectbot stays at 1, google apps at 2. Your dead wikipedia research was 7 or 8.
How:
By default, holdapp.sh will check /proc/(browserpid)/oom_adj every second, and set it to 1 whenever it goes below 1. If it isn't running, it will look for it every 20 seconds.
Installation/Usage:
download somewhere and run:
ash /path/to/holdapp.sh
(not sh)
-or-
chmod 755 /path/to/holdapp.sh, and make sure the top #!/system/xbin/ash points to ash (not sh)
holdapp.sh can protect a different app if invoked like:
* holdapp org.example.bookreader *
The forced oom_adj level, it's 1 second check delay, and the 20 second running-check delay can be adjusted by editing the variables at the top of the script (ADJ, WAIT_RUNNING, WAIT_APPDETECT). Other variables enable logging and forced pidfile and busybox locations.
* holdapp -k or holdapp -k appname * kills the script (not the protected app)
* holdapp -c or holdapp -c appname * returns 0 if running, 1 if not.
* holdapp -n or holdapp -n appname * run in foreground.
Caveats:
* If you don't manually kill the browser, or run 'holdapp -k', it will never exit.
* This is not very efficient, for a shell script, as it reads /proc/(pid)/oom_adj every second. I have not experienced a -noticable- performance impact, however (it's minimal, compared to the dalvik stuff that runs). Using inotify won't work as it doesn't detect when a file from /proc vanishes.
* Protecting the browser comes at the cost of making -other- backgrounded apps more likely to be killed. I use the browser alot, however. If that's the case with you, it's probably a good tradeoff.
* I have mostly tested this on Donut. On that, the impact to other apps has not been crippling. I have not tested this on Froyo, and it may cut things -too- close for the G1, there. Test for a long time before sticking it in userinit.sh
Todo:
* Test higher WAIT_RUNNING values.
* Multiple app support without multiple instances.
* Look into something less cheesy for detecting oom_adj changes and app death.
* Fix the dammed browser to set it's own OOM value the right way, and add 'exit'

Does it work with Opera Mini?

Abolfazl said:
Does it work with Opera Mini?
Click to expand...
Click to collapse
If you run it as:
holdapp com.opera.mini.android

This is really amazing. good work.
I've noticed that messaging is really sticky in the memory too..., but all of a sudden after cm6 rc2. rc1, it didn't stick. Also, is this method how cyanogen added "keep home in memory"? i'd assume so.

Sounds useful, gonna give it a try. Thanks for sharing.
€: Small feedback for holdapp with opera mini:
I found that if I go from opera to the homescreen and then back to opera, it pops up immediately at tha last visited page.
If I do something else in between, like locking or using another app, opera will start up fresh, but jump to the last visited page without reloading it.
That is something it never did before, seems like it tries to save its state when exiting, but without holdapp, it gets killed too early to fully save.
€€: OK, just checked with "ps|grep opera": Opera still gets killed as soon as I launch another app and as soon as I unlock from sleep mode. I guess it just takes up so much mem that it gets murdered no matter what, as soon as some memory is needed.

[SOLVED] Mount a smb/cifs share

Thank you in advance if you can help with this, unfortunately I'm not going to be able to follow through with this very well at the moment. If this gets no attention I'll bump it when I can follow through.
I want to mount a smb/cifs share from my router to my Nexus 5.
I can successfully mount the share and view it in terminal but none of it shows up in any apps...and that's pretty much my issue.
Here's some unimportant info, and a little info about me, I'm as scatterbrained as they come. The reason I want to do this is to stream my movies on the "NAS" to my Chromecast through Allcast or something.
As of now I'm using an entware mini dlna package on the router to stream everything to Avia. My problem is dlna broadcasts all my media to my entire network...no password required or anything. Also accessing my files through Avia is a pain in the ass, navigating through the folders repetitively gets exhausting.
Here's what I've come up with so far:
I'm using hammerhead-faux123-010m kernel, and SlimRC3.
CIFS DebugData:
Code:
CIFS Version 1.78
Features: posix xattr
Active VFS Requests: 0
Servers:
1) Name: 192.168.1.1 Domain: WORKGROUP Uses: 1 OS: Unix
NOS: Samba 3.0.37 Capability: 0x80e3fd
SMB session status: 1 TCP status: 1
Local Users To Server: 1 SecMode: 0x3 Req On Wire: 0
Shares:
1) \\192.168.1.1\NAS Mounts: 1 Type: NTFS DevInfo: 0x0 Attributes: 0xf
PathComponentMax: 255 Status: 0x1 type: 0
MIDs:
The disk is actually Ext3, not NTFS.
This guy kinda just crushed all my hopes and dreams of the future but I'm trying to use his OneClickMount alpha app.
http://forum.xda-developers.com/showpost.php?p=49651026&postcount=127
app here:
http://forum.xda-developers.com/showpost.php?p=49693815&postcount=129
This is what I have tried, I ended up with the same results:
Code:
[email protected]:/storage/emulated/0/cifs # setenforce Permissive
[email protected]:/storage/emulated/0/cifs # getenforce
Permissive
[email protected]:/storage/emulated/0/cifs # mount -r -o noperm,rw,file_mode=777,dir_mode=777,uid=1023,gid=1023,unc=\\\\192.168.1.1\\NAS,username=***,password=*** -t cifs none /storage/emulated/0/cifs
[email protected]:/storage/emulated/0/cifs # ls
My Music
My Pictures
My Videos
Torrents
Then I tried OneClick Mount app:
https://www.dropbox.com/sh/muabb9vp1i8ubxt/o78FSYMcHo
From what I can tell from the app logcat, the app tries to move the debuggered file, create its own with a chosen command inside, start then stop it, and restart the original.
I might try to do this manually later, as in a month from now at the least. I'm pretty sure a certain someone is pissed off at me for not becoming one with the universe n all that jazz.

I'm gonna leave a couple links here so I can delve into them later, they seem to have crazy amounts of useful information:
[HINT] How Stickmount (and others...) are working with Android 4.2
Debuggered script
Sincerely, Head is spinning

Sorry but as of android 4.4.2 CIFS at a device level (all accounts see the network shares) no longer works and no one has a solution. This includes rooted devices and custom Roms. Of course apps such as ES File Explorer can have network share accesses but not all apps can utilize that access. For example MX player can be invoked from an ES file folder by clicking on a video file but apps like PowerAmp cannot see those folders. Some apps include built in network share features but they have the same restrictions as I previously described.
Things all changed when Android included multiple accounts and security started to get tighter. Initially developers found ways around those measures but too my knowledge, with 4.4.2 no one has found a work around.
Sent from my Nexus 10 using XDA Premium HD app

3DSammy said:
Things all changed when Android included multiple accounts and security started to get tighter. Initially developers found ways around those measures but too my knowledge, with 4.4.2 no one has found a work around.
Sent from my Nexus 10 using XDA Premium HD app
Click to expand...
Click to collapse
One workaround is hijack a system process such as debuggerd (debugger daemon) which runs with higher than su permissions. This method still works but is awkward to exploit manually. Apps such as foldermount use this workaround but not for network mounting, but it shows that it is still possible.

I have a Raspberry Pi running OpenELEC for streaming my locally stored media. I use my Chromecast for streaming Netflix, Google Play media, etc.
I understand what you are trying to do, but a dedicated device works great for me.
That said, you might keep an eye on VLC to see if they start supporting casting to Chromecast. That would likely accomplish what you are asking.

rootSU said:
One workaround is hijack a system process such as debuggerd (debugger daemon) which runs with higher than su permissions. This method still works but is awkward to exploit manually. Apps such as foldermount use this workaround but not for network mounting, but it shows that it is still possible.
Click to expand...
Click to collapse
This is what I'm going to attempt next, from what I read it can be terribly inconsistent if not done through SSH, so that's a bummer. I just need to get more information on how to do it. Debuggered in general confuses me.
embhorn said:
I have a Raspberry Pi running OpenELEC for streaming my locally stored media. I use my Chromecast for streaming Netflix, Google Play media, etc.
I understand what you are trying to do, but a dedicated device works great for me.
That said, you might keep an eye on VLC to see if they start supporting casting to Chromecast. That would likely accomplish what you are asking.
Click to expand...
Click to collapse
This is what I've been wanting to do with my old Galaxy Nexus. I have the HDMI adapter and everything but the screen is broke (the digitizer works), so I plug it into my TV and randomly hit the screen hoping to eventually connect my bluetooth mouse lol. No such luck. I wish I could just boot it into a custom build but that's never gonna happen. Unless OpenELEC works on android devices? Seems unlikely.

debuggerd can be replaced with a shell script with the mount command in it and it will run at boot.
It's really messy. I found I had to put the original debuggerd back or the phone would lock up.
Sent from my Nexus 5 using Tapatalk

WEEEEEOOOOOOO I finally got all my stuff to show in a file manager, now I just need to find a terminal command to trigger media scan on the folder. Right after I eat a bunch of chicken.
Awesome, it works perfectly. And by perfectly I mean it's the messiest thing I've ever done on Android. I'm not really sure how this affects battery and all but thank god this finally works.

For anyone interested:
Follow the directions in this post.
I didn't understand the mount command he used so I used
Code:
/system/xbin/busybox mount -r -o noperm,rw,file_mode=777,dir_mode=777,uid=1023,gid=1023,unc=\\\\192.168.1.1\\NAS,username=***,password=*** -t cifs none /data/media/0/cifs
You also need to use /data/media/0/ otherwise it will only work in already opened apps apparently.
So thanks rootSU...And that should work, I'm going to do it in a way where I don't have to use scriptmanager but that's the gist. All the credit goes to the people in the threads I linked, I have absolutely no idea what I did here and I learned nothing.
Nothing special to see here. :good:

Here's a way to unmount it so it doesn't explode your apps when you disconnect WiFi:
/system/bin/debuggerd.binnn
Code:
#!/system/bin/sh
/system/bin/umount_movies.sh
exec /system/bin/debuggerd.bin "[email protected]"
/system/bin/umount_movies.sh
Code:
#!/system/bin/sh
/system/xbin/busybox umount /data/media/0/cifs
/system/xbin/busybox umount -r -o noperm,rw,file_mode=777,dir_mode=777,uid=1023,gid=1023,unc=\\\\192.168.1.1\\NAS,username=***,password=*** -t cifs none /data/media/0/cifs
Script_eject.sh
Code:
#!/system/bin/sh
mount -o rw,remount /system
sleep1
/system/xbin/busybox mv /system/bin/debuggerd /system/bin/debuggerd.binn
sleep 1
/system/xbin/busybox mv /system/bin/debuggerd.binnn /system/bin/debuggerd
sleep 1
mypid=$(/system/xbin/busybox ps -o pid,comm | /system/xbin/busybox grep 'debuggerd' | /system/xbin/busybox awk 'NR == 1 {print $1}')
/system/bin/kill $mypid
sleep 1
/system/xbin/busybox mv /system/bin/debuggerd /system/bin/debuggerd.binnn
sleep 1
/system/xbin/busybox mv /system/bin/debuggerd.binn /system/bin/debuggerd
sleep 1
mount -o ro,remount /system
I'm automating all this with Tasker.
Script task: (I have it run at boot)
waits 15 seconds
run shell command to kill debuggerd
wait 5 seconds
media action scan card /
Script_eject task: (I have it run when I disconnect from my SSID)
run shell command with the script_eject.sh code
wait 6 seconds
media scan card /
It has been seamless so far, also lol.

sendan said:
For anyone interested:
Follow the directions in this post....
Click to expand...
Click to collapse
I have yet to try your solution but what Rom and kernel do you have installed? I ask because in the past (Android 4.1) you needed a custom kernel that supported CIFS or you needed to add modules to stock.
I'm using rooted stock, Franco Kernel.
Sent from my Nexus 10 using XDA Premium HD app

3DSammy said:
I have yet to try your solution but what Rom and kernel do you have installed? I ask because in the past (Android 4.1) you needed a custom kernel that supported CIFS or you needed to add modules to stock.
I'm using rooted stock, Franco Kernel.
Sent from my Nexus 10 using XDA Premium HD app
Click to expand...
Click to collapse
I'm on the latest Slim, with latest faux kernel. Faux has cifs modules built in, I'm not sure about Slim or Franco kernel. If you have a cifs folder in /proc/fs I assume that means the kernel has the cifs modules.

[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.

[TUT] Remove default launcher on Amazon Fire 8" & 10" (NO ROOT)

I never finished this, please use Launcher Hijacker v3+ as it works much much better!
EDIT 09/23/16
I finally found a permanent solution to how to change fire launcher on the Amazon Fire without root. It works on any version (FireOS 5.3.1) on any tablet variant (7, HD 8, HD 10 etc...).
You can read the detailed tutorial at http://forum.xda-developers.com/ama...-remove-default-launcher-amazon-fire-t3288310 but basically you run one command, must be done after reboot currently via adb shell:
Noval Launcher on Amazon Fire no-root:
Code:
nohup logcat -c; logcat | grep --line-buffered 'flg=0x10200000 cmp=com.amazon.firelauncher/.Launcher' | while read line; do am start com.teslacoilsw.launcher/.NovaLauncher; done &
That's it. Once you paste that into your adb shell you're done; you now have a default launcher programmatically set via ADB.
Optionally, you can install the modded firelauncher.apk so you can finally delete it without root .
(this is optional, you wont have any launcher after doing this! backup your old APK!!)
Code:
adb install -r -d com.amazon.firelauncher.apk
... as you can now see this will -r reinstall and -d downgrade the launcher, causing it to crash and never open.
Thanks for your support guys, I love android!
EDIT:
I have updated with a new method that is much better, the only negative to this new method is when you hit the home button, for a brief moment you see the firelauncher. Performance, speed, and bugs are perfect.
Just paste this code in adb shell, I'm working on setting up nohup to work with it, when you close adb it will stop working.. Going to bed for now though.
Code:
#!/bin/bash
am monitor | while read -r line; do
if [[ $line == *"firelauncher"* ]]
then
am start [B]com.newlauncher.launcher[/B]
fi
done
I'm new to the whole Android scene, and recently I had acquired an Amazon Fire HD 8. The only complaint about this tablet is the lack of Google Play and the horrible firelauncher. There is currently no root options available for the Fire HD modles 8 & 10, so I have spent the time to develop a temporary workaround.
Please take a quick look at the developmental thread I previously created so we can collaborate to make a more efficient version of this:
http://forum.xda-developers.com/hd8...zon-fire-hd-8-10-remove-firelauncher-t3286646
Disclaimer:
If you plan on installing new applications/packages while this script is running you may have a hard time. Installing packages may take 2-10 minutes, or maybe not at all!
If you experience any problems you can undo everything by running the undo script attatched (unix), or by typing "adb shell ps | grep /system/bin/sh", you will see anywhere from 2-10 processes listed. For each type "adb shell kill -9 <pid>", pid would be the process ID, should be the first number you see on each line.
There is a small chance when you press the home button that it will load the regular firelauncher, do not fret, try again and it will go to whichever launcher you previously selected.
Performance may be slightly altered, if it becomes too bad to use try adjusting the script and change the interval at which it loops (set to 20 by default).
This is an alpha experiment, and I am a noob with Android so please bare with me
This is a noobish approach to disabling the firelauncher (com.amazon.firelauncher.apk), please do not judge it, this is also my first time releasing something for Android.
If you are using a unix operating system (like Linux or Mac), I have compiled a script that does the work for you! Windows users will have to wait and do it manually since I am unfamilar with batch (would someone like to help with this?)
Automatic Tool (easy, linux, mac only)
Step One:
Download the two script attachments:
remove_default_launcher.sh - disables amazon's firelauncher
re-endable_firelauncher(undo).sh - reverts the process, if you have any issues
Step Two:
Run the following commands to make the scripts executable:
Code:
chmod +x remove_default_launcher.sh
chmod +x re-endable_firelauncher(undo).sh
Here is a video showing you how to do this next step:
https://www.youtube.com/watch?v=1IVOa048UbY
Run the tool to remove amazon's nasty launcher!
Code:
./remove_default_launcher.sh
Step Three:
The script should automatically do everything, when it's done, check your Fire. Keep pressing the home button and switching between applications until you get the "Change default launcher" dialogue, make sure you have an alternative launcher installed beforehand or else you won't have a launcher! When it's all working how it should be go to step four!
Step Four:
Simply exit out of your terminal window, do not type anything, just exit ADB. The script will continue running!
This is what a successful window looks like, whenever you have confirmed it is working, close out of the ADB window and end that process.
{
"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"
}
Manually (harder, windows)
Step One:
Open up a new ADB shell window and type
Code:
adb shell
Step Two:
Once you are in the shell window, simply copy and paste this line of code and press return. It is just a simple bash script that loops the command "install -r -d "/system/priv-app/com.amazon.firelauncher/com.amazon.firelauncher.apk"" which will reinstall the firelauncher repeatedly, which temporary uninstalls it.
Code:
#!/system/bin/sh
nohup
while :
do
kill $!
sleep 1 & pm install -r -d "/system/priv-app/com.amazon.firelauncher/com.amazon.firelauncher.apk" & sleep 20; kill $!
kill $!
done &
exit
#press enter now
After pressing enter, you can watch it go to work, or you can close out of the adb window and unplug your device, it will continue to run until you kill the shell processes or reboot the device. Make sure you have an alternative launcher already installed so it can easily be set as default. EDIT: Reboot may not reset it, which is cool but could be annoying. To turn off this wonderful feature open up adb shell and use "ls | grep shell" and kill using "kill <pid>" all releated processes to /bin/shell or whatever. It may take up to a minute to reset.
If you have any issues at all please comment and I will send you a private message with detailed instructions catered to your specific issue!
If you are a dev, take a look at my unix auto-install script, it may help you figure it out yourself as well. I need someone who understands batch to help me write a windows version .
I literally spent about 45 minutes working on this noobish approach, so if you find bugs or want to modify the script, simply post in the comments your version and why you think it is more efficient. If you want to help make a dedicated and more efficient approach to this, check out the development thread here (there are alternative methods here too):
http://forum.xda-developers.com/hd8...zon-fire-hd-8-10-remove-firelauncher-t3286646
This appears to be a very stable system actually, I recommend everyone does this to the Fire HD tablets!
I hope this helps someone, if this helps you please give me a thanks so I know it

Just tried this on my HD 8. Works like a charm! Haven't noticed much of a performance decrease as I figured would happen. On occasions when I press home it likes to hang at a black screen until I press home again. Other than that its perfect. Thanks!

ZenPowerBuilder said:
Just tried this on my HD 8. Works like a charm! Haven't noticed much of a performance decrease as I figured would happen. On occasions when I press home it likes to hang at a black screen until I press home again. Other than that its perfect. Thanks!
Click to expand...
Click to collapse
I am working on a better version, I have noticed some performance issues that irritate me.. I also made the scripts better much better.
I am glad I was able to help you .

I have updated with a new method that is much better, the only negative to this new method is when you hit the home button, for a brief moment you see the firelauncher. Performance, speed, and bugs are perfect.
Just paste this code in adb shell, I'm working on setting up nohup to work with it, when you close adb it will stop working.. Going to bed for now though.
Code:
#!/bin/bash
am monitor | while read -r line; do
if [[ $line == *"firelauncher"* ]]
then
am start [B]com.newlauncher.launcher[/B]
fi
done

nyln said:
I have updated with a new method that is much better, the only negative to this new method is when you hit the home button, for a brief moment you see the firelauncher. Performance, speed, and bugs are perfect.
Just paste this code in adb shell, I'm working on setting up nohup to work with it, when you close adb it will stop working.. Going to bed for now though.
Code:
#!/bin/bash
am monitor | while read -r line; do
if [[ $line == *"firelauncher"* ]]
then
am start [B]com.newlauncher.launcher[/B]
fi
done
Click to expand...
Click to collapse
Has anyone had any luck finding a way to keep this script running? I am experimenting with Python..

I have not had too much time to work on this, but all the puzzle pieces are here if anyone wants to make a permanent solution.

nyln said:
I have not had too much time to work on this, but all the puzzle pieces are here if anyone wants to make a permanent solution.
Click to expand...
Click to collapse
I have used your manual method and during the execution of this process I could with the command "adb shell pm hide com.amazon.firelauncher" the amazon firelauncher set as permanent hidden. After that I could set the Nova Launcher as a standard launcher. As a substitute for home button (was not working) I set in the "overlays app" the Nova launcher as a foreground application. So I can select the foreground Nova launcher symbol as a home replacement. For me is that a good workaround.

schr01 said:
I have used your manual method and during the execution of this process I could with the command "adb shell pm hide com.amazon.firelauncher" the amazon firelauncher set as permanent hidden. After that I could set the Nova Launcher as a standard launcher. As a substitute for home button (was not working) I set in the "overlays app" the Nova launcher as a foreground application. So I can select the foreground Nova launcher symbol as a home replacement. For me is that a good workaround.
Click to expand...
Click to collapse
The package manager requires root or superuser in order to hide/disable the firelauncher package properly. You probably have the 7" model.

nyln said:
The package manager requires root or superuser in order to hide/disable the firelauncher package properly. You probably have the 7" model.
Click to expand...
Click to collapse
That is true, that the package manager requires root or superuser in order to hide/disable the firelauncher package.
But there must be a "time gap" when there is running in a first adb window (task) the following adb shell script
!/system/bin/sh
nohup
while :
do
kill $!
sleep 1 & pm install -r -d "/system/priv-app/com.amazon.firelauncher/com.amazon.firelauncher.apk" & sleep 20; kill $!
kill $!
done &
exit
and in a second adb window (task) is executed the "adb shell pm hide com.amazon.firelauncher" command.
Remark: I must multiple times repeat this command until I get the "TRUE" confirmation.
I has this done on my HD8 ( 5th generation) model. wiht the firmware 5.1.1.

nyln: awesome job!
now i bought this tablet for my son (6 yrs old) and the "child profiles" suck since they do not allow non amazon apps to be shown there. So having the nova launcher is the next best thing since i can hide the apps i dont want him touching. Problem is this if we are out somewhere and an app crashes the tablet, i have no way to get nova back on.
Is there a way to put this script on the tablet and run it that way?

5.1.4?
It is not working on 5.1.4?

XJimmyCaoQ99X said:
It is not working on 5.1.4?
Click to expand...
Click to collapse
You can downgrade to 5.1.2

@nyln can't wait to try this when i get home, can you install widgets on nova launcher now?
Sent from my HTC 10 using XDA Labs

ahac85 said:
@nyln can't wait to try this when i get home, can you install widgets on nova launcher now?
Sent from my HTC 10 using XDA Labs
Click to expand...
Click to collapse
How it actually works:
First of all, corrupting the firelauncher will prevent your system from loading it, which saves memory and cpu resources on these low-end devices. After that, in order to replace the system launcher I actually just intercept the home activity and allow a launcher of your choice to open. So it's really just a clean hack you won't notice. Only downside currently is the fact that it takes about 100ms for your home button to actually take you to the launcher of your choice.
tldr: It should work perfectly normally with widget.

XJimmyCaoQ99X said:
It is not working on 5.1.4?
Click to expand...
Click to collapse
It works on all versions, including 5.1.4. In fact, this will work on ANY device with ANY operating system. If you have 5.1.4 why don't you just root?

Can someone tell me if this works after reboot?

@nyln when i try to execute the script i get "syntax error: 'while' unmatched"
I saved the script to a file on my fire HD 8 and executed it with sh filename.sh, because with adb shell i pasted the text but i couldn't press enter to execute it. It just entered a new line to the script.
Here is how it looks:

aldileon said:
@nyln when i try to execute the script i get "syntax error: 'while' unmatched"
I saved the script to a file on my fire HD 8 and executed it with sh filename.sh, because with adb shell i pasted the text but i couldn't press enter to execute it. It just entered a new line to the script.
Here is how it looks:
Click to expand...
Click to collapse
The image looks good. You may need unix for this or cygwin.

But as i understood, the script runs on the fire tab? So why should it matter what OS I am pushing the script with? Or why should Unix work better than windows?

I'm not totally naive to the command line, nor to customizing android installations. This is my first experience with the Amazon tablets; I have the Fire HD8 6th-gen. I'm running the 5.3.1.1 firmware. I tried entering the command in the top post, entered into a terminal emulator, and it didn't seem to return anything -- no error, no nothing. Still having the same issue; I can run NovaLauncher and it's fine until I get into a different app or hit home, then it goes back to Amazon's junk launcher... am I doing something wrong in the terminal?