Database Info

[Q] Disabling Android 2.2 DropBoxManager

Good Day Folks.
I'm a Noob in need of help and i'm hoping the more experienced among us might be able to assist. I have an issue with disappearing phone storage. Over the course of a week I realized that I was losing about 1MB a day. My phone would basically be dormant and I would still see my storage space dropping by this amount everyday.
Cache cleaning didn't work. Later I realized that Android creates a bunch of log files in Data/System/Dropbox that was responsible for the disappearing phone storage trick I've been seeing for a while now.
I know now that Google has incorporated into Android as of the 2.2 iteration, a DropBox Manager that's responsible for logging all of the events that take place during the course of a running Android session. Everything from what took place at boot to force close details.
I understand that this is used for debugging purposes but I'm no developer . So my question is.... Can this DropBox Manager be disabled....somehow.
I really don't need all these files (and its A LOT OF THEM) being created as they serve no practical purpose for me. Not sure if anyone else might have noticed this but I'm hoping to receive some help. Even if it means pointing me in the right direction so I can work on it myself.
I really don't have a clue on how to start. Any help will be appreciated....Seriously...
Currently using G1 with CM6 Magpie running on EZTERRY's 2.6.34.7 kernel.
Its perfect except for this annoying problem.......

Hm what happens if you rename the directory. It might throw some errors in the logger, but probably won't create anymore files.
I just deleted the content of my dropbox folder, the DropboxManagerService was throwing some errors that he could not open files, but the phone was fine, no FCs or anything.

Renaming the directory just results in a random reboot. My guess is that when Android tries to create a new log, its unable to find the directory and then it just freezes and after a while it reboots. Once restarted it just reappears... I've tried that too.
And its true.. Its ok to delete the files. Its what I do currently. All of those files in Data/System/Dropbox as well as the ones located in Data/Tombstones are ok to delete. As I said, its just used for debugging purposes. Whats really annoying though is that, no matter how many times you delete anything, they just get repopulated just as fast as they're deleted. I'm ok with micro-managing my memory and phone storage (its a G1 after all) but this is ridiculous. It just creates too many of these log files too quickly.
If there was a way to turn the DropBoxManager service off then that would be the end of it all.
What's unusual about it too is that in my particular case, the contents of these text files just have two things listed in them. Pertaining to my online accounts associated with the phone: My Google account and My Whatsapp account...
It just repeats the same thing over and over again. I'm starting to think that the event data might actually be synchronization data or at least synchronization attempts made at regular intervals. But ultimately i'm guessing....
I really don't have a clue... Have you ever heard of anything like this on XDA......possible resolutions of this issue?

epolaris said:
I really don't have a clue... Have you ever heard of anything like this on XDA......possible resolutions of this issue?
Click to expand...
Click to collapse
Not yet .
What about replacing the folder by a symlink to /dev/null ?
You could also try to change permission on the folder.

Ok... I'm a real Noob but I'll take a shot.. When you say symlink what do you mean.
I'm not really familiar with Android at that level yet its really just flashing and such.
But I know a symlink is really just a reference to a location that the OS would interpret and follow (like a pointer i think). So, is it that you're suggesting some sort of redirection where the Data/System/Dropbox directory is pointed to another arbitrary location. Kind of like a creating a dead link that Android is unable to follow up on. Or maybe, redirecting the folder to an entirely new location that Android would then follow. I'm not sure... How do you perform a symlink in Android... I'm willing to try.

You can do it with a console on the phone it self or using adb shell. You need root of course.
You could make a link to another location where you have more space?
Or you change to permissions of that directory to write only.
Or you can mount a different file system to that directory that is read only.
On how to do that just google a bit for linux tutorials on that topic.
I have just googled a bit and it seems you can't symlink directories to /dev/null.
If all that doesnt help post again, there might be an option to make an app delete the files automaticly, first time they get created.
If that would be an option too let me know, im in the mood to program something intresting .

