Related
This should make Android Market work on all Froyo :
1. Get your androidId:
Install Android SDK (Link here)
Launch Android SDK and AVD Manager (tools/android)
Click on Available packages, then select Google APIs by Google Inc., Android API 8 and install it
Click on Virtual devices, then on New..., and select as Target Google APIs (Google Inc.) - API Level 8
Launch your new virtual device (click on Start...)
Login with your Google Account on this virtual device (Go to Settings/Accounts to login)
Enter this command with adb :
adb -e shell sqlite3 /data/data/com.android.providers.settings/databases/settings.db "select value from secure where name='android_id'"
Click to expand...
Click to collapse
This command return your androidId.
2. Set your androidId on your phone :
Set USB Debugging on your phone
Plug your phone to your computer
Pull settings.db :
adb -d shell
su
cp /data/data/com.android.providers.settings/databases/settings.db /sdcard/settings.db
exit
exit
adb -d pull /sdcard/settings.db
Click to expand...
Click to collapse
Set your new androidId :
sqlite3 settings.db "update secure set value='your_android_id' where name='android_id'"
Click to expand...
Click to collapse
Push your new settings.db :
adb -d push settings.db /sdcard/settings.db
adb -d shell
su
cp /sdcard/settings.db /data/data/com.android.providers.settings/databases/settings.db
exit
exit
Click to expand...
Click to collapse
Reboot your phone
Install Market 2.2.11 (You can find the apk here)
Known bugs :
Sometimes the market doesn't work anyway, reboot your phone may solve the problem
I'll try and report back Thanks for your help
I posted this yesterday, for me it unfortunately worked once.
http://forum.xda-developers.com/showpost.php?p=10634550&postcount=371
For me it only works once after reboot. Then download isn`t possible anymore.
But i got my androidid from an old backup where the market was definitly working without problems.
Does the androidid change between 2.1 and 2.2 ?
I don`t think so, but that could be one possibility why it only works once for me.
Do you tried, if it works over some reboots and more than one download ?
It works for more than one download and after download with Market 2.2.11
androidId seems different between eclair and froyo, I got a 19 digits int-value on eclair and a 16 digits hexa-value on froyo.
Ok, thanks.
I also have an int for androidid from my Backup. I will have a test with the hex id and report.
sqlite3 settings.db "update secure set value='my_id' where name='android_id'" returns an error
Can I get the error ? It may help ><
I'm not sure how it sounds in English, but a rough translation from my language is ""sqlite3" is not an internal or external command..."
sqlite3.exe if you're on Windows maybe, but check your PATH variable (sqlite3.exe is in android/tools in the SDK)
You can also set the value with root explorer and sqleditor.
whoa, i now took the value from the virtual device and now after reboot all colors are inverted.
Looks really strange.
After booting into Launcher, colors reverted to original.
But for the moment market seems to work after wiping marketdata and marketcache. Did 3 downloads and all 3 worked as they should. Will have an eye on it and hope it stays working.
But i had a look at my androidid from 2.1. It was also a 16digit hexa. Thougth it would only contain numbers, but also contained letters. Failure by me.
Edit: Same as before. Market stopped working. Every download hangs in status beginning downloading but never starts.
yahoum said:
sqlite3.exe if you're on Windows maybe, but check your PATH variable (sqlite3.exe is in android/tools in the SDK)
Click to expand...
Click to collapse
Copy sqlite3.exe from \tools to \platform-tools. Thanks for advice
Acid_Junk said:
I'm not sure how it sounds in English, but a rough translation from my language is ""sqlite3" is not an internal or external command..."
Click to expand...
Click to collapse
you need to run the command from your ..\androidSDK\tools\ folder on your windows PC...
Worked once - then again market reports that "Download Unsuccessful"
Hi everyone! It's my first post. Did the "Noob video" kind of emerge from a frustration with new users?
Purpose
I want to run the Android Market on Android 2.3 inside the emulator, since I don't want to register a Google account on my phone. I donwload the apps there and transfer them to my phone.
Situation
I successfully set up an AVD with 1.6 and 2.3 where the Market seems to run flawlessly. However, it's not really deterministic what conditions lead to a running Market [1]. I want to be able to make all modifications of the SDK images and APKs myself in order to run the market. I consulted several guides already [2]:
Varun's How to: Install Android market on Emulator <hxxp://blog.varunkumar.me/2010/11/how-to-install-android-market-in-google.html>
Anything simple: How to use Android Market on Android Emulator 2.2 <hxxp://anythingsimple.blogspot.com/2010/09/how-to-use-android-market-on-android.html>
Tech-Recipes: How Do I Install the Android Market on Android SDK <hxxp://w#w.tech-recipes.com/rx/10004/accessing-android-market-from-android-sdk/>
CareAce: How to fix "protected" Android Market app <hxxp://w#w.careace.net/2010/06/16/how-to-fix-protected-android-market-app/>
All files I used are provided.
What I did
I followed the guide by Varun and it worked quite well, but it really worked only after I changed ro.secure=1 and ro.allow.mock.location=0 in default.prop (located in ramdisk.img).
Create a new AVD. Config.ini:
Code:
hw.lcd.density=160
hw.gps=yes
hw.camera=yes
hw.ramSize=256
sdcard.size=256M
Edit build.prop (see attachment, original values are commented with ###)
Install Vending.apk and GoogleServicesFramework.apk
Delete SdkSetup.apk
ro.secure=1 and ro.allow.mock.location=0
When using GSF provided by Varun, the Market runs fine. When I use the GSF from my phone, it doesn't work. So, my two questions:
What exactly does a running market depend on? (Only fingerprint and gsf?)
Is the GSF by Varun the original or a patched variant?
How could my version of the GSF be modified to work?
Attachments
CRC32 values are in parantheses.
com.android.vending.apk (6502c750)
Original Market v2.3.6 as downloaded by the Market Updater
Vending_Adi.apk (a51aa807)
Above patched on byte basis [3] (no re-assembling, modification directly in classes.dex for minimal deviation from original).
Installed on my working AVD.
GoogleServicesFramework_htc.apk (3f770666)
Version 2.2.1
I pulled this file from my HTC Desire Z with Android 2.2.1
GoogleServicesFramework_varun.apk (6b3ea386)
Version 2.2
Available from Varun's guide
[1] A non-running Market only shows TerraTime on the home screen and games like PapiWall and PapiStep.
[2] Sorry for the obfuscation of the links. It's because this is my first post.
[3] I will explain every modification in detail, if asked for.
I've been trying to get the market working on the emulator "properly" for days.
Can you find protected apps such as g-mon or dr droid?
If yes PLEASE can you post a detailed howto?
It could be that they fixed it with the latest packages, judging from comments on some blog entries on the subject, so don't update your SDK before making a backup!
Thanks in advance,
- MF
How did u change "ro.secure=1 and ro.allow.mock.location=0" ?
MFighter said:
Can you find protected apps such as g-mon or dr droid?
If yes PLEASE can you post a detailed howto?
Click to expand...
Click to collapse
Edit build.prop in "system.img" before running emulator.
1) copy "%SDK%\platforms\android-10\images\system.img" "%userprofile%\.android\avd\%AVD%.avd\system.img"
2) open this file with binary file editor,
3) search "# begin build properties" or "23 20 62 65 67 69 6E 20 62 75 69 6C 64 20 70 72",
4) rewrite build.prop's content with real device's.
mrawekul said:
Edit build.prop in "system.img" before running emulator.
1) copy "%SDK%\platforms\android-10\images\system.img" "%userprofile%\.android\avd\%AVD%.avd\system.img"
2) open this file with binary file editor,
3) search "# begin build properties" or "23 20 62 65 67 69 6E 20 62 75 69 6C 64 20 70 72",
4) rewrite build.prop's content with real device's.
Click to expand...
Click to collapse
Don't suppose you would be willing to share your system.img file. I understand most of this but I tried to edit the system.img with no success. And there is no ramdisk.img in the avd folder. Can you help me out? I've tried everything. All I want to do is be able to download apps from the market so I can install on my tablet which is a Pandigital Planet and some of the apps don't show up on the market.
Persisting system.img and trying to make Android Market application to work
Actually, there is a way to persist system partition.
Built-in command line help shows that there is an optional persistent system-qemu.img. If it worked, all the hoops below would be not necessary.
If it try to create system-qemu.img in .avd directory as a copy of system.img from one the platforms in the SDK, emulator fails with an error
Code:
ko:Missing initial system image path!
. My guess is that emulator was deliberately crippled to not support persistent /system partition out of the box. If someone has a method to make system-qemu.img to actually work, please post.
I quickly looked through the emulator sources, the patch to enable system-qemu.img would be a pretty easy task for someone who has built android emulator from sources at least once. Any volunteers?
Read on for a hack to get system-qemu.img functionality.
When emulator starts, it creates a copy of system.img in %temp%/AndroidEmulator with some random name like TMP9323.tmp. If you do
Code:
adb -e remount
to mount /system as rw, you will get the writable system, but with an empty free space. Everything you do to /system is saved into this .tmp file.
The next trick is to start emulator instance with more virtual sectors than there are actually are in the stock system.img. You do that by starting emulator with the aptly named emulator command like so
Code:
emulator @AvdName -partition-size 256
If look later at free space with df, you will get something like this
Code:
adb -e shell df
Filesystem Size Used Free Blksize
/dev 252M 32K 252M 4096
/mnt/asec 252M 0K 252M 4096
/mnt/obb 252M 0K 252M 4096
/system 248M 96M 151M 4096
/data 248M 34M 213M 4096
/cache 64M 1M 62M 4096
/mnt/sdcard 252M 1K 252M 512
/mnt/secure/asec 252M 1K 252M 512
Note that you now have some free space in /system.
Later you do
Code:
adb remount
from your host shell. This is essentially the same as running
Code:
#mount -o remount,rw /dev/block/mtdblock0 /system
from emulator shell.
Now you get the fully writable /system filesystem. You can copy with
Code:
adb push
any files you like into the /system and they will be successfully written.
After you are happy with your new /system, from
Code:
adb -e shell
you sync filesystems and make system read-only:
Code:
#sync
#mount -o remount,ro /dev/block/mtdblock0 /system
After that you can hot copy the .tmp to some other place and close the emulator with an [x] button from the window title bar. I do not use snapshots, so closing emulator is akin to removing the battery from a real device.
And using snapshots to get a "persistent" /system is impossible without rebooting. Currently it is not possible to shutdown via emulated power button (F7). The emulator manual says just to close the emulator window. If you do that with snapshots enabled, you will get into the state you were when you closed the window. Also it is not possible to reboot, as there are no documented way to reset the virtual processor. The reboot command does not work. It just hangs the emulator-arm.exe with 100% use of the CPU core it happens to run on. That is another observation for emulator was deliberately crippled or not developed to a point when resetting the virtual processor is possible.
Later you put your .tmp file into your .avd directory with a name of system.img. And when you start your emulator (even from AVD Manager GUI) you will get your new /system.
If you later need to make some modification to /system, you need to go through all the steps again.
When starting emulator with a new /system for the first time, I recommend to check "Wipe user data" to recreate the file and directory structure in the /data partition, especially if you pushed new .apk files into /system/app or pushed some other system wide components like .jar (framework) or .so (library) files.
Wiping a /data partition can be a lengthy process because it leads to recreation of dalvik-cache, the most CPU demanding process. In most cases, you can avoid the /data wipe. But if you push Google Apps to a pristine AVD, you should do a wipe so that Google initialization program with "Touch Droid to begin" kicks in. It is a first step screen the user sees at least on a real, Google "enhanced" device based on Android 2.3.
You can even observe how userdata-qemu.img file gets bigger as dalvik-cache and other parts of /data get populated. You may even use the
Code:
top
command to see the processes on the emulated device.
If you are running emulator from the command line you can add -wipe-data option to wipe the /data partition.
Optionally you can remove cache.img from .avd directory to clear the cache. cache.img will be recreated from scratch in this case.
After all these manipulations, the only way to launch AVD would be from command line as -partition-size 256 must be specified every time, otherwise you will get a kernel panic when mounting the /system partition.
The GUI option "Ideal size of system partition" is actually ignored. Its value is not copied into hardware-qemu.ini from config.ini, but stays at the size of initial system.img. Just another observation that emulator was deliberately crippled.
If emulator hangs with textual (not graphical) "A N D R O I D" on its screen, it is likely that the new system.img is corrupted and/or the partition size of 256MB has not been specified for not stock system.img. You can verify this by launching AVD from the command line with -show-kernel option to get all the kernel output in real time. You will likely find a kernel panic there.
If emulator hangs with a graphical ANDROID animation (aka boot loop), you can use
Code:
adb -e logcat
tool to look for any errors in the start up process. Examples below.
But that was an easy part. Now we need to install Vending.apk and its dependencies.
As my goal is Android 2.3.3, as it is a close to current majority of real devices as it can be. I tried to work with the version of Google Apps for CyanogenMod. I own an HTC Desire with CyanogneMod 7.1-nightly. I downloaded the initial gapps-gb-20110828-signed.zip from the link in CM wiki. This .zip, when flashed through recovery works without any issues on CM. Also I pulled from HTC Desire an updated Android Market .apk. Also I generated a demo app which shows a text edit and a button, but does nothing just to check that .apks can be installed both as system and 3rd party apps.
Here is what I tried.
0. Started with a Google API (API Level 10) emulator images. Pushed unpacked gapps. Everything worked: initial Google account registration, Talk, Maps, Latitude, Navigaton, Places, News and Weather (widget + app), Search (including widget). But not Market. There were no icon for it. Fail.
1. Started with Android 2.3.3 (API Level 10) emulator images. Pushed unpacked gapps. Got a boot loop with an exception in logcat related to contacts migration/upgrade. Strange, Google API 10 image may have something that plain image does not have. Fail.
2. Started with Android 2.3.3 (API Level 10) emulator images. Pushed upgraded Vending.apk to /system/app. No Market icon after a reset. Even with data wipe. Fail.
3. Started with a Google API (API Level 10) emulator images. Tried to install through adb the latest Vending.apk as a third-party app. adb install failed with "INSTALL_FAILED_ALREADY_EXISTS". Fail.
4. Started with a Google API (API Level 10) emulator images. Deleted /system/app/SdkSetup.apk. Tried to install latest Vending.apk with adb. Same result as in 3. Fail.
5. Started with a Google API (API Level 10) emulator images. Deleted /system/app/SdkSetup.apk. Pushed latest Vending.apk to /system/app. After reboot no icon. Also pushed own app, it got the icon. Vending.apk got no entry in /data/dalvik-cache, but demo app got it. Something prevents the Vending.apk to be recognized as a valid app. Fail.
6. Same as 5, but pushed not as Vending.apk, but as foobar.apk. Same result. No icon after reboot, no entry in dalvik-cache. Fail.
Spent the last 4 hours for figuring out the method for /system persistence and Vending.apk experiments.
Some possible reasons for Market Application to not show up in dalvik cache and no icon in launcher application list:
1. Some metadata in .apk prevents it from being processed. SDK level?
2. Crypto keys mismatch. Firmware signing keys != .apk signing keys.
3. Apk contents conflict with something existing in the firmware. (INSTALL_FAILED_ALREADY_EXISTS).
4. Permission issues.
5. System image configuration variables like ro.secure and ro.allow.mock.location.
The next step for me would be to read 3 books:
1. Learning Android.
2. Application Security for the Android Platform
3. Android Forensics: Investigation, Analysis and Mobile Security for Google Android
As I plan to fork or contribute to pffmod (http://forum.xda-developers.com/showthread.php?t=996726), I had to read them anyway.
If someone has a working method to put recent Android Market into Android 2.3.3 (API level 10) or Google API (API level 10) emulator images, please post.
nice information M4rketSqueezer and geckoneer! may be try to change the property ro.config.nocheckin=yes? i have 2.1 emulator with market now..same method as M4rketSqueezer
I don't have my device yet and want to take advantage of what few apps are still 49 cents.
I've been trying to follow this method today and when I get to the pulling build.prop part I get a cmd error saying adb is not recognized as an internal or external command.
I'm not sure what I did wrong :\
I've download the image referenced in this article at techdroid.kbeanie.com/2011/01/android-market-on-emulator-22.html. This post is merely for 2.2, but I managed to extract their googleservicesframework.apk and vending.apk from inside the image(using adb pull while the emulator is running). I then created a normal 2.3 AVD, started it from the command line with -partition-size 100, pushed the pak files I just extracted from 2.2, and followed geckoneer's hints for getting the system image that contained the pushed apk files. Now having that image with the market apk files, I ran that image inside the emulator and got the market running successfully. Once you start the market for the first time it'll run you through the google account registration wizard. Once you complete with an account, you'll have the market running and I tried searching and downloading applications from it. I've attached the two apk files for convenience.
Two points are noteworthy here: I had to change /system/build.prop inside the system image to one of the real supported models in google market at support.google.com/googleplay/bin/answer.py?hl=en&answer=1727131. I extracted the file from my mobile which was Samsung galaxy mini GT-S5570. I had to replace some of the values(especially those related to the model and manufacturer) in build.prop inside the emulator with those from my mobile.
The second point is that, after I exit the market(with several back-button presses till I get to the home screen) or restart the emulator. It seems the market isn't working properly. By working properly I mean that when I search for something in the search box, it just reports the number of matched results it found for my search(like saying 543 matches or so), without actually displaying the result. So far the only fix I managed to find to this was by restarting the emulator from the command line with -wipe-data; this repeats the google account registration process when I try to run the market again, and it's once again running effectively just after the registration, but it'll get crippled soon if I exit it or restart the emulator. This seems like an annoyance, but other than that the image works fine.
Current as of March 29, 2018.
I've been saving this for a rainy day and it's raining at my house today I have been with XDA for about a year and a half now. I made a list of several goals I wanted to accomplish, mainly to do so without root. Though I have been successful at many tricks and hacks on these tablets WITHOUT root, sometimes, no matter how hard you try, some things can't currently be done without it. One of the goals I set was activating Android's stock Daydream screensaver. This is something that was built into Android and is a feature that is greatly underappreciated and many people just don't know it exists. It's also a feature Amazon blocks us from using. Another goal was to find a way to change the lock screen wallpapers after you got rid of Amazon Photos.
After several weeks of reading and researching, I finally discovered a working way to edit the framework and successfully install it back onto at least two of the Amazon tablets I own. In doing so I discovered how Amazon blocks the use of certain features and settings and in some cases, have been able to reverse their code and replace it with values that activate those things. As you can see in the screenshot below, the Daydream screensaver feature is installed onto the tablet. Using Activity Launcher, tap the top left pull down menu and select 'all activities. Scroll until you see the settings option and tap it. Then scroll until you see 'Daydream'. That's as far as you can go. If you tap it, the display settings is what pops up. Furthermore, if you disable or delete Amazon Photos, and you're stuck with their lock screen wallpapers for the rest of time, until now.
{
"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"
}
In this case the settings don't redirect to another app like setting your lock screen wallpapers, which until now, required Amazon Photos to change. They simply take advantage of the framework, and block the use of the Daydream function through settings within it. That setting, among many more settings, are all allowed to be blocked and are options Android provides to manufacturers and service providers when they purchase the rights to a copy of an Android OS.
Today I am proud and very happy to announce through modding the FireOS framework on the Fire 7 and HD 10, I have successfully activated Android's stock Daydream screensaver, while at the same time, not destroying the fabric of FireOS. I have also found a way for you to once and for all, change your lock screen wallpapers WITHOUT the use of Amazon Photos.
In this TWO PART guide, I'll show you how to enable the use of the Daydream screensaver, install the 'Colors' add-on and show you how to change your lock screen wallpapers. The best part about Daydream, I have been able to track down the proper APK for Android's stock 'Colors' screensaver, also known as 'BasicDreams' and as you can see in the screenshot below, it surprisingly worked on both the Fire 7 and HD 8
The hardest part of all this, once Daydream was activated, was finding the proper APK to get this working. It took me about a week or more to track down the closest version of the 'BasicDreams' APK for our version of Lollipop and I provide it to you today as well. Follow the guide below on how to get Daydream activated and in part two, learn how to change your lock screen wallpapers WITHOUT the use of Amazon Photos.
*****WARNING*****
Editing or modifying the system framework can be very damaging to your device. I have spent an extensive amount of time studying it and ways to edit it. I am writing this guide now because I believe this method is the safest way to edit the framework without damaging your tablet. With that said, your results might not be the same. As such, from this point forward in this guide, I cannot be responsible for any damage that may occur to your device. Please only continue if 1) You are willing to risk a possible brick 2) If you are willing to flash back to the last version of FireOS that your tablet was on in case a brick does occur.
Part 1: Enable 'Daydream' Screensaver
Requirements:
- Rooted Amazon Fire 7 or HD 10.
- Windows PC with ADB installed.
- APKtool (Please note you need to install Java version 7 or greater in order to use APKtool).
- 7-Zip
- Proper 'BasicDreams' screensaver APK, provided at the bottom of this post.
- Notepad++
- ADB insecure
- Patience.
Instructions:
1. On your PC, Download and install 7-Zip, Java (INSTALL JAVA BEFORE YOU INSTALL APKTOOL!!), APKtool and Notepad++ and ADB Insecure, if you haven't done so already, from the links provided above. Download links and install instructions for APKtool can be found here. On your Fire 7 or HD 10, download and install ADB insecure from the link provided above. For APKtool, I recommend you create a folder named 'apktool' in your C:\ directory, as seen in the screenshot below:
2. Once you've installed those two things, plug your tablet into your PC and make sure you have ADB debugging enabled in developer options. (Tap settings, device options, tap serial number 7 times, tap developer opeions and enable ADB). Open an ADB window. We need to get a copy of your framework package by typing the command below into your ADB window and pressing enter. This command assumes you installed APKtool into your C:\ directory:
Code:
adb pull /system/framework/framework-res.apk C:\apktool
3. Now on your PC, you need to navigate to your APKtool folder in C:\. When the window opens, open a command window by holding down shift and right clicking on the APKtool folder window and select 'open command window here'. An example of how that command window would look is posted below:
4. Now we need to install the framework APK into APKtool so it's able to decompile it. In the APKtool command window, type the following command:
Code:
apktool if framework-res.apk
5. Time to decompile the framework so we can look inside of it and make ONLY one edit. Yes that's all it takes is one edit. Amazon only blocks out the Daydream screensaver by using one word. Type the following command in the APKtool window to decompile the framework APK:
Code:
apktool d framework-res.apk
6. Now go back to your APKtool folder on your PC. Another folder should have been created inside the APKtool folder. The folder will be called 'framework-res'. Open up the folder and double click the RES folder. Scroll down until you see the folder named 'values' and double click it. You then should then see a list of XML files, like in the screen shot posted below:
7. Right click on the file named 'bools.xml' and select 'Open with Notepad++'. Slowly scroll the page and look for the configuration setting as seen below. On my Fire 7 the configuration is on line 98:
Code:
<bool name="config_dreamsSupported">false</bool>
8. In the configuration it will say 'false'. Change it to 'true' (no quotation marks) so it looks like this:
Code:
<bool name="config_dreamsSupported">[B]true[/B]</bool>
9. Then save the file by clicking on the floppy disc icon at the top left of Notepad++. DO NOT MAKE ANY OTHER EDITS!! You can now close Notepad++ and open the command window for APKtool again. We have to recompile the framework. Do that by typing the following command into the APKtool command window:
Code:
apktool b framework-res
10. You might get an error or three as the APK recompiles. As long as APKtool builds the APK, ignore the errors. If any pop up during the rebuild process, at most there will be 3 that will say something about an 'ellipsis' and time formatting. They don't mean anything as far as I can tell. If there are more errors which are fatal for the framework APK building, APKtool will not complete the build process. If the build process successful, move onto the next step. Otherwise please repeat the process from step two and make sure you don't edit anything else.
11. Back on your PC, bring up the APKtool folder again. Open the 'framework-res' folder. A few new folders have been created by APKtool. The only one you need to worry about is 'dist'. Double click that folder. This is where APKtool puts rebuilt APKs. Right click on the 'framework-res.apk' file and choose '7-Zip' and 'open archive'. DO NOT CHOOSE UNZIP!!! (Unzipping or decompiling the APK improperly will result in undesirable consequences when you install it back on your tablet.)
12. A 7-Zip window will open up listing a few files. You can make it a little smaller and move it out of the way, but don't minimize it. Back at the APKtool folder (you should still be inside the dist folder), click the back or arrow up button until you are back in the main APKtool folder. Right click your OLD framework-res.apk file and select 7-Zip and 'open archive'. Again do NOT unzip or decompile the APK. You can make the 7-Zip window that opens, smaller if you like, but now make sure the two 7-zip windows are side by side, noting which one is the OLD and which is the NEW archive (the one with 'dist' in the directory is the NEW APK. See below):
13. Highlight the 'res' folder in the 7-Zip window containing the NEW archive. Now drag the 'res' folder from the new archive into the 7-Zip window containing the OLD archive. A window will appear asking if you "really want to copy the folder". Click yes. Now highlight the 'resources.arsc' file in the NEW archive window and then drag it to the OLD archive window and click yes when it asks you if you really want to copy it. You can now close both 7-Zip windows and navigate back to your APKtool window.
14. Now it's time to install the modified framework. Open ADB Insecure if you've already installed it. Grant it SuperUser rights and check the box next to "enable insecure adbd" and open an ADB command window. In order for this next step to be successful, you MUST have insecure adbd enabled. When you're ready, type the command:
Code:
adb remount
15. The window should reply with 'remount succeeded" as seen above. Now we are going to install the framework to the system. Don't worry about setting permissions for the framework. Because we are pushing the framework into the system via ADB and because the framework-res APK was already a system app, ADB will automatically set the proper permissions for the framework APK. This is the moment of truth! Type the following command below (this is assuming you installed APKtool into the C:\ directory). Once installed, within 5-10 seconds some buttons may appear different or be a different color. This is normal and generally signals a successfull installation. If within 5-10 seconds your tablet automatically reboots itself, that generally signals a soft brick. Here we go! Type the commands below, into your ADB command window one at a time:
Code:
adb push C:\apktool\framework-res.apk /system/framework/framework-res.apk
adb reboot
16. If your tablet rebooted successfully, congrats, you just activated Daydreams Before we install the Colors screensaver, go ahead and navigate to your display settings on the tablet. You'll notice a new tile, 'Daydream'. Tap on it and a new window opens. From here you can use the stock desk clock app for the screensaver, install 'Colors' or choose the Amazon screensaver. For Colors: Download the attached BasicDreams APK at the bottom of this post, but do NOT install it. Place the APK into your ADB folder. When done type the following command below. Again no need to worry about setting permissions to the APK as ADB will do it for us:
Code:
adb push BasicDreams.apk /system/app
adb reboot
17. When your tablet reboots, download and install Activity Launcher if you haven't done so already. Tap the pull down at the top left and select all activities. Scroll down until you see SystemUI and tap on it, then tap 'Dessert Case'. To stop the screensaver, tap and pull up near the navigation bar and swipe it closed. Navigate to your display settings again and tap on Daydream. You now have 3 screensavers!!! Tap the three dots at the top right for options on when the screensavers should turn on aka 'daydream'. You can also tap 'start now' to preview them.
So far, these are the only three I have been able to get working. I am still trying to get Photo Table to work, but I am pretty sure Gapps needs to be installed, and I haven't gotten that far to test it. I've tried other screensavers from the Play Store with no luck unfortunately. However if anyone finds anymore working ones, please post your results/finds
Thanks everyone who followed. This makes me quite happy to see this unique feature on these tablets as they are deserving of such a thing. It's disappointing Amazon lets such a great thing go to complete waste. This maybe an old feature, but a very cool and underappreciated one. I hope everyone enjoys this as much as I did unlocking it. I'll be honest; I never thought I would be able to learn basic coding. At least not enough to get this far and accomplish the things I have. Thanks for the support everyone
Watch for part two in the next couple days: Change your lock screen wallpapers...WITHOUT using Amazon photos!!
Part 2: Change your lock screen wallpapers
This guide will teach you how to change all of the stock FireOS wallpapers. This is much easier than activating Daydreams and you don't need Java or Apktool to make the edits.
This guide is mainly for individuals who want to or already disabled/uninstalled Amazon Photos. When you disable or uninstall Amazon Photos, you lose the ability to change your lock screen wallpapers. This guide will work for both the Fire 7 and HD 10.
Requirements:
- ROOTED Fire 7 or HD 10
- 7-Zip
- ADB insecure
- Your choice of any 7 wallpapers
- Windows PC with ADB
Instructions:
IMPORTANT: Make a copy of your SystemUI.apk at /system/priv-app/SystemUI and place it somewhere on your PC in case you have an unfavorable result, you won't have to reset your device.
1. Download and install 7-zip.
2. First we need to get a copy of your SystemUI. Plug your tablet into your PC, making sure ADB debugging is enabled in the developers menu. Open an ADB window on your PC and type the command below (the actions of moving the SystemUi.apk around should only be done via ADB. Never copy and past an APK from one device to another if you intend on editing it.)
Code:
adb pull /system/priv-app/SystemUI/SystemUI.apk
3. Running the above command will have resulted in making a copy of your SystemUI.apk and then placed it on your PC, into the same folder as ADB.
4. Create a folder on your desktop for the 7 wallpapers you desire. You can pick 7 different ones, or use the same wallpaper 7 times, but you can't choose any more or any less of a quantity. Putting anymore or less in the SystemUI will cause the tablet to bootloop. I have a collection of about 200 stock Android wallpapers from the first version, all the way to Nougat. It doesn't matter what size they are because you'll be resizing them anyways.
5. Once you've chosen your wallpapers, you'll have to resize them. For this guide I will be using Microsoft Paint. Navigate to the folder containing your new wallpapers and open the first one in Paint. Click the 'Resize' button at the top left of the screen, select Pixels and make sure the 'maintain aspect ratio' box is UNCHECKED. Your wallpaper MUST be the same size/resolution as Amazon's. Enter the values as listed and pictured below:
Code:
Horizontal: 1920
Vertical: 1200
6. Save the wallpaper as a .jpg. The name doesn't matter right now because we will be renaming them. If you are going to use 7 different wallpapers, you need to make a copy of the wallpaper you just resized. Open it in paint and again click resize, select Pixels and make sure 'maintain aspect ratio' is UNCHECKED. Reverse the dimensions:
Code:
Horizontal: 1200
Vertical: 1920
7. If you want to keep the same wallpaper on your lock screen all the time, repeat the above step with copies of the same wallpaper. Regardless if you use the same ones or different ones, you will have 14 wallpapers in the folder when done.
8. Navigate back to your ADB folder and locate SystemUI.apk. Right click on it and select the '7-Zip' option then 'open archive'. DO NOT UNZIP, EXTRACT OR DECOMPILE THE APK! Resize the window so you have a good amount of space to open the wallpaper folder we just made. Place the windows next to each other.
9. In the 7-zip, SystemUI archive window, double click on the 'res' folder then locate and double click the 'raw-hdpi-v4' folder. This is the location of the Amazon's default lock screen wallpapers. In your custom, wallpaper folder, you need to rename each wallpaper to match the names of Amazon's. It's important you do this step and that the names match. Otherwise when you reinstall the SystemUI, it will crash.
10. When you're done, in your custom wallpaper folder, click on 'Edit' a the top and 'select all'. Click on any of the wallpapers but don't let go! Start to drag them over to the 7-zip SystemUI window. Make sure you have all of them, then let go. When the box pops up asking you if you want to overwrite the other wallpapers just click yes. Close both windows and open an ADB window again.
11. Download and install ADB Insecure from the link at the beginning of this post. Open it and grant it root access if you don't have SuperSU set to automatic. Check the box to put ADB into insecure mode. In the ADB window, type the following commands, pressing enter after each one.
Code:
adb remount
adb push SystemUI.apk /system/priv-app/SystemUI/SystemUI.apk
adb reboot
12. That's all. If successful, your tablet will reboot and your custom lock screen wallpaper(s) should appear. If unsuccessful, your tablet will reboot, but with no SystemUI active. I'll write a small guide on recovering from a SystemUI crash without reflashing firmware if anyone has a problem. Until then enjoy your wallpapers. Just remember you have to repeat this guide each time you want to change them. Until I can figure out how Amazon Photos has such control over the lock screen, this is the only way to change your lock screen wallpapers if you uninstall Amazon Photos. Thank you for following everyone!
Definitely looking forward to trying this!
Still waiting for part 2. Also wondering if it's possible to modify the framework so that we can customize the power options.
oscarcx said:
Still waiting for part 2. Also wondering if it's possible to modify the framework so that we can customize the power options.
Click to expand...
Click to collapse
Got a little busier this weekend than I predicted. I will try to get part 2 up today or tonight.
Is it possible? Yes. However I'm having a difficult time with it. Those settings are a bit scattered and butchered so I'm having trouble figuring out which xml to edit. Amazon created their own xml files to override some of androids. It also doesn't help that a lot of values from the bools are repeated then scattered across various system apps. I know one issue is the power profile. Amazon did a good job of butchering that setting and it's proving difficult reconstruct. In other words the power profile is almost non existent.
DragonFire1024 said:
Got a little busier this weekend than I predicted. I will try to get part 2 up today or tonight.
Is it possible? Yes. However I'm having a difficult time with it. Those settings are a bit scattered and butchered so I'm having trouble figuring out which xml to edit. Amazon created their own xml files to override some of androids. It also doesn't help that a lot of values from the bools are repeated then scattered across various system apps. I know one issue is the power profile. Amazon did a good job of butchering that setting and it's proving difficult reconstruct. In other words the power profile is almost non existent.
Click to expand...
Click to collapse
No need to hurry. These are great discoveries so take your time to write the tutorial
In my opinion, your tutorial is kind of way too detailed. I know it's great for tech newbies, but by simplifying it a little bit could effectively save your time.
For the power option, if it's way too hard to customize it, maybe spending time on other stuff will be a better choice.
Anyways, thanks for your amazing work!
oscarcx said:
No need to hurry. These are great discoveries so take your time to write the tutorial
In my opinion, your tutorial is kind of way too detailed. I know it's great for tech newbies, but by simplifying it a little bit could effectively save your time.
For the power option, if it's way too hard to customize it, maybe spending time on other stuff will be a better choice.
Anyways, thanks for your amazing work!
Click to expand...
Click to collapse
I think it's more of putting pieces back in the right spots, for example, settings fragments. Some things are directed with Amazon's fragments and it's just a matter of finding the right android fragment and replacing it. In other cases, Amazon blocks out some features in an 'assets' file. Some things are also set in smali files/java and I know very little about smali, so have been reading up on that. Sometimes the fix is just a simple word change like the DayDream. I also recently discovered other settings or at least "project defaults " set by mediatek. I'm able to change some of those and supposedly add them to the build prop for more activation, but so far I haven't seen a difference.
Change your lock screen wallpapers everyone Part 2 is out!
DragonFire1024 said:
This guide will teach you how to change all of the stock FireOS wallpapers. This is much easier than activating Daydreams and you don't need Java or Apktool to make the edits.
(........................)
Thank you for following everyone!
Click to expand...
Click to collapse
Brilliant! Never thought of replacing those default wallpapers. At least this is a temporary solution.
I am wondering how the lockscreen wallpaper works and correct me if I am wrong. The app called "Special offer" is included in stock Fire OS and it has the ability to either change the wallpaper or overlay the wallpaper. Maybe it's a good idea to start from there but I am not sure about the legitimacy issue.
The lockscreen itself is weird though. Using Gravity Box, I can change some of the features but not all of them. Someone here told me that the lockscreen is deeply integrated into Fire OS.
oscarcx said:
Brilliant! Never thought of replacing those default wallpapers. At least this is a temporary solution.
I am wondering how the lockscreen wallpaper works and correct me if I am wrong. The app called "Special offer" is included in stock Fire OS and it has the ability to either change the wallpaper or overlay the wallpaper. Maybe it's a good idea to start from there but I am not sure about the legitimacy issue.
The lockscreen itself is weird though. Using Gravity Box, I can change some of the features but not all of them. Someone here told me that the lockscreen is deeply integrated into Fire OS.
Click to expand...
Click to collapse
There's a line in the build.prop file called "curlockscreen" with a value of 1. I have no idea exactly what it's for, but it might be related to disabling and/or modifying the lock screen.
lakitu47 said:
There's a line in the build.prop file called "curlockscreen" with a value of 1. I have no idea exactly what it's for, but it might be related to disabling and/or modifying the lock screen.
Click to expand...
Click to collapse
Just did a quick search on it and looks like it's the default lockscreen style
I decided to give Part 1 a try.
I got up to step 15 successfully, including having the Daydream tile.
I'm presuming that — to install BasicDreams.apk (in step 16) — you need to have another round of "adb remount"
Unfortunately, although "adb remount" worked when I did it the first time, trying to do it now results in an error:
remount of system failed: Invalid argument
remount failed
Trying to copy (with the "adb push BasicDreams.apk" command) results in an error:
adb: error: failed to copy '[PATH]/BasicDreams.apk' to '/system/app/BasicDreams.apk': remote Read-only file system
(Unsurprisingly, this is the same error if I try to do the "adb push BasicDreams.apk" thing without trying "adb remount")
In all cases, I'm re-enabling the "Enable insecure adbd" option from the "adbd insecure" app.
Any ideas how to fix this?
GamerOfRassilon said:
I decided to give Part 1 a try.
I got up to step 15 successfully, including having the Daydream tile.
I'm presuming that — to install BasicDreams.apk (in step 16) — you need to have another round of "adb remount"
Unfortunately, although "adb remount" worked when I did it the first time, trying to do it now results in an error:
remount of system failed: Invalid argument
remount failed
Trying to copy (with the "adb push BasicDreams.apk" command) results in an error:
adb: error: failed to copy '[PATH]/BasicDreams.apk' to '/system/app/BasicDreams.apk': remote Read-only file system
(Unsurprisingly, this is the same error if I try to do the "adb push BasicDreams.apk" thing without trying "adb remount")
In all cases, I'm re-enabling the "Enable insecure adbd" option from the "adbd insecure" app.
Any ideas how to fix this?
Click to expand...
Click to collapse
Make sure box is checked in adb insecure. After a reboot, you need to check the box again.
oscarcx said:
Just did a quick search on it and looks like it's the default lockscreen style
Click to expand...
Click to collapse
Yes but broken up internally. I do have a fix but I have to consult a developer before I announce it as it uses a piece of software from another rom.
GamerOfRassilon said:
I decided to give Part 1 a try.
I got up to step 15 successfully, including having the Daydream tile.
I'm presuming that — to install BasicDreams.apk (in step 16) — you need to have another round of "adb remount"
Unfortunately, although "adb remount" worked when I did it the first time, trying to do it now results in an error:
remount of system failed: Invalid argument
remount failed
Trying to copy (with the "adb push BasicDreams.apk" command) results in an error:
adb: error: failed to copy '[PATH]/BasicDreams.apk' to '/system/app/BasicDreams.apk': remote Read-only file system
(Unsurprisingly, this is the same error if I try to do the "adb push BasicDreams.apk" thing without trying "adb remount")
In all cases, I'm re-enabling the "Enable insecure adbd" option from the "adbd insecure" app.
Any ideas how to fix this?
Click to expand...
Click to collapse
How about,
adb shell
su
mount -o rw,remount /system
Instead of adb remount? It looks like an error in adb remount.
Supersonic27543 said:
How about,
adb shell
su
mount -o rw,remount /system
Instead of adb remount? It looks like an error in adb remount.
Click to expand...
Click to collapse
You can do that I suppose. I haven't tried. I side stepped that method because adb will make sure the APK has the permissions assigned properly amongst other anomalies I've come across. These are old APKs from original sources I work with. Most of the time i keep them safely inside their zipped ROM and sometimes you only get so many uses out of them if you move them around outside the system too much without proper permissions. In a matter of speaking they get lost and stop working. So I try to minimize the amount of time they remain away from home. With that said, it shouldn't be a problem.
Sent from my Samsung Galaxy S4 using XDA Labs
To follow up here:
1) I was certain I re-enabled adb insecure.
2) I tried "mount -o rw,remount /system", and got a similar error: "mount: Invalid argument". I also tried a command that worked in the past (that I'm pretty sure is doing the same thing): "mount -w -o remount /system" (no quotes, obviously), and also got the "mount: Invalid argument" error.
3) The error I had in this circumstance was similar to one I had on an unrelated matter regarding getting FlashFire working.
What I suspect is that somehow /system gets tired of being written to, and it "locks me out" for some reason. (There are two points when I have traditionally made use of "mount -w -o remount /system" — when I copy over the initial /system image via "dd if=/sdcard/system.img of=/dev/block/mmcblk0p13; sync" and when I disable OTA updates with "mv /system/priv-app/DeviceSoftwareOTA/DeviceSoftwareOTA.apk /system/priv-app/DeviceSoftwareOTA/DeviceSoftwareOTA.apk_" )
Another possibility is that I had somehow made a mistake in following this tutorial originally, typing "adb push [SOURCE]\framework-res.apk /system/framework-res.apk" instead of "adb push [SOURCE]\framework-res.apk /system/framework/framework-res.apk"
I deleted the errant framework-res.apk from /system, but I wonder if that somehow tripped up some kind of "don't muck with this" flag that wouldn't let me remount it.
4) Speaking of which, are you sure about this command in Step 16?
adb push BasicDreams.apk /system/app
Click to expand...
Click to collapse
I can't get it to work. In fact, if I use a file browser to go to /system , I just have a non-folder file named "app" that happens to be the same size as BasicDreams.apk . . .
I reflashed my /system and confirmed that I don't seem to have a folder named "app" in /system , so I can't quite figure out what that command is doing . . . Does it need to be:
adb push BasicDreams.apk /system/priv-app
? (I have a 2017 HD10, if it matters.)
5) For my second attempt, I tried to do as "clean" a re-install of my system as I could, avoiding the two instances of when I would remount /system in the past (flashing a straight system.img extracted from an update and freezing the OTA app with Titanium Backup). This time, remounting worked both times, as did the rest of the procedures (with the exception of the "BasicDreams.apk" problem, directly above).
GamerOfRassilon said:
To follow up here:
1) I was certain I re-enabled adb insecure.
2) I tried "mount -o rw,remount /system", and got a similar error: "mount: Invalid argument". I also tried a command that worked in the past (that I'm pretty sure is doing the same thing): "mount -w -o remount /system" (no quotes, obviously), and also got the "mount: Invalid argument" error.
3) The error I had in this circumstance was similar to one I had on an unrelated matter regarding getting FlashFire working.
What I suspect is that somehow /system gets tired of being written to, and it "locks me out" for some reason. (There are two points when I have traditionally made use of "mount -w -o remount /system" — when I copy over the initial /system image via "dd if=/sdcard/system.img of=/dev/block/mmcblk0p13; sync" and when I disable OTA updates with "mv /system/priv-app/DeviceSoftwareOTA/DeviceSoftwareOTA.apk /system/priv-app/DeviceSoftwareOTA/DeviceSoftwareOTA.apk_" )
Another possibility is that I had somehow made a mistake in following this tutorial originally, typing "adb push [SOURCE]\framework-res.apk /system/framework-res.apk" instead of "adb push [SOURCE]\framework-res.apk /system/framework/framework-res.apk"
I deleted the errant framework-res.apk from /system, but I wonder if that somehow tripped up some kind of "don't muck with this" flag that wouldn't let me remount it.
4) Speaking of which, are you sure about this command in Step 16?
I can't get it to work. In fact, if I use a file browser to go to /system , I just have a non-folder file named "app" that happens to be the same size as BasicDreams.apk . . .
I reflashed my /system and confirmed that I don't seem to have a folder named "app" in /system , so I can't quite figure out what that command is doing . . . Does it need to be:
adb push BasicDreams.apk /system/priv-app
? (I have a 2017 HD10, if it matters.)
5) For my second attempt, I tried to do as "clean" a re-install of my system as I could, avoiding the two instances of when I would remount /system in the past (flashing a straight system.img extracted from an update and freezing the OTA app with Titanium Backup). This time, remounting worked both times, as did the rest of the procedures (with the exception of the "BasicDreams.apk" problem, directly above).
Click to expand...
Click to collapse
I am not too sure why this is happening. I presume you edited the framework-res.apk? If so, use a root explorer, I use the actual Root Explorer, and navigate to /system/priv-app and create a folder named BasicDreams. If using root excplorer, Long press the folder, tapp three dots at top right, tap permissions, set to 0755 (rwxr-xr-x). Place the APK in the internal storage of your tablet. Open your root explorer and go to your internal storage. CUT the APK FIRST to /system then CUT it to the BasicDreams folder in /system/priv-app you just made. When done, if using root explorer, long press the APK, tap three dots on upper right and tap permissions. set permissions to 0644 (rw-r--r--). Reboot then go to settings, display, and see the Daydream menu.
DragonFire1024 said:
I am not too sure why this is happening. I presume you edited the framework-res.apk? If so, use a root explorer, I use the actual Root Explorer, and navigate to /system/priv-app and create a folder named BasicDreams. If using root excplorer, Long press the folder, tapp three dots at top right, tap permissions, set to 0755 (rwxr-xr-x). Place the APK in the internal storage of your tablet. Open your root explorer and go to your internal storage. CUT the APK FIRST to /system then CUT it to the BasicDreams folder in /system/priv-app you just made. When done, if using root explorer, long press the APK, tap three dots on upper right and tap permissions. set permissions to 0644 (rw-r--r--). Reboot then go to settings, display, and see the Daydream menu.
Click to expand...
Click to collapse
I did edit the framework-res.apk, yes.
I jumped through all those hoops, it it is — indeed — working! (I interpreted the instructions as "Cut and paste into /system, then cut and paste it from /system into the folder on /system/priv-app" . . . is that because the file needs to "touch" /system to work correctly? And I just COPY/pasted the first time into /system, to keep the original backed up on my SD card.)
GamerOfRassilon said:
I did edit the framework-res.apk, yes.
I jumped through all those hoops, it it is — indeed — working! (I interpreted the instructions as "Cut and paste into /system, then cut and paste it from /system into the folder on /system/priv-app" . . . is that because the file needs to "touch" /system to work correctly? And I just COPY/pasted the first time into /system, to keep the original backed up on my SD card.)
Click to expand...
Click to collapse
It touches the system just as a precaution. I've read in places it a way for the system to better accept APKs as a system app when you force install it like this. I don't know if it's true, but when manually adding a file, i take this step as a just in case route.
Disable Tracking Services
This is a set of scripts that disables privacy invasive tracking components in all user installed apps (service/broadcast receiver/activity/content provider).
Root permission is required to run the scripts.
How it works:
UpdateExodus.sh downloads tracker names from Exodus Privacy.
DisableTracking.sh dumps a list of components of all installed apps, compare it against the list of trackers name, and disable those components (using the 'pm disable' command) if they match.
Download: Google Drive link
Check instructions.txt for details on how to use the scripts.
The latest version is 1.8.
You are recommended to backup your apps before running the scripts.
You are also recommended to do a full nandroid backup before running the scripts.
I hope you will find this useful
The script was originally based on the one here: https://forum.xda-developers.com/android/development/script-disable-fk-services-trackers-apps-t4074427
Instructions
Prerequisites:
Root permission is required.
You also need these extra binaries installed in a directory of $PATH (such as /system/xbin):
-aapt
-jq
You can download these binaries from the Termux app ( https://play.google.com/store/apps/details?id=com.termux )
You will also need busybox installed. Search for how to install it.
Method 1 (automatic) (experimental):
Run InstallReq.sh in Termux *as a normal user* (not as root)
i.e. run this command: bash /path/to/script/InstallReq.sh
It will check if aapt, jq, curl or sqlite3 are missing and automatically download them, then copy them to /system/xbin.
Method 2 (manual):
Run these commands in Termux:
pkg install aapt
pkg install jq
Copy them from /data/data/com.termux/files/usr/bin to a directory of $PATH
Then give them execution permission, e.g. "chmod +x /system/xbin/aapt"
To see what directories are in $PATH, run this command: "echo $PATH"
Note: if you've placed the binaries in /sbin, or you have installed Magisk,
the binaries will be deleted every reboot. You'll have to copy them again.
Note: aapt and jq must be downloaded from Termux and the Termux app must remain installed,
since the dependencies are stored in Termux's data folder.
------------------------------------------------------------
Usage:
-All scripts and txt files must be in the same directory as DisableTrackers.sh
You need a terminal emulator to run these scripts.
Personally I use "Terminal Emulator for Android" ( https://play.google.com/store/apps/details?id=jackpal.androidterm )
This terminal emulator lets you add launcher shortcuts. Quite convenient in my opinion.
Termux may also work, but I haven't tested it.
For first time usage, run UpdateExodus.sh first.
i.e. run this command: su -c sh /path/to/script/UpdateExodus.sh
If the script runs successfully, a MergedTrackers.txt will be created.
Then you can run DisableTrackers.sh AS SU to start disabling trackers. (root permission is required)
i.e. run this command: su -c sh /path/to/script/DisableTrackers.sh
By default, only third party apps are checked.
If you want to check for trackers in system apps as well, add 'sys' as the parameter.
i.e. run this command: su -c sh /path/to/script/DisableTrackers.sh sys
Not really recommended since it could theoretically mess up Google Play Services, though I can't confirm since I don't have it installed on my phone.
Note: if you've used version 1.4 or below and don't want the script to process all apps again, run CreateAppDB.sh.
It will create a ProcessedApps.db with records of all currently installed apps.
------------------------------------------------------------
Explanations:
UpdateExodus.sh will download a tracker list from Exodus Privacy, and merge it with CustomTrackers.txt (if it exists)
You can add your own trackers to CustomTrackers.txt. You may also write comments in this format: #(comment here)
DisableTracking.sh will dump a list of components (service/broadcast receiver/activity/content provider) of all installed apps,
compare it against the list of trackers in MergedTrackers.txt, and disable those components if they match.
It will save a list of already processed apps to a database file in the script's directory,
so they will not be processed twice when you run the script again (like maybe you've installed a new app and you want to disable its trackers by running the script).
Apps with trackers will be logged to AppsWithTrackers.txt.
exodustrackers.json is the raw list downloaded from Exodus Privacy.
MergedTrackers.txt contains the merged results of exodustrackers_extracted.txt and CustomTrackers.txt.
ProcessedApps.db contains a list of already processed apps. They will be skipped in the next run of DisableTrackers.sh.
whitelist.txt is a list of apps that will be skipped.
Update log
Version 1.5:
-DisableTracking.sh now uses a database to store processed app names and versions.
This means if an app was updated, it will check for trackers in the updated app again.
-If there was a deleted app, DisableTracking.sh will now delete its record from ProcessedApps.db automatically. No more manual deletion.
-Note: if you've used version 1.4 or below and don't want the script to process all apps again, run CreateAppDB.sh.
It will create a ProcessedApps.db with records of all currently installed apps.
Version 1.6:
-DisableTracking.sh now supports checking for trackers in system apps. Check the usage section for how to use.
-Improved logic of DisableTracking.sh to reduce problems. Thanks to hyborian for pointing them out.
-Added checks for root permission and presence of extra binaries.
-The new script 'InstallReq.sh' will automatically install missing extra binaries from Termux.
Check the prerequisites section for how to use.
-UpdateExodus.sh will no long generate exodustrackers_extracted.txt. The content is stored in memory instead of a file.
-MergeExodus.sh is no longer needed. The functions are...merged into UpdateExodus.sh.
Version 1.7:
-DisableTracking.sh now shows the app name as seen in the launcher when processing an app (will be empty if the app name is not in Engish)
-DisableTracking.sh will skip apps in whitelist.txt.
-UpdateExodus.sh now shows new tracker names that were not previously present in the old MergedTrackers.txt.
Version 1.8:
-Small fix in DisableTracking.sh that stops it from creating duplicated records in ProcessedApps.db
(in line 165, grep -qx is chnaged to grep -q)
If you've used version 1.6 or above, you are recommended to delete ProcessedApps.db located in the script's directory and run CreateAppDB.sh to regenerate a ProcessedApps.db, although the existing ProcessedApps.db with duplicated records may still work.
reserved 3
Thanks, fantastic tool
del
Hello I got a little issue with your tools ( it says to i need to verify my internet connection but I have wifi on. I have tried in mobile data still same ...
(When I open the web site manually it work but during the script execution I have this issue any other method?
Random-Tester said:
Hello I got a little issue with your tools ( it says to i need to verify my internet connection but I have wifi on. I have tried in mobile data still same ...
(When I open the web site manually it work but during the script execution I have this issue any other method?
Click to expand...
Click to collapse
Ok try running the script in attachment (remove .txt in the name), copy/screenshot the output and post it here.
steveglowplunk said:
Ok try running the script in attachment (remove .txt in the name), copy/screenshot the output and post it here.
Click to expand...
Click to collapse
Hi thnx for fast answers !! Unfortunately nothing new
I got this in terminal :
$ su
:/data/data/com.termux/files/home # /system/bin/UpdateExodus.sh
curl not found
wget not found
jq is a tracked alias for /sbin/jq
Checking connection with https://etip.exodus-privacy.eu.org/trackers/export
/system/bin/UpdateExodus.sh[26]: curl: inaccessible or not found
Network check status is empty
Unable to connect with https://etip.exodus-privacy.eu.org/trackers/export. Please check you internet connection.
No changes done.
Script will exit now.
Random-Tester said:
Hi thnx for fast answers !! Unfortunately nothing new
I got this in terminal :
$ su
:/data/data/com.termux/files/home # /system/bin/UpdateExodus.sh
curl not found
wget not found
jq is a tracked alias for /sbin/jq
Checking connection with https://etip.exodus-privacy.eu.org/trackers/export
/system/bin/UpdateExodus.sh[26]: curl: inaccessible or not found
Network check status is empty
Unable to connect with https://etip.exodus-privacy.eu.org/trackers/export. Please check you internet connection.
No changes done.
Script will exit now.
Click to expand...
Click to collapse
Yes, the purpose of the script was to find out missing binaries, and it says you're missing curl and wget. This could be because you don't have busybox installed (wget is included in busybox) and you're running stock rom (curl should be included in a custom rom such as LineageOS).
What you can do is download those binaries from Termux. (Use the command 'pkg install curl', same for wget), and copy them to /sbin, just like what you'd do with jq.
curl is used for checking connection status. wget is used for downloading the trackers json file.
After executing everything perfectly, I ran to a weird instance where everytime it scans an app, a command sqlite3: inaccessible or not found was shown. I was wondering if this shows because I performed disable f*ck services script first then this script? are they supposed to do the same? does that mean the apps I'm scanning right now already have their services/receivers disabled thats why disabletracking.sh can't detect them? thank you!
phantom146 said:
After executing everything perfectly, I ran to a weird instance where everytime it scans an app, a command sqlite3: inaccessible or not found was shown. I was wondering if this shows because I performed disable f*ck services script first then this script? are they supposed to do the same? does that mean the apps I'm scanning right now already have their services/receivers disabled thats why disabletracking.sh can't detect them? thank you!
Click to expand...
Click to collapse
That means sqlite3 is not installed (I thought it's supposed to be included in Android?). Verify it by running 'type sqlite3' in the terminal.
Maybe you can try downloading sqlite (without the 3) from Termux with the 'pkg install' command, then copy the downloaded binaries to /sbin (similar to what you'd do with jq). Or you can use version 1.4 for now.
sqlite3 is used for writing a database that stores processed apps names and versions, so that they will be skipped in the next run. The script will still disable tracking components that haven't been disabled already.
steveglowplunk said:
That means sqlite3 is not installed (I thought it's supposed to be included in Android?). Verify it by running 'type sqlite3' in the terminal.
Maybe you can try downloading sqlite (without the 3) from Termux with the 'pkg install' command, then copy the downloaded binaries to /sbin (similar to what you'd do with jq). Or you can use version 1.4 for now.
sqlite3 is used for writing a database that stores processed apps names and versions, so that they will be skipped in the next run. The script will still disable tracking components that haven't been disabled already.
Click to expand...
Click to collapse
This worked well. Thank you.
Do you plan on implementing something for sqlite, jq and aapt to stick on sbin for the next update?
Also, some of the apps I'm scanning shows:
Exception occured while executing:
java.lang.illegalArgumentException: component class bugsnag.com etc. Etc. Does not exist in bla bla app.
I assume exodus detected that a certain app has trackers and tries to disable it but since I used disablefohkservice script before this, I guess it was already disabled and disabletracking.sh can't find it now?
phantom146 said:
This worked well. Thank you.
Do you plan on implementing something for sqlite, jq and aapt to stick on sbin for the next update?
Also, some of the apps I'm scanning shows:
Exception occured while executing:
java.lang.illegalArgumentException: component class bugsnag.com etc. Etc. Does not exist in bla bla app.
I assume exodus detected that a certain app has trackers and tries to disable it but since I used disablefohkservice script before this, I guess it was already disabled and disabletracking.sh can't find it now?
Click to expand...
Click to collapse
The error you mentioned is normal. That component cannot be toggled.
Also, please try running the script attached in Termux as a normal user (root permission will be required half-way through the script) by running 'bash /path/to/script/InstallReq.sh' . It will check if aapt, jq, curl or sqlite3 are missing and automatically download them, then copy them to /system/xbin. (binaries there should retain across reboots). You are recommended to backup at least your system partition in a recovery. Although tested on my own phone and it shouldn't overwrite anything important in /system, I'm not responsible for any damage caused.
Edit: small change to the script to avoid problems with checking curl
Updated script to version 1.6. Check update log for details.
phantom146 said:
Also, some of the apps I'm scanning shows:
Exception occured while executing:
java.lang.illegalArgumentException: component class bugsnag.com etc. Etc. Does not exist in bla bla app.
Click to expand...
Click to collapse
I just added a 2> /dev/null to the disable line so I don't see it ...
---------- Post added at 10:10 AM ---------- Previous post was at 10:09 AM ----------
steveglowplunk said:
Updated script to version 1.6. Check update log for details.
Click to expand...
Click to collapse
Great, will try it ...
All good :good:, I just added code to delete old app versions from processed db, and to recreate DBFullList variable again after the sqlite changes.
hyborian said:
All good :good:, I just added code to delete old app versions from processed db, and to recreate DBFullList variable again after the sqlite changes.
Click to expand...
Click to collapse
Um... That doesn't sound necessary?
The version field in the database is updated after processing an updated app. There shouldn't be old app versions left behind?
Also, DBFullList doesn't need to be updated after processing an app. If an app's name doesn't exist in DBFullList, then it must be a new app. If it exists in DBFullList and was processed, then it must be an updated app. Not updating the DBFullList variable after processing each apps shouldn't affect the functions.
steveglowplunk said:
Um... That doesn't sound necessary?
The version field in the database is updated after processing an updated app. There shouldn't be old app versions left behind?
Also, DBFullList doesn't need to be updated after processing an app. If an app's name doesn't exist in DBFullList, then it must be a new app. If it exists in DBFullList and was processed, then it must be an updated app. Not updating the DBFullList variable after processing each apps shouldn't affect the functions.
Click to expand...
Click to collapse
Lol, you are right, I was looking at my old processed db which had apps with different versions. I should just have erased it and started fresh.
Anyway, it was nice practice for me. learned something while doing it when I couldn't grep the darn version number of Google Play Store (Version: 20.2.09-all [0] [PR] 311811225 (82020900) in DBFullList. I finally realized it had metacharacters [ ] so changed the grep from -qx to -qFx, and all ok now; otherwise, it will get processed again even if it was already done.
Thanks for the script, really great, beats manually doing it using MyAndroidPro or Blocker.
hyborian said:
Lol, you are right, I was looking at my old processed db which had apps with different versions. I should just have erased it and started fresh.
Anyway, it was nice practice for me. learned something while doing it when I couldn't grep the darn version number of Google Play Store (Version: 20.2.09-all [0] [PR] 311811225 (82020900) in DBFullList. I finally realized it had metacharacters [ ] so changed the grep from -qx to -qFx, and all ok now; otherwise, it will get processed again even if it was already done.
Thanks for the script, really great, beats manually doing it using MyAndroidPro or Blocker.
Click to expand...
Click to collapse
Ah I see. I'll add that -F option in the next update.
Hi there, i am right at the end of the process of installing the modded samsung health monitor app and ADB etc but i have an error right at the end which is killing me.
This is it here:
C:\Program Files (x86)\Minimal ADB and Fastboot>adb -s "IP address" install Watch.SHM.MOD.1.1.0.215.dante63.apk
error: device 'IP address' not found
adb: error: failed to get feature set: device 'IP address' not found
- waiting for device -
I think it is probably down to the last instruction which is this one:
Now, set your watch aside, type the following ADB command, and hit Enter to install the modded Samsung Health Monitor app on the watch. For this command to work as intended, you need to have the modded Samsung Health Monitor APK in the same directory as the file labeled cmd-here. Also, replace the X in the command mentioned below with the current version number of the APK.
adb -s "IP address" install Watch.SHM.MOD.X.X.X.XXX.dante63.apk
I have put the version number in as i downloaded it 1.1.0.215
I am unclear though on where i am supposed to make sure the apk is in relation to 1.1.0.215
Am i supposed to make sure the APK on my phone is in the same folder as what????? where does the cmd-here file come from ?
Help would be appreciated before i launch the phone towards a crash landing in mild temper LOL
Did you enable wireless debugging on your watch?
naked123 said:
Did you enable wireless debugging on your watch?
Click to expand...
Click to collapse
yep certainly did, and adb connectee so i allowed it
Try using wear installer 2
Sleepwalker54321 said:
Hi there, i am right at the end of the process of installing the modded samsung health monitor app and ADB etc but i have an error right at the end which is killing me.
This is it here:
C:\Program Files (x86)\Minimal ADB and Fastboot>adb -s "IP address" install Watch.SHM.MOD.1.1.0.215.dante63.apk
error: device 'IP address' not found
adb: error: failed to get feature set: device 'IP address' not found
- waiting for device -
I think it is probably down to the last instruction which is this one:
Now, set your watch aside, type the following ADB command, and hit Enter to install the modded Samsung Health Monitor app on the watch. For this command to work as intended, you need to have the modded Samsung Health Monitor APK in the same directory as the file labeled cmd-here. Also, replace the X in the command mentioned below with the current version number of the APK.
adb -s "IP address" install Watch.SHM.MOD.X.X.X.XXX.dante63.apk
I have put the version number in as i downloaded it 1.1.0.215
I am unclear though on where i am supposed to make sure the apk is in relation to 1.1.0.215
Am i supposed to make sure the APK on my phone is in the same folder as what????? where does the cmd-here file come from ?
Help would be appreciated before i launch the phone towards a crash landing in mild temper LOL
Click to expand...
Click to collapse
Did you use the watches IP address instead of the text "IP address"?
Did you connect your watch via adb first?
Apache config:
adb connect x.x.x.x
Yes and yes
Its easy to make a mistake in the process ( happened to me).
Best is to start from step 1 again and carefully follow all instructions.
Use the TAB key to autocomplete file names and directories in a command line interface.
That way you're sure that it's actually the right name