Hi all,
...my recently bought BenQ E72 (candidate to replace my Tornado) has kept me busy and below is my findings-log (which most of them I could not find elsewhere, so they may be useful for you as well).
My device is intended for BT Fusion Service (which is no more offered) and this may explain the cheap price at Expansys.UK (I have not bought it from them, but from a different source in the UK offering refurbished ones).
Unfortunately my device was sent without a wired headset (which I am still struggeling to get). My investigations on the dual-use of the mini-USB are so far failing to decode the use of the wires. I suspect that (just like for the Motorola Razor V3) some active electronic parts are required in the headset to communicate with the mobile.
Cleanup \Windows folder:
- Remove locales not needed for MunduIM (fr, it, br, ...directories)
- \Data folder is for beetzRSS -> move to SD card in options menu
- \Java folder for JBED -> move to SD card, change keys in registry at (HKEY_CURRENT_USER\Software\JBlend)
- \Profiles folder for PIE -> move to SD card by changing paths at: HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders (may not be persistent if card is not ready at boot time or is removed)
- \Rings folder for ringtones -> also in \windows but are not referenced from there, so they stay here
- \skins folder is for HipCam (HKEY_LOCAL_MACHINE\Software\Emuzed Inc\HipCam)
- \sounds folder is for Camera sounds (HKEY_LOCAL_MACHINE\System\Pictures\Camera\OEM)
- \themes folder is for HipCam (HKEY_LOCAL_MACHINE\Software\Emuzed Inc\HipCam)
- \traveller folder for FIZZ Traveler
(move to SDCard, change items in HKEY_CURRENT_USER\Software\FizzSoftware\MicroClient\TRS)
Ring tones selected from:
\windows\rings\*.*
\windows\ring*.* (no midi)
Install more than one T9 language:
- get packages from http://melgurth.ovh.org/index.php?page=downloads
- download also the package that you already have + the ones you want (so all have the same version)
- install them all, ignore device reboot requests in the meantime
- edit HKEY_LOCAL_MACHINE\T9 Input Method\MUI\Languages string "Available" to contain concatenated (separated by comma) all language numbers
- reboot device
Retrieve hidden settings/options in the setup menus by removing the commenting in the relevant XML files:
- callforwarding.cpl.xml get CFU settings for Data and Fax (Phone->Call Forwarding)
- clckalrm.cpl.xml get Automatic Timezone setting from Network (Clock&Alarm->TimeZone->AutoTimeZone)
- telephonygsm.cpl.xml get Frequencyband selection (Phone->Band Selection = usually "automatic")
- connectgsm.cpl.xml get SMS delivery options (Connections->SMS Service = usually "circuit only")
Info:
This device obviously is configured differently for several operators (see \windows\initflashfiles.dat).
Mentioned interesting strings are Orange, movistar, Flashlite, etc..
Intersting that the BT Fusion does not have an entry here.
Power Drain:
- batteryfunctions do not deliver drain and temperature, but the backup battery voltage is reported
Drain is (rough values):
- 60 mA Display visible
- 90 mA Lowest Light
- 110 mA more
- 120 mA normal
- 130 mA high
- 150 mA highest
BT creates peaks ~ 10 mA on top roughly once per second
WiFi creates peaks ~60 mA similar rate as above
- power off still drains the battery to charge the backup battery but only a few µA (micro Ampere)
Interesting Programs (not linked via .lnk files) in \windows:
- DevHealth.exe will also be called by LogMaster and creates a very elaborate memory and process report. It is named "mem_1.txt" and is either located in the Storage Card root or the main memory root, sized ~ 292kB. Subsequent calls will generate files named mem_<n>.txt where <n> relates to the called number. This file includes the DLL relationship of all active loaded modules, so it is easy for ROM cleaners to sort out the debug ROM remains.
-> This is the key application to investigate further any modifications of Startup options or ROM modifications.
- LogMaster.exe sets various trace and log points, can call netlogctl.exe, swmodemtrace.exe, celogflush.exe, DevHealth.exe, WinsockLogApp.exe, links to LogUtil.dll which relates to logfiles: OSImageVersion.txt, sqpco.log, sqmodem.log, sqdriver.log, sqatcmd.log)
- QDW.exe (internall referenced: "QDW.exe is launched by AppExceptionMonitor.exe", but this .exe is missing, only a dll is remaining) This would read (or write) to files in \Windows\System\ExceptionExtraLogs\. It calls copylog.exe to do the job.
If directly called it asks for a memory card and generates a directory \yyyymmdd_hhmmss\ExceptionExtraLogs\ generating (copying) files ELog.txt KITL.txt qatcmd.log qdriver.log qmodem.log qpco.log verinfo.txt call is hinished with "copy failed".
- PreForWSA.exe is called via HLKM\init\Launch.. and may prepare WinSockLogging (may call \Windows\WinsockLogApp.exe)
- prtscrn.exe generates a screendump of the current state, it is also called via long press of the Vol-Up key and generates a file called scncap<n>.jpg in the "\My Documents" folder (<n> is a sequence number starting at 1).
ToDo:
- remove UMAClient.exe from \HKLM\init\Launch.. but still keep WiFi switched off after reboot. UMAClient cares for the settings in Settings->Connections->WiFi transmission. If not loaded also the WiFi mode to disable WiFi if not connected after <time> does not work.
Candidates for ROM Cleanup:
- CeRegExport.exe (not a valid Windows CE application), executes on PC and links to rapi.dll to communicate with the device.
- D3DMDemo.exe (just displays a boiuncing ball and a rotating colored cube)
- D3DMPerf.exe (displays a colored cylinder, then quits)
- related dlls: D3DM_TI3D.dll, d3dm.dll (not referenced in mem_1.txt)
- AppExceptionMonitor.dll
...more to add here once ROM cooking will be possible
What do these programs do?
- ERS.exe (stays resident, links to coredll.dll only)
...
enjoy + enhance,
bye
tobbbie
hi
thanks for your effort.
i'll study this report and compare with my e72 (by expansys, sim free and app locked, unlocked by utility found on the net)
can't edit the windows files
Thanks for the information. I have been trying to get access to the 'band' setting for some time. However I have been unable to edit the actual xml files. I have tried using SDA unlocker and RAPI and keep getting 'phone is unlockable'. How are you editing these files?
You cannot edit them onboard as they are in ROM. Copy them to your PC, remove the Read-Only attribute, edit and copy it back to the device. It will put in device memory and virtually overwrite the ROM copy. If you delete it on the device the old ROM copy will be used again.
Thanks. That is what I have been trying to do, but every time I get '...could not be placed on device. You do not have permission to create item'. It is like the file system is locked, but I cannot find a way to get past it. Any ideas?
Oh, yes you need to unlock it first. No clue how I did it, it is also not directly mentioned in my old blog. But from there are some links to other sites - you need to look it up there. It is basically the same thing that needs to be done on any WinMo device. Have you tried to search here already (use "E72 Unlock" as a start)?
Thanks. I was able to unlock the phone, copy the xml files off make the changes (removed the commenting), and copy them back to the device. However when I try to use a control panel function that relies on one of these xml files I get 'the control panel document telphonygsm.cpl.xml cannot be loaded. Verify the XML and try loading the control panel again.'
The XML is well formed (as best as I can tell), yet I get this every time I swap in the modified file I get this. If I put the original back in place everything is fine. It looks like the XML is bad, but I can't find anything wrong with it.
Ok, I think I figured it out. In the section that was commented out there were languages that were not relevant to what I had setup on the phone. Once I removed those it accepted the XML files and I was able to view the control panel. Thanks for your help.
Good stuff here. Bump up.
Has anyone found a way to change default hardkey mappings ?
Impressive! Thank you for your hard work. I have the same phone and I am glad we can all share our findings here.
I believe a good source of information will be in the engineering menu which I can't access (yet).
I don't plan on hitting random codes but I can tell you how to enter a code if you want to:
##*[Numbers]#
Be warned, there are codes that will trash your ROM, so be careful!
Also, I am planning on running this on my phone when I have some free time:
http://www.fewbits.com/startmgr/
I will log my findings asap
Cheers from Argentina!
Dear All,
I have a benq e72 since one year. The problem; once I wake up in the morning (three days before); I saw my PDA was not functioning and all applications inside were referred as "not found" icons.
I simply tried to power it off ... not suceeded ... it was completely hanged.
I removed the battery and restarted. dead .. it shows me only BenQ (the very initial screen) .. no more going to windows.
I tried to master reset the device by clicking right key + power button .. but again not succeded ...it shows me "proceeding master reset" .. and nothing proceed up actually.
I tried to update the loader .. by clicking left key + power button .. same situation .. nothing happened.
I tried the KITL too... by clicking home + power button ...
I tried to upgrade the rom to wm 6.1 or 6.5 ... i followed your posts ... but shows me "download ebood error" ... again not succeeded ..
the warranty is finished also ...
Can any one help .. please ....
What if you buy a new battery and shove it in? Would that work?
tobbbie said:
Hi all,
Retrieve hidden settings/options in the setup menus by removing the commenting in the relevant XML files:
- callforwarding.cpl.xml get CFU settings for Data and Fax (Phone->Call Forwarding)
- clckalrm.cpl.xml get Automatic Timezone setting from Network (Clock&Alarm->TimeZone->AutoTimeZone)
- telephonygsm.cpl.xml get Frequencyband selection (Phone->Band Selection = usually "automatic")
- connectgsm.cpl.xml get SMS delivery options (Connections->SMS Service = usually "circuit only")
Click to expand...
Click to collapse
There is the orginal xml files for who forget backup these..
The original files stay in the ROM - even if you "overwrite" them with the changed files. What you see in the \windows directory is an overlay of the ROM filesystem with a directory of the same name where you can write to. So in fact you just "overlay" the ROM file with one on the device. You cannot loose the original file - hence no need for a backup
You detect those files in ROM usually by their Read-only attribute, but to be sure use Totalcommander CE - it shows in the file properties if it is a ROM file.
I have installed an Android Application which was developed by the friend of mine. It had installed on my Android phone (HTC G2, with Android 2.2). I need to locate the application forlders, and especially SQLite database which was created along with the application, because I need to copy it to my PC. I did seach on SD card but I did not found it, so I assume it must be on the device RAM, but I really don't know the structure and how the apps are organized. I might suspect the SQLites data filename, but that all I know at the moment.
Can somebody pint me to some utility which will allow to find the database, and the application path, and most of all to copy it to the PC ???
Thanks - Arthur
The database and any other "data" used by the app will be located in /data/data/ then inside a directory that corresponds to the app's package name. If we use the Kindle app as an example, the path to it's data would be: /data/data/com.amazon.kindle
unfortunately I checked this foldeor on RAM as well as SD and couldn't find it. device /data folder is empty, and SD gas some other stuff bot not this App.
aklisiewicz said:
unfortunately I checked this foldeor on RAM as well as SD and couldn't find it. device /data folder is empty, and SD gas some other stuff bot not this App.
Click to expand...
Click to collapse
I should have also said, you need to be rooted in order to see the contents of the /data directory. Without root access, it will be shown as empty because you do not have permission to view or modify. If your phone is rooted, you can use Root Explorer, Terminal Emulator, or adb to access /data and copy, modify, create, or delete files there.
Thank you for your time. That would explain why I do not see it.
OK, I have HTC G2 from T-Mobile, I think it has Android 2.2
Nothing was changed or updated on this phone since I bough it last fall. I'm not with T-Mobile anymore so I do not wat to mess up with the phone unless I'm really sure what am I doing. The only nice thing is that the phone is unlocked now. The reason I ask those questions is because I am working on some tool, which is a desktop program wchich supposed to sync SQLite data from device to the PC.
What I want to do is to connect the device through USB cable, then have it mapped is it normally does (i.e. drive H. Then access the SQLite file from the desktop application by opening the database through that link and syncing the records. Not sure but I hope this approach would work. If it cannot work that way then eventually I want to copy the SQLite dB file to the PC sync database and then copy it back to the device. I already have a desktop App which work on SQLite localy so now I want to access the device, having the same dB file residing on my android phone instead on my local HD.
What could be the reason that the installed APP doesn't want to move to SD ???
I would appreciate any suggestions...
What is required to root the phone? I've herd there are some risks. Besides I probably have to find some other solutions as none of the App users would want to root their devices (or have a knowledge how to do it).
aklisiewicz said:
Thank you for your time. That would explain why I do not see it.
OK, I have HTC G2 from T-Mobile, I think it has Android 2.2
Nothing was changed or updated on this phone since I bough it last fall. I'm not with T-Mobile anymore so I do not wat to mess up with the phone unless I'm really sure what am I doing. The only nice thing is that the phone is unlocked now. The reason I ask those questions is because I am working on some tool, which is a desktop program wchich supposed to sync SQLite data from device to the PC.
What I want to do is to connect the device through USB cable, then have it mapped is it normally does (i.e. drive H. Then access the SQLite file from the desktop application by opening the database through that link and syncing the records. Not sure but I hope this approach would work. If it cannot work that way then eventually I want to copy the SQLite dB file to the PC sync database and then copy it back to the device. I already have a desktop App which work on SQLite localy so now I want to access the device, having the same dB file residing on my android phone instead on my local HD.
What could be the reason that the installed APP doesn't want to move to SD ???
I would appreciate any suggestions...
What is required to root the phone? I've herd there are some risks. Besides I probably have to find some other solutions as none of the App users would want to root their devices (or have a knowledge how to do it).
Click to expand...
Click to collapse
Took me a bit to get back to you but figure better late than never...
Here is a good FAQ on rooting among other things specific to the G2(the US variant of the Desire Z). In order to root your G2, this guide looks to be good as he's simplified and automated a good bit of the process, should be safe, and seems to work. You'll need to install the two apps he mentions in step 1 and download the zip file he mentions in step 2 which is attached at the bottom of the post then just follow the instructions.
As for the database stuff, if you end up needing to access the /data directory you'll have to be rooted. Also, moving the app to the sdcard won't really help you with having access to the app's files. Froyo built-in App2SD just moves the apk file to a hidden directory on /sdcard (.android_secure) but the app data, cache and all that stuff will still be on internal memory. But to answer why the app won't move to the sd card, I'm guessing it's because the app itself must allow for it to be moved since by default, an app doesn't have this enabled unless the app dev gives it that ability.
To communicate with the phone, even with root access, you'll probably have to do so through adb commands or use an adb shell to be able to run shell commands on the phone. This would require adb be set up on the user's computer. If you want to play around with adb, there's a nice guide called ADB for Noobs that goes through setting it up and starting out using it. I can't say I've really done anything with SQLite databases on Android and certainly not then syncing it to a computer so I could be off-base or overlooking a workaround.
Thank you for your valuable information. You guys are really great help, and I appreciate your time. I will study the links provided.
In the meantime my main concern is to access SQLite database, as I need to get to the records, or at least be able to copy it back and forth between device an PC. I guess the database file would be something like MyDatabase.db , but I have no cule how to find it and copy it. As you have said it might be in some system protected directory. The main issue is that I will ne a solution which would work on every standard device (no the rooted one), so I need something very easy for the user to setup and follow. I have seen a utility that allow to manipulate SQLite records directly on device, but again thsi tools requires to root the phone (which I'm reluctant to do) because ot the above reasons. If you could help my to resove this I would be very graceful!
Arthur
aklisiewicz said:
Thank you for your valuable information. You guys are really great help, and I appreciate your time. I will study the links provided.
In the meantime my main concern is to access SQLite database, as I need to get to the records, or at least be able to copy it back and forth between device an PC. I guess the database file would be something like MyDatabase.db , but I have no cule how to find it and copy it. As you have said it might be in some system protected directory. The main issue is that I will ne a solution which would work on every standard device (no the rooted one), so I need something very easy for the user to setup and follow. I have seen a utility that allow to manipulate SQLite records directly on device, but again thsi tools requires to root the phone (which I'm reluctant to do) because ot the above reasons. If you could help my to resove this I would be very graceful!
Arthur
Click to expand...
Click to collapse
Unless there is some trick I don't know about you are going to have to be rooted to get access to the database. I found a couple links discussing this: here and here. The second link does mention that the app with the database you want to access could be written to store the database on the sdcard where it would then be accessible but that would be unsecure since anything could read/modify it there.
Thanks, looks like I have to do more research on my own. It is hard to believe for me that Google would not allow to access the same database from different Apps. I've seen there is a Java class ContentProvider which seems to allow that, so I will study this, perhaps it will help. Thank for you help.
Arthur
I've noticed since upgrading my Droid X to Gingerbread that many websites that were previously fooled by setting the User Agent (in Dolphin HD) to "desktop" are no longer fooled and can now detect that I'm on a mobile device. This can be quite irritating as the mobile version of many sites is horrible.
To see if this article pertains to you, if you're set for a desktop user agent string, go to http://www.bbc.co.uk and see if you get the mobile version of the page or the desktop version. If you get the mobile version despite your user agent setting, this hack may help you.
When this first happened to me I decided to find out how the sites were detecting the fact that I'm on a mobile device. Generally a website only knows what you tell it about yourself, and what you tell it about yourself is 100% in the HTTP headers your browser sends (or that get added by a proxy server if you use one). So the first logical place to look was to see what all headers the browser was sending. Note: for any who might object that it also knows things about you by your cookies, your cookies are actually sent as HTTP headers as well.
I have a CGI script on one of my web servers that I use to see what all headers my browser is passing. There are plenty such scripts/sites on the web -- here is a decent one (it's not mine) if you want to see what your browser sends. Examining the headers, one stuck out like a sore thumb:
Code:
HTTP_X_WAP_PROFILE='http://uaprof.vtext/com/mot/mb810/mb810.xml'
Geez, that's a pretty dead giveaway isn't it? I checked a phone running FroYo and it does not send that header, so that further confirms this is the header these sites use to detect me as a mobile (since they don't detect me as a mobile under FroYo and do under Gingerbread).
I then Googled HTTP_X_WAP_PROFILE and found numerous coding resources where they suggest looking to see if that header exists and/or is set to anything in order to detect mobile browsers. Bingo.
Great - so how to get rid of it? My first thought is that since the header is clearly identifying me as a Droid X (MB810), there has to be something in the phone that is providing the data. Since I observed that the header is present whether I access the net via WiFi or via 3G, that further confirmed that this is all happening in the phone and not being added by Verizon in transit.
The first sensible place to look was /system/build.prop. Turns out that the first sensible place to look was the right place to look as I found this line:
Code:
ro.mot.hw.uaprof='http://uaprof.vtext/com/mot/mb810/mb810.xml'
Well, that's about as perfect as you could ask for. Not knowing if the phone might be touchy about completely removing this setting, my first attempt was to change the line to read like this:
Code:
ro.mot.hw.uaprof=''
I found that you must reboot the phone for the setting to take effect (no real surprise there). Unfortunately, afterward, when I examined the headers being sent by the browser, they now contained this:
Code:
HTTP_X_WAP_PROFILE=''
With that setting, the various websites still detected me as a mobile browser (which you would expect). Next I tried changing the build.prop to this:
Code:
ro.mot.hw.uaprof=
* Note - there is nothing after the equal sign - not a space or anything, just a carrriage return.
This (pleasantly) resulted in the HTTP_X_WAP_PROFILE header being completely absent -- the ideal outcome. Happily, the various websites that were detecting me as a mobile no longer did. Success!
In the interest of being thorough, I tested just removing the ro.mot.hw.uaprof setting altogether (by commenting out the line). I figured that probably was not the best plan, but I wanted to see what would happen. When I did that, the following header was the result:
Code:
ro.mot.hw.uaprof='http://uaprof.motorola.com/phoneconfig/MotoMB200/profile/MotoMB200.rdf'
Interesting default value -- and of course I was again identifiable as a mobile device.
So, the fix for this is pretty simple. The exact property that needs to be modified in your build.prop would of course vary if you're not running a Motorola build, but I'd expect it to be readily identifiable. Of course you have to be rooted to do this, and of course you should make a backup copy of your build.prop before you modify it, and of course you should think about what your fallback recovery is going to be if you foul up your build.prop and end up in a boot loop or something. Can you boot into Recovery and then fix the file with ADB, etc. -- it all depends on how your phone is set up.
For those that like step-by-step, here's precisely what I did:
Open Root Explorer (or other "root aware" editor)
Navigate to /system
Mount system as R/W
Open build.prop in text editor
Find the ro.mot.hw.uaprof line
Put a # at the beginning of the existing line (to make it into a comment)
Insert a new line below the existing line that says "ro.mot.hw.uaprof=" (without the double quotes -- no characters after the equal sign)
Save and exit editor
Mount system as R/O
Reboot phone
By doing it this way I end up with a backup copy of the original string in case I want to easily put it back. Root explorer automatically saves the original build.prop as build.prop.bak, but if you're really cautious you might want to actually make a copy of the file to your SD card or something.
At this point, in Dolphin HD, with my user agent string set to Desktop, all of the web sites that had begun seeing me as a mobile device now serve the normal desktop page (as desired). If I want to see the mobile version (for some reason) I can just switch Dolphin HD back to Android mode (user agent string) and then I get the mobile version.
Hope this helps someone. Sorry it was so long -- almost everything I write up is.
P.S. If you do this successfully on a non-Motorola phone, post here and let others know.
firstly,, BIG THANKS
I am running a GB2.3.3build.596 P3D 2file root DroidX..
when i open ROOT EXPLORER in r/w mount and open the build.prop i can not type anything..and this mobile site only crap was the reason i took 2 days of forum reading at 3 forums before i went ahead and sbf'd back to froyo from a stock Verz 2.3.3GB to then root ,and then to install the 2 P3D files to have a .596 build GB rooted phone
any suggestions, maybe another editor ware? total newb
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.