Disabling Android 2.2 DropboxManager [RESOLVED]
I took your advice and did the research you suggested and it worked.
The first thing I tried was changing the permissions on the "Data/System/Dropbox" directory and it worked. But I didn't use CHMOD and console command line to do it.
I have a program called Root Explorer that allows me to permanently change the permissions on any file or folder I select. I set all of the offending folders to read only and the log files stopped being written to those folders.
These are the directories I set to read only:
1. "Data/System/Dropbox"
2. "Data/System/UsageStats"
3. "Data/Tombstones"
Since changing the permissions on these folders my phone storage has stopped dwindling out of control. No additional programming necessary
Disabling the DropBoxMangerService itself is not necessary which is good.
I'm going to take your advice and read up some more on Linux commands (specifically Ubuntu as its what I currently use).
You have been very helpful, thanks for the advice. If you have any ideas about Froyo ROMS (Maybe even Gingerbread ) I should try let me know.
Thanks again....

I have also found these files. They can take MUCH space in memory and nothing seems to delete them. I made the dropbox system folder RO but I think this is a bug. It should be reported to the dropbox team. Is there a bug report form somewhere? I did not find it... Just found the forum, QA,...
[edit]I reported it in the forum... Just see http://forums.dropbox.com/topic.php?id=41227 [/edit]

vax said:
I have also found these files. They can take MUCH space in memory and nothing seems to delete them. I made the dropbox system folder RO but I think this is a bug. It should be reported to the dropbox team. Is there a bug report form somewhere? I did not find it... Just found the forum, QA,...
[edit]I reported it in the forum... Just see http://forums.dropbox.com/topic.php?id=41227 [/edit]
Click to expand...
Click to collapse
You are mistaken: /data/system/dropbox, has NOTHING todo with www.dropbox.com !
See http://developer.android.com/reference/android/os/DropBoxManager.html

Dark3n said:
You are mistaken: /data/system/dropbox, has NOTHING todo with www.dropbox.com !
See http://developer.android.com/reference/android/os/DropBoxManager.html
Click to expand...
Click to collapse
Hey, just looked at your SD Maid app (looks cool).
So what do you know about /data/system/dropbox? I just read that htc uses the dir to store phone events which is then sent to the htc cloud of spying-on-your-ass. But since non-htc phones have this dir, is htc merely misusing the directory and it has other legit uses, or is this a directory we should try to keep cleaned out?
(I like the idea of changing perms so nothing writes to it if that's the case.)

600 MB additional free storage
Hi all
Just found a smart way to increase your Dropbox account with 600 MB:
1 Sign into your existing Dropbox account (or create a new account)
2 Goto https://www.dropbox.com/free
3 Follow instructions ... and voila 600 MB additional free storage

Mittaa said:
Hi all
Just found a smart way to increase your Dropbox account with 600 MB:
1 Sign into your existing Dropbox account (or create a new account)
2 Goto https://www.dropbox.com/free
3 Follow instructions ... and voila 600 MB additional free storage
Click to expand...
Click to collapse
Yay, nice to see you didn't read the thread at all.
This has nothing todo with dropbox.com

Yea other day I got the SD Maid, and the Pro version after I saw how handy it was. I too on my G1 (with 2.2) see that dropbox folder.. and lately Ive been thinking its causing my G1 to constantly reboot. When I look, it has 300+ files in it. So I clear that folder and seems to stop rebooting for a lil while.
Not sure what the deal is here however, been trying to find out. HOWEVER it only seems to reboot once its connected to the internet, so I am wondering if this is where it tries to upload and so. Not really sure. That and its hard to tell in logcat whats going on before it reboots.

Thanks
Excellent information. This works on my Sony Ericsson Xperia Pro MK16a, Rooted. Thank you so much. My best regards.

Try to change the permisions of the folder, I'm not sure if it would work but you could try ^^
Sent from my GT-I9001 using xda premium

All is ok
All was fine. The permissions :laugh:changed with root explorer. Thank you so much

Note completely disabled but only 1 file in the /data/system/dropbox folder with these Android shell commands (or use Sqlite3 editor):
content insert --uri content://settings/secure --bind name:s:dropbox_max_files --bind value:i:1
Or for Android 4.2+
content insert --uri content://settings/global --bind name:s:dropbox_max_files --bind value:i:1
settings put global dropbox_max_files 1
Reboot.
more dropboxmanager settings:
dropbox_age_seconds
dropbox_max_files
dropbox_quota_kb
dropbox_quota_percent
dropbox_reserve_percent

I've been using the advice from this thread to control this "dropbox" data collection directory for several years now until I updated to 9.0 and found that the folder and default permissions were restored after every reboot. Was irritating bc I can use root to modify /system but no longer have control over my own data partition Something is over-riding my root-user!!!
I tried different apps, TWRP's FM, adb, and almost gave up when init.d scripts wouldn't work either. init.d will work tho. A simple script to run
Code:
#!/system/xbin/sh
busybox rm -f /data/system/dropbox
at boot. You can probably chown and chmod if you want but I just deleted it. Just put it in your init.d folder and make sure you give it the correct permissions (root:shell -755), then immediately perform a soft reboot. Use hardware keys if you have to. You want the phone to go immediately OFF, no spinny wheels or "powering off" notifications. That's the only way I could get rid of the damn thing.
Anyway, I came across this thread while searching for a solution and thought I would add this in case any other paranoids like me are concerned about this mysterious "dropbox" directory. This will probably break any ability for google to troubleshoot your phone but I don't think that's real anyway. It's just spyware as far as I'm concerned.
p.s. (off-topic) Thanks @Dark3n I'm also a frequent SD Maid user btw and in case you happen to read this, I thought I might mention I intended to send a donation via your app the other day (i like to show love when ppl share badass works) but balked at the only available option for "pizza," not bc I don't appreciate it that much but I can afford a little every now and then. If you add a smaller option, "coffee" or beer or whatever, maybe even an outside of googlePlay option, BTC perhaps. I'd be happy to shoot a few dollars at you.

My GPS Improvements for CM7

CM7 has made a few strides in improving GPS accuracy and lock time, with improved coding and additions like the SuplRootCert, but by itself has a ways to go.
Here are three changes/additions I've made that have vastly improved my GPS response/accuracy time from anywhere between near instant to less than 20 second locks, both of which are good because with GPS so many variables factor in (weather, time of day, city/rural area, # of satellites above you at the given time) we can't expect "INSTA-LOCKS" every time. That's absurd.
Everyone's mileage will vary, and none of these should be particularly foreign if you've searched GPS fixes before. I've basically streamlined all my research into one thread only using what has been found to be the most useful. You will need root access for first two suggestions.
1. Modify the system/build.prop file to include stock ROM coding that is relevant to GPS.
Add the following lines to the build.prop:
Code:
ro.com.google.clientidbase.ms=android-hms-tmobile-us
ro.com.google.clientidbase.gmm=android-lge
ro.com.google.clientidbase.yt=android-lge
ro.com.google.clientidbase.am=android-tmobile-us
ro.ril.def.agps.feature=1
ro.ril.gprsclass=10
Change the following line from this:
Code:
ro.com.google.clientidbase=android-google
to this:
Code:
ro.com.google.clientidbase=android-lge
You can add these at the end of the build.prop so you know where you have placed them should you need to revert. Making these changes will also allow you to get the free T-Mobile tracks in Google Music since the phone is now recognized as a T-Mobile phone. The Market picks up on this and changes accordingly.
2. Modify the system/etc/gps.conf file.
Add the following lines:
Code:
NTP_SERVER=0.north-america.pool.ntp.org
NTP_SERVER=1.north-america.pool.ntp.org
NTP_SERVER=2.north-america.pool.ntp.org
NTP_SERVER=3.north-america.pool.ntp.org
NTP_SERVER=0.us.pool.ntp.org
NTP_SERVER=1.us.pool.ntp.org
NTP_SERVER=2.us.pool.ntp.org
NTP_SERVER=3.us.pool.ntp.org
So that your gps.conf now looks like this:
Code:
NTP_SERVER=north-america.pool.ntp.org
[B]NTP_SERVER=0.north-america.pool.ntp.org
NTP_SERVER=1.north-america.pool.ntp.org
NTP_SERVER=2.north-america.pool.ntp.org
NTP_SERVER=3.north-america.pool.ntp.org
NTP_SERVER=0.us.pool.ntp.org
NTP_SERVER=1.us.pool.ntp.org
NTP_SERVER=2.us.pool.ntp.org
NTP_SERVER=3.us.pool.ntp.org[/B]
XTRA_SERVER_1=http://xtra1.gpsonextra.net/xtra.bin
XTRA_SERVER_2=http://xtra2.gpsonextra.net/xtra.bin
XTRA_SERVER_3=http://xtra3.gpsonextra.net/xtra.bin
There are obviously more lines in CM7's gps.conf but I'm simply showing the common placement of the additional lines and where to sandwich them in. Believe me when I say these additional servers do make a difference.
3. Use GPS Status to download the most recent AGPS data.
You might be wondering what was the point of making all of those changes if you're just going to have to download an app to improve your GPS, but GPS Status really is the icing on the cake. I've used GPS Status exclusively as well as just the Steps 1 and 2 exclusively and alone you see minor improvements, but it is in tandem that everything comes together.
We want GPS Status to have it download the latest AGPS data for us. AGPS data essentially tells the GPS where to look for the satellites so that our lock on can be as quick as possible.
Before I am about to use a GPS-related app like Google Maps or Google+ for checking-in, I simply open GPS Status, give it a second and allow it to download the most recent AGPS data, and close it. That's it!
You can also change in GPS Status' settings how often you'd like it to download the AGPS data when you open the app. I have mine set to 1 hour.
Thanks to erikikaz and nrvnqsrxk for your previous work and reference points.

This needs a good bump..
Worked for me..
Before without data or wifi, it takes around 3minutes to lock.
With this it takes around 20-45 esconds to lock.
- Using copilot live

Just gave this a try, will post back with results. Thanks!

After using these tweaks I can finally get fairly quick sat locks in the GPS status app, unfortunately my actual Google Maps app seems to never get a decent lock in most locations still, but it is still an improvement.

Oh btw, I skipped step 3.
In my house, I get a 1minute lock with NO data.
Outside I get around a 30second lock average with NO data.
With data it's a lot faster.

Is there any way someone can make an .apk or flashable .zip for the first two steps? What's the fastest way to modify those files?

mcs6 said:
Is there any way someone can make an .apk or flashable .zip for the first two steps? What's the fastest way to modify those files?
Click to expand...
Click to collapse
Use Root Explorer, easiest way.

[Q] Has anyone played with the Android L battery-historian tool?

FYI, I don't have a Nexus 5, but I've been following the Android L news for the past few weeks and have yet to see any reports on the battery historian developer tool. I'm really curious to see detailed battery usage reports for apps that are known to cause frequent wakeups from deep sleep (e.g. facebook). From what I can tell, you need 3 things to use this tool:
1.) adb
2.) The actual Python script: https://raw.githubusercontent.com/google/battery-historian/master/historian.py (just right-click and "Save as" to the directory from which you run 'adb')
3.) Also need to install Python 2.7 on your system (for Window users): https://www.python.org/download/
4.) Obviously, a browser to view the generated html.
There are some comments at the beginning of historian.py script that describe how to generate the required data with adb. Note for Windows users: open up the file in Wordpad, not Notepad.
Also for Windows users: assuming you have installed Python 2.7 in c:\Python27, use the following command line to run the script:
c:\Python27\python.exe historian.py [OPTIONS] [FILE]
Also note that this tool is NOT part of the built-in Android battery settings/stats and there is no native Android UI for it. It is meant to be a developer tool. However, this doesn't mean that users with access to 'adb' can't play with it...

I manage to get this work...even i have no idea about development...
First it need python 2.7 not 3.4
After that you have to mix some commands from the OT and the info inside the .py file...so what i do
After installing python 2.7 i use the command to get a bugreport from the phone...
Code:
adb bugreport > bugreport.txt
then i use the OT command to make the bugreport to an html file with a bit of change
Code:
c:\Python27\python.exe historian.py -a bugreport.txt > battery.html
Thats it...now..i don't know if it has the correct data...im just achived the html look of what we saw on I/O
I think first you need to use this command
Code:
adb shell dumpsys batterystats --enable full-wake-history
To let the phone start dumping stats...and then after some use time to gather the bugreport from your phone....anyone with better knowlage im sure it will figure it out!!!
On the attachment i use the command
Code:
adb shell dumpsys batterystats --reset
to reset my values cause im not using my L rom...
Oh btw this will work only on L....

I can't use "--enable" option.
I can't use this command.
Code:
adb shell dumpsys batterystats --enable full-wake-history
Please tell me how to use "--enable" option.
My phone is Android4.4.2.
("--enable" option is Android "L" only ??)

k-matoo777 said:
I can't use this command.
Code:
adb shell dumpsys batterystats --enable full-wake-history
Please tell me how to use "--enable" option.
My phone is Android4.4.2.
("--enable" option is Android "L" only ??)
Click to expand...
Click to collapse
This is only for Android L.

thomase00 said:
This is only for Android L.
Click to expand...
Click to collapse
How is it that we are a month after Google I/O, and no one with Android L has played with this yet?
IMHO, this is one of the most important new features.

Yep, i think this is the most recent problems the two guys from project Volta have. They have to be rely on the help of the programmers which develop the software.

Daimonion1980 said:
Yep, i think this is the most recent problems the two guys from project Volta have. They have to be rely on the help of the programmers which develop the software.
Click to expand...
Click to collapse
They have to rely on Developer to use JobScheduler API but not for finding you bad apps that are killing the battery. And to that effect, those guys are doing a terrible job with a botched tool.
It's amazing how there is NOTHING on the Internet about the Battery Historian tool. It's like no one has used it. In my case, I can't get the command to builds the html file from the bugreport. It keeps giving me a invalid html error.

Yep, I did ask chamonix from BBS if he can use the generated stats and he will take a look into it. I hope he will do it in the near future.

Using battery historian
After playing with this for a while I've figured out how to use the basic function (this is part of project volta, so it will only work on Android 5.0+)
enable full wake history and then output your batterystats to a text file
./adb shell dumpsys batterystats --enable full-wake-history
./adb shell dumpsys batterystats > batterystats.txt
navigate to wherever you placed historian.py and output the data to a html file (you need python 2.7)
./historian.py [location of batterystats.txt] > batterystats.html
open the batterystats.html file and you're done! For basic use at least. I'm still figuring out the rest myself.

So after having problems on lollipop with mobile radio active bug (https://code.google.com/p/android/i...id&colspec=ID+Type+Status+Owner+Summary+Stars)
i managed to get an dump from battery historian. But at the moment a see not the culprit in my log. The only thing i see is that my device although it was not heavily used this morning has a tons of wakelocks.... and an running par between 10:45 and 10:55 where i don't know it's coming from......
Have a look at it:
http://picture-diamonds.de/private/Thomas/Dumpsys.html
Is anyone able to interpret this chart?

I finally got 5.1 on my Verizon Moto X (1st gen). One of the first things I did was collect battery stats and run Battery Historian 2.0. The following guide was very helpful in getting this set up on Windows 7:
http://ph0b.com/battery-historian-2-0-windows/
Anyway, it turns out that while sitting untouched on my desk at work, the phone pretty consistently wakes up about once per minute (only for a second or 2), with the partial wakelock held by GOOGLE_SERVICES. Most of the time, it seems to be related to location reporting. This doesn't sound like a lot, but I think there is a relatively big cost associated with powering the up and down.
Other than location, the ONLY reason I can think of for waking up the phone periodically is for TCP keep-alive (to keep GCM push notifications working), but once per minute seems kind of excessive even for that. My theory is that there is an app using the Google Play Services Geofencing API, and I just happen to be parked near a geofence boundary. According to my understanding, the Google geofencing service adjusts location polling frequency according to your distance from a geofence. If I am correct, the problem is that it is not smart enough to understand that you are stationary and therefore avoid excessive polling.
I'll try to collect more stats from different locations.
I'm sure this ground has been tread before...

thomase00 said:
I finally got 5.1 on my Verizon Moto X (1st gen). One of the first things I did was collect battery stats and run Battery Historian 2.0. The following guide was very helpful in getting this set up on Windows 7:
http://ph0b.com/battery-historian-2-0-windows/
Anyway, it turns out that while sitting untouched on my desk at work, the phone pretty consistently wakes up about once per minute (only for a second or 2), with the partial wakelock held by GOOGLE_SERVICES. Most of the time, it seems to be related to location reporting. This doesn't sound like a lot, but I think there is a relatively big cost associated with powering the up and down.
Other than location, the ONLY reason I can think of for waking up the phone periodically is for TCP keep-alive (to keep GCM push notifications working), but once per minute seems kind of excessive even for that. My theory is that there is an app using the Google Play Services Geofencing API, and I just happen to be parked near a geofence boundary. According to my understanding, the Google geofencing service adjusts location polling frequency according to your distance from a geofence. If I am correct, the problem is that it is not smart enough to understand that you are stationary and therefore avoid excessive polling.
I'll try to collect more stats from different locations.
I'm sure this ground has been tread before...
Click to expand...
Click to collapse
Thanks for sharing ph0b's work here with Battery Historian.

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

[Root] [HD 10 Suez] Remove parental control applications/restrictions [May 2019]

I've tried to complete this mission a few times, each ending in disaster...until now.
Summary:
The parental control applications too are restrictive. Amazon made some slight changes to the Android code which gave these applications full, and in my opinion unnecessary control of the tablets and the security options. Disabling or uninstalling them can and will eventually cause you to reflash stock firmware. That's because they are labeled as "device/profile owner applications". Located in /data/system is 'device_owner.xml'. That file configures the apps as device/profile owners and doing anything to stop them results in a disaster, often unfixable without reflashing stock. The idea was to trick FireOS by switching device owner applications right from under it's nose. It's not easy but it is possible.
This will be along guide. one or two of these steps may not even be necessary but I am going to present them as I did them and was successful. Beyond that you are free to remove steps and try the process at your will. However any deviation from the guide can result in damage to your device. Even this guide may result in damage to your device, because not everyone's results will be the same. From here on out you are on your own and I am not responsible for any damage done to your devices. This will take some time, if you do not have it it is recommended you do not continue until you do. It will not be possible to pause for extended periods through this guide. This WILL REQUIRE a factory reset. You must be rooted or have an unlocked tablet to complete the guide. You must also have the Google play store and related services installed as system applications in priv-app folder. For this it's recommended to flash a pico Gapps package in TWRP.
THIS OPERATION WAS PERFORMED ON A DEVICE THAT WAS DEODEXED ON 5.6.1.0 WITH A 5.3.6.0 (LATEST FIREOS) BOOT IMAGE. This will not likely work on a stock ROM that has not been deodexed.
Instructions:
1. You need to download an application that uninstalls system applications. Any one of them will do so long as it works. You will absolutely need to download an application that does this. Also download a root file explorer.
2. Uninstall the application called 'Managed provisioning.' then open a shell using a terminal emulator or ADB. Then type the commands below.
Code:
adb shell
su
settings put global device_provisioned 0
3. Go to settings > security > device administrator and make sure Google pay is a device administrator. This is very important and you must not miss this step.
4. Using a root explorer, go to /data/system and copy device_owner.xml to your internal storage. If using your PC please use Notepad++, though it's recommended you complete the following tasks on your device.
4b. Go to system/etc/permissions/ and open handheld_core_hardware.xml in a text editor. Find the line that says: <!-- feature name="android.software.managed_users" --> and replace that line with the one below, save the file and reboot:
Code:
<feature name="android.software.managed_users" />
5. Then go to your internal storage and open the file device_owner.xml in a text editor. Replace the lines of text with the text below, making sure the format is NOT changed from the original and save the file:
Code:
<profile-owner package="com.google.android.gms" name="Google Play services" userId="0" component="com.google.android.gms/com.google.android.gms.mdm.receivers.MdmDeviceAdminReceiver" />
6. NOTE: this step CANNOT be done in TWRP. Again Using a root explorer, copy and paste device_owner.xml to /data/system, overwriting the current one (remember to back up the original). Set permissions to rw (0600) and reboot. If there are no errors or popups and your home and recents button still work after rebooting, continue to the next step.
7. Reboot to recovery and clear/wipe cache and dalvik and reboot system. When booted, if no pop errors from anything, open the uninstaller app you downloaded and uninstall Parental Controls and Parental monitoring. Again reboot to recovery and wipe cache and dalvik and reboot system.
8. Again if no errors, reboot to recovery again and this time do a factory reset. This step is very important and cannot be missed. It is absolutely required that the data be wiped on the device or the device and system will recognize it is no longer owner of said device and it will start shutting you out of security and other options on the device.
9. When rebooted, Open the shell in terminal emulator again or ADB and type the following command below. A reboot should not be necessary when done:
Code:
su
settings put global device_provisioned 1
10. Download an activity launcher (I use activity manager and yes you need to pay a slight fee to use the root part of the launcher, but it's worth it.) Scroll settings and search for 'generic lockscreen set' and long press it to open it with root access. All of your lock screen options should be open and available to you even after removing the parental applications. If they are congratulations you have now remove parental applications and the restrictions that came with them from your device. Go back to /data/system and you will also notice that the device_owner.xml is gone. Killing 2 birds with one stone. If any lockscreen options are blocked then you have failed to properly remove the parental applications and the policies that go along with them.
NOTE: You may need to deactivate 'smart lock' and trusted gms as that may interfere with some lock screen options.
I'll let you guys decide, but I think the device is vastly improved in terms of performance and in Internet connectability after removing these applications.

Edit: forgot a step. Can't believe I did that.
Sent from my Amazon KFSUWI using XDA Labs

I must have goofed. I did a factory reset and now my tablet is back to stock. lol
Edit: I take that back. I tap on parental controls and nothing happens lol
Edit2: Yep It's running good. You were right too. It seems like it runs a lot smoother without amazon's parental controls.

Shadow Death said:
I must have goofed. I did a factory reset and now my tablet is back to stock. lol
Edit: I take that back. I tap on parental controls and nothing happens lol
Edit2: Yep It's running good. You were right too. It seems like it runs a lot smoother without amazon's parental controls.
Click to expand...
Click to collapse
Cuz I'm pretty sure without the support of manage profiles, the parental applications actually cut down on a Wi-Fi speed. I don't think it's cutting short the connection, rather the metrics and scripts associated with other apps and configs, cause it to constantly disconnect and reconnect. also fireOS doesn't like when you have more than one network saved at a time, in the same area. You can also delete etc/wifiloglevels.sh if you are on the deodexed rom. Can also set the value of the line in build prop for wifi rssi levels to ""

Shadow Death said:
I must have goofed. I did a factory reset and now my tablet is back to stock. lol
Edit: I take that back. I tap on parental controls and nothing happens lol
Edit2: Yep It's running good. You were right too. It seems like it runs a lot smoother without amazon's parental controls.
Click to expand...
Click to collapse
Add: you Dan probably reinstall the managed provisioning app. It might let you create a work profile I am not sure. I am going to experiment with that more tomorrow.

I'd like to add that I am on the same battery cycle as the other day when I started this process at 65%. I haven't been as aggressive in my use as much as normal this weekend but I haven't had to put it on the charger all well and usually I have to do that a few times a week if I really use it.

I forgot to mention that step 4 and possibly 5 seem jumbled.

Shadow Death said:
I forgot to mention that step 4 and possibly 5 seem jumbled.
Click to expand...
Click to collapse
Are you using the app?

DragonFire1024 said:
Are you using the app?
Click to expand...
Click to collapse
I'm not sure what app you mean. What I meant was this part:
Using a root explorer, go to /data/system and copy device_owner.xml to your internal storage and open it in a text editor. If using your PC please use Notepad++, though it's recommended you complete the following tasks on your device. Open system/etc/permissions/handheld_core_hardware.xml in a text editor.
Click to expand...
Click to collapse

Shadow Death said:
I'm not sure what app you mean. What I meant was this part:
Click to expand...
Click to collapse
I'll fix it tomorrow. Thanks.

DragonFire1024 said:
I'll fix it tomorrow. Thanks.
Click to expand...
Click to collapse
I figured out what you meant but I thought I would point it out just in case others can't.

Shadow Death said:
I figured out what you meant but I thought I would point it out just in case others can't.
Click to expand...
Click to collapse
Worded it a bit better and broke it apart somewhat. I definitely saw where one would get lost right there. Good eyes!

Hi Dragon Fire,
Is it now working ok? I have the HD8 (7th generation) and would like to eliminate the restrictions of the parental control.

masterted said:
Hi Dragon Fire,
Is it now working ok? I have the HD8 (7th generation) and would like to eliminate the restrictions of the parental control.
Click to expand...
Click to collapse
Every thing is working so far as I can see. There is a slight delay with some apps that require a lock screen be activated for them to work. I use a WiFi app my provider provides and it requires a screen lock. It failed to recognize it at first. Clearing the providers app cache and restarting it worked.
Sent from my Droid RAZR M using XDA Labs

Hi guys, I got a couple questions about this process...
Could someone who did it already check to see if it is possible to change the language of the tablet? On my own tablet, I get a message about parental controls being required, however my own tablet was rooted and debloated a different way last year. In my case, I don't care about changing the language, and I'm totally satisfied with the results I got.
I ask because I'd like to do this "stock Android look & feel" process for a friend (they do not even have an Amazon account, nor want one), but they need to be able to switch language between English and Spanish on a regular basis, and I don't want to mess up their tablet with mods that would prevent this.
Thanks for any insights you guys might have on this... really appreciate the hard work and vast knowledge represented here on XDA.

Kids Dashboard free app and free cloud (Basically you are making dashboard kiosk like small mdm).
PLAY STORE LINK : https://play.google.com/store/apps/details?id=com.tabnova.aidashboard
Cloud Login: https://cloud.kidsdashboard.com
Main site : http://www.kidsdashboard.com/
Complet free app enjoy dont waste money