Related
Can one of you rom gurus make a busybox update zip which includes (super user, busybox and wireless tether) that is compatible with any rom. I like to flash different roms and not all roms allow for metamorph use or wireless tether...
this is for ubuntu 32bit with build-essentials installed and arm enabled in the kernel.
go here
http://busybox.net
then download the tarball and patches
apply the patches
then
make menuconifg
select you options
then make CROSS_COMPILE=arm-linux-uclibcgnueabi-
remount phone in rw mode
then copy the binary to the location of busy box on the phone usually /system/bin or data/local/bin
should be good
I am a complete noob when it comes to this, that why i am asking the community to make it. your instructions appear to be complete, but i am completely lost.
orrrrr........
you could search the Hero CDMA sub-forum and find someone already did this!
http://forum.xda-developers.com/showthread.php?t=593952&highlight=busybox
pretty sure your looking for something exactly like that right?
EDIT: adb remount- superuser application- and busybox plus app2sd if your card is partitioned properly.
EDIT2: wireless tether apk can be found in this thread http://forum.xda-developers.com/showthread.php?t=612221&highlight=wireless+tether
you take all the fun out of it.
I would like to mess with trying to install my own customized ROM's to my Nexus 7, but the first place to probably start is with being able to build AOSP as-is from source.
As I understand currently, building is only supported on Linux and OS X, but I can easily get Ubuntu 10.04 and re-partition my HDD to give it about 100GB (if that much is even needed).
Looking at:
http://source.android.com/source/initializing.html
I need to choose a branch and setup the Linux environment. I'm a bit confused as to what branch I should choose though. I want the latest source of Android available at the time, so I should pick the master branch? Or since I'm only building for the Nexus 7, should I choose it's device-specific branch instead? Although looking at:
http://source.android.com/source/build-numbers.html
the Nexus 7 is only at android-4.1.1_r1.1, but I could of sworn I heard there was r4 out already.
As for setting up the Linux environment, I hope I can just follow all the commands listed there without any problem.
Proceeding on with:
http://source.android.com/source/downloading.html
It looks like a pretty straightforward process that I'm also hoping can be done successfully if I follow the commands exactly as presented. I don't have a proxy nor the need for a local mirror either.
And then moving onto:
http://source.android.com/source/building-devices.html
Some stuff there I find a little bit confusing. It would seem I have to first get proprietary drivers, which all 4 seem to be placed conveniently at:
https://developers.google.com/android/nexus/drivers#grouper
From there, I imagine I can move the script that's bundled inside to the root of the source folder, run it, and follow the instructions. I don't exactly know what the root of the source folder is, but it would probably be obvious once I did start trying to build this. But once I did find it, I would run (using Nvidia's Graphics driver for the example) sh extract-nvidia-grouper.sh in Terminal, and it would place the right files where they need to be.
I don't understand the make clobber part too well at all; should I run this on the very first build, later builds, or all builds?
And once the source and drivers are all downloaded and available, I should then run lunch full_grouper-userdebug and then finally make -j# (# being some number in accordance with how many cores on my CPU I have). I have a triple-core CPU at 3.5Ghz, and I have the ability to unlock to quad-core at 3.3Ghz (but prefer to stay on triple). Should I just run -j32? Also will this build the Kernel as well, or will I have to get the source for that and compile it separately?
And once the build completes, my plan from there was to just go back to Windows and flash it. And if I managed to get it to flash and boot properly, I assume I would of succeeded with compiling AOSP from source
I noticed that userdebug part on full_grouper-userdebug gives "root access and debuggability". Does this mean it comes with some program like Superuser or SuperSU already installed? Or does this mean I can easily install those?
Perhaps after I get comfortable with the basics of flashing AOSP as-is, I can then try to mess with different types of optimizations, like Linaro and perhaps even messing with many types of optimizations from different kernels like faux123 has done .
I also have a 360kb/s DSL connection, so downloading the entire source the first time will probably take a good while. But once I have the source, I take it I don't have to redownload the entire thing for patches and stuff?
Any and all guidance is welcome
Bump before I go for tonight
Bump
You have a bunch of questions. I will answer some. And while I whole-heartedly support learning to build you don't need to build to flash roms.
The best advice I can give you is to just start building. You have found a bunch of instructions and links, obviously. Go ahead and begin, and tackle problems as they arise.
Environment
Okay...really the hardest part is setting upi the environment, if you don' t know linux. After downloading and installing Java and the SDK, make sure you add them to your path.
Most guides will have adding the path in the directions. But make sure to check that it works! It will be extremely frustrating, and you won't know what is wrong. Go to a random directory, Documents would be good, and enter java -version and then adb devices. If the computer says it cannot find the commands, then your path is the problem.
Make sure to setup udev. It is easy, Google it.
Building
Branch
You want to build from the tags.
Code:
repo init -u https://android.googlesource.com/platform/manifest -b android-4.1.1_r4
For the proprietary blobs, whatever directory you repo sync from (~/android/system or whatever) is the root directory. run the extraction from there.
when the proprietary blobs are extracted, and the source has been downloaded, these are your commands.
Code:
. build/envsetup.sh
lunch
Lunch will return a list of devices, Grouper is the Nexus 7, it is number 4. eng and user-debug do have root access, but SU and SuperSU are more than just root, they manage the root access for your apps as well. You can download them from Play or install them as a flashable-zip.
Choose 4 and then
Code:
make otapackage
don't worry about the -j# part. Your machine almost definitley cannot handle -j32. It is -j4 by default, that should be fine for your cpu.
If you want to enable faster builds, you can enter
ENABLE_CCACHE=1
before make otapackage, but it will take up a lot of space on your hd. Your subsequent builds will use some thing from your intial build instead of rebuilding them each time (kernel and other things). So even if you repo sync, some changes won't be reflected in your later builds. For instance, if you do not clean your prebuilts and build system, your build date in the build.prop will always stay the same as the first build.
The way you clear the build directory and make new everything is with make clean or make clobber. You can run it before any build, but the build will take much much longer than one that uses prebuilts. Non-clobbered and with ccache enabled are the fastest of all. But subsequent builds are pretty fast even without ccache.
When you want to update your source, you can just go to your root dir and repo sync. It will only update your source, it won't take nearly as long.
Okay, I answered more than I intended. There are a million guides that show you every step in the process.
Don't ask anymore generic worry questions...you're ready. You understand more than most people do before their first build before I even posted. Get started and if you run into problems, search. If you can't find the answer, then come back and ask us.
Good luck. it is easy, and very satisfying.
I finally got around to installing a Virtual Machine, and Ubuntu 10.04 After doing that, I fully updated Ubuntu, installed VMWare Tools, and then proceeded to start trying to acquire the AOSP source.
Getting sun-java-6 was a bit tricky, but not too hard (I ran the commands exactly as listed on the site, but the package didn't exist; had to get it from somewhere else). After that, I proceeded to do everything else, except CCache (I didn't know what .bashrc was, but I'll look further into this with future AOSP builds).
I then made the folder, did repo sync, and I'm now acquiring the source now from android-4.1.1_r4. As a quick question, does it matter whether I choose to build from android-4.1.1_r4, or master? Would master be more up-to-date?
espionage724 said:
I finally got around to installing a Virtual Machine, and Ubuntu 10.04 After doing that, I fully updated Ubuntu, installed VMWare Tools, and then proceeded to start trying to acquire the AOSP source.
Getting sun-java-6 was a bit tricky, but not too hard (I ran the commands exactly as listed on the site, but the package didn't exist; had to get it from somewhere else). After that, I proceeded to do everything else, except CCache (I didn't know what .bashrc was, but I'll look further into this with future AOSP builds).
I then made the folder, did repo sync, and I'm now acquiring the source now from android-4.1.1_r4. As a quick question, does it matter whether I choose to build from android-4.1.1_r4, or master? Would master be more up-to-date?
Click to expand...
Click to collapse
Sorry for late answer, no, use the r4 branch as it is more up to date. Also, make clobber every time isn't needed but you should as it remove then entire out folder (wich is where compiled stuff go) and this make sure you rebuild a clean thing.
Building CyanogenMod 10
Dunno if this is of any interest, but I have a thread started with a complete walkthrough for building CyanogenMod10 for Nexus 7.
Most of the info is the same, and there are some tips in the comments as well.
espionage724 said:
I would like to mess with trying to install my own customized ROM's to my Nexus 7, but the first place to probably start is with being able to build AOSP as-is from source.
Click to expand...
Click to collapse
So, how did you get on? I've been following the same path I think - repo sync the source and follow Google's own tutorial on compiling Android but with the added step of incorporating the binary drivers for the grouper.
I've built the .img files using make -j8, that all works, fastboot flash worked, but I get no video out when booting up using the new OS. I can ADB into the Nexus and it's certainly booted and working okay apart from, I'm guessing, the missing binary drivers.
I've used each of the 5 binary driver scripts to populate the "vendor" directory in the root of the downloaded source before compiling from scratch, but perhaps I've missed a step, so I'm curious as to whether you've got a fully working AOSP+binary driver compile working.
(By the way, my build environment was Ubuntu 12.04 64bit, SDK r20.0.3, Android 4.1.1 (JRO03R) source, Sun Java 1.6, and it all seems to work well using 8 threads on a Core i5 2500K + 4GB RAM).
Edit:
I re-ran the binary extraction, did a make clean; make clobber, and re-compiled - and now video works. Everything works now apart from the compass, camera and rotation sensor. I also tried compiling CyanogenMod from source, too, and had the exact same three problems. Everything works, and works well, apart from camera, compass and rotation sensor. All of which work in the stock Google ROM. Weird.
OK, So I've just compiled an OTA update package from AOSP source... my question is this:
I already have unlocked the bootloader on my wife's Nexus 7, installed Clockworkmod, rooted it, installed busybox, etc, manually on the stock 4.2 update I downloaded from Google on the device when it asked me to upgrade.
Is the otapackage I just compiled going to replace my custom recovery if I flash it as is? I've looked, and it has a "recovery" folder in the .zip, whereas any of the custom ROMs I have downloaded for my phone do not. Do I simply delete this recovery folder, and flash away? Do I need to edit the updater-script? I'm still trying to read and learn about this, but I haven't gotten a good answer from google or searching this site for my specific problem... maybe I'm wording my searches incorrectly.
I would just rather not have to go back and reinstall Clockworkmod... I know that if I want to have busybox, SuperSU, and other apps installed when I flash I'm going to have to add them to the zip and resign... I just don't want to mess my recovery. And being that this is my wife's tab (and not mine to play with, as she pointed out ) I don't want her to get the impression that I'm having to "fix" something I "broke" lol.
hallowed.mh said:
OK, So I've just compiled an OTA update package from AOSP source... my question is this:
I already have unlocked the bootloader on my wife's Nexus 7, installed Clockworkmod, rooted it, installed busybox, etc, manually on the stock 4.2 update I downloaded from Google on the device when it asked me to upgrade.
Is the otapackage I just compiled going to replace my custom recovery if I flash it as is? I've looked, and it has a "recovery" folder in the .zip, whereas any of the custom ROMs I have downloaded for my phone do not. Do I simply delete this recovery folder, and flash away? Do I need to edit the updater-script? I'm still trying to read and learn about this, but I haven't gotten a good answer from google or searching this site for my specific problem... maybe I'm wording my searches incorrectly.
I would just rather not have to go back and reinstall Clockworkmod... I know that if I want to have busybox, SuperSU, and other apps installed when I flash I'm going to have to add them to the zip and resign... I just don't want to mess my recovery. And being that this is my wife's tab (and not mine to play with, as she pointed out ) I don't want her to get the impression that I'm having to "fix" something I "broke" lol.
Click to expand...
Click to collapse
Sorry if a bit late, but here are some answers:
yes, the rom will replace your recovery. but if you delete the recovery folder and delete every line containing the word "recovery" in the updater-script, you should be good to go.
And if you accidentally remove the recovery, you can always flash it back very easily using: "fastboot flash recovery [filename.img]" (your n7 has to be in the bootloader)
And again, yes, you will have to put the extra apps into the zip and update the updater-script to install them too.
Also, you will need the gapps package if you want to use the play store and other google apps.
Hope this helped
Nexus 7 3G does not boot after flashing AOSP
Hi,
I followed the steps provided on source.android.com to build and flash the AOSP for Nexus 7 3G Tilapia. After successful flash, the device does not show anything after Google logo. Please help me out.
Thanks,
Veeren
Compile with ccache makes build time extremely fast.
How to do:
_Open a terminal
_Install ccache:
sudo apt-get install ccache
_Open .bashrc:
sudo gedit ~/.bashrc
_Add these lines:
#ccache
export USE_CCACHE=1
_Save and exit
_Sync source code
_After source synced, run in same terminal (in root directory of your source):
prebuilts/misc/linux-x86/ccache/ccache -M 20G (20G is the size in giga of space allocated for ccache, change it as you want)
_Start building
How to see if ccache works:
_Open another terminal in the root directory of your source and type:
watch -n1 -d prebuilts/misc/linux-x86/ccache/ccache -s
First build using ccache may be a little much longer but the others will be faster...
veerndra said:
Hi,
I followed the steps provided on source.android.com to build and flash the AOSP for Nexus 7 3G Tilapia. After successful flash, the device does not show anything after Google logo. Please help me out.
Thanks,
Veeren
Click to expand...
Click to collapse
Did you pull the proprietary files for your nexus and include them in the build? I believe things like your video drivers are included in there, so if those are missing....
I think the prop files are available for download from Google on source.android.com... If not, they tell you how to use an included script to pull them via adb. I can't remember... It's been a while since I built vanilla AOSP.
Sent from my Inspire 4G using xda app-developers app
Modifying stock AOSP
I have built AOSP following the Google tutorial.
I am compiling using the master branch and
Code:
aosp_grouper-userdebug
.
I have downloaded and extracted the appropriate proprietary binaries.
I am modifying two files in the source tree (see attachments; search for "// MODIFICATION ADDED HERE" to find my changes). Will these changes work? I am using Eclipse, set up in the exact way the tutorial explains, and I am not receiving any new errors.
When I compile the source using the following commands
Code:
$ . build/envsetup.sh
$ lunch aosp_grouper-userdebug
$ make fastboot adb
and flash it to my device with
Code:
$ fastboot -w flashall
BEFORE my modifications, it works just fine. The android-info.txt file and all the image files are produced properly.
However, AFTER adding the modifications, the build completes with no errors, but android-info.txt and all image files are no longer produced.
Why am I experiencing these problems? What can I do to make it work the way I want?
P.S. YES, I am aware that my modifications are not secure; these are for my own purposes, not for a public build.
Recently Xposed modules were released for Android7 that gave me a relief for the proximity sensor problem in my device. Before that I used a recompiled dialer.apk from @digital0 (https://forum.xda-developers.com/showpost.php?p=69507586&postcount=253).
As the new Android builds for my device has released LINEAGEOS15, AIM ROM, AEX ROM. I was curious to use them all, the ROM's are working fine but the problem of proximity sensor for dialer came back. As there is no xposed module for Android 8 I had the only option to use the recompiled dialer.apk that I have mentioned above.
The problem starts here I cannot push the dialer.apk to my device using adb/fastboot tools it gives me the error that "adbd cannot run as root in production builds" (https://forum.xda-developers.com/showthread.php?t=833756) again I used this thread to do exactly what it said but It was a fail and In the Fastboot mode I get bootloader unlock:false but I'm running a custom ROM and custom RECOVERY that would not be possible with a locked bootloader.
So i decided to to insert the recompiled dialer.apk to priv-app in system folder of my ROM using Ubuntu(system.new.dat>system.img>system folder). I succeeded to keep the recompiled dialer.apk in the priv-app folder I repacked the folder to system.img>system.new.dat. Compressed all the files to .zip and flashed the ROM, booted the device and as soon as I open the dialer.apk it pops a message saying "Unfortunately app has stopped working".
and for the information I modified AIM ROM which had a dialer.apk(v.10) and mine was dialer.apk(v.3).
Any help will be appreciated. It is a long topic please don't stress out. I know should have changed my display but I'm curious to know why this is happening.
if anyone knows how to recompile a apk please help me.
You have to recompile the app for your version of Android.
How to recompile - get the sources for your Android (LineageOS I assume) version, patch the source (for cm14 it was packages/apps/Dialer/InCallUI/src/com/android/incallui/ProximitySensor.java file), then compile dialer - I used command "make Dialer DISABLE_DEXPREOPT=true WITH_DEXPREOPT=false".
Then the compiled apk was here - out/target/product/generic/system/priv-app/Dialer/Dialer.apk.
digital0 said:
How to recompile - get the sources for your Android (LineageOS I assume) version, patch the source (for cm14 it was packages/apps/Dialer/InCallUI/src/com/android/incallui/ProximitySensor.java file), then compile dialer - I used command "make Dialer DISABLE_DEXPREOPT=true WITH_DEXPREOPT=false".
Then the compiled apk was here - out/target/product/generic/system/priv-app/Dialer/Dialer.apk.
Click to expand...
Click to collapse
Any tutorial that can explain this process step by step.
There are tutorials how to compile LineageOS, you can use any, not specifically for your device, because you need to compile Dialer.apk only.
So can you elaborate it please. More specific how how to do it step by step @digital0
No, I am not writing tutorial how to compile LineageOS step by step, sorry. I can show commands which I used to compile (probably), but you have to adjust them to the new Android version:
repo init -u https://github.com/LineageOS/android.git -b cm-14.1
repo sync
patch
make Dialer DISABLE_DEXPREOPT=true WITH_DEXPREOPT=false
Edit: instead of cm-14.1 you will probably need to use lineage-15.0
See https://github.com/LineageOS/android/tree/lineage-15.0 for more information.
Thanks for the info I will start working on it and let you know when it is finished
Hi All,
I am interested in any ROM, preferably based on LOS, that has no GAPPS pre-installed?
Is there any such? nougat, oreo, and whatever P is... doesn't matter.
A follow-up question for the more technically advanced than I: why is this such a problem for PH1? I believe the PIXEL phones also have A/B partitions, and are supported by LOS
Thanks!
lleo_ said:
Hi All,
I am interested in any ROM, preferably based on LOS, that has no GAPPS pre-installed?
Is there any such? nougat, oreo, and whatever P is... doesn't matter.
A follow-up question for the more technically advanced than I: why is this such a problem for PH1? I believe the PIXEL phones also have A/B partitions, and are supported by LOS
Thanks!
Click to expand...
Click to collapse
The number of developers fixing issues on the pixel vs this phone is astounding...
rignfool said:
The number of developers fixing issues on the pixel vs this phone is astounding...
Click to expand...
Click to collapse
I do recognize that, but given similarities between devices, would not be possible to adopt the work done by those developers. Granted that I ask this with the knowledge of a noob.
To follow up are you saying that there is no such as GAPPS-less ROM for PH1?
lleo_ said:
I do recognize that, but given similarities between devices, would not be possible to adopt the work done by those developers. Granted that I ask this with the knowledge of a noob.
To follow up are you saying that there is no such as GAPPS-less ROM for PH1?
Click to expand...
Click to collapse
There are... But they come and go as far as updates and such...
The demand is for Google... And moar features without losing Google...
Now... What you can do/try is wander over to the Project Trebble area... I would assume that you will find a plethora of development...
You're gonna be wading in some unknown territory... And it'll be a mystery as to what works... And whether it's fixable... Good luck
EDIT: or... You can magisk yourself... And try NanoMod... I think that disables a ton of Google stuff and puts FOSS stuff in it's place...
Sir! Thank You for your post. At first I thought it was a joke, but I learned something today. The concept and related work of project Treble bypassed me. I have already a GApps-less LOS on my Ph1. Again thanks!
Don't know if this applies, but lots of ppl are successfully running GSIs on the Essential.
Maybe some of them are GAPP-less?
@lleo_ another thing you can always do, is run Stock Android and Debloat it and run it Gapp Free, just like any custom rom...
As they say YMMV (Your Mileage May Vary), and I found Stock Oreo to be more stable on the Essential, so I debloated it, made it Deodex and patched for Signature Spoofing and of course Gapp Free. I still have the Gboard, Contacts, Messeges, and Phone, but these can be removed and replaced easily, any and everything Google can be taken out.
See the screen shot...
DoR3M3 said:
@lleo_ another thing you can always do, is run Stock Android and Debloat it and run it Gapp Free, just like any custom rom...
As they say YMMV (Your Mileage May Vary), and I found Stock Oreo to be more stable on the Essential, so I debloated it, made it Deodex and patched for Signature Spoofing and of course Gapp Free. I still have the Gboard, Contacts, Messeges, and Phone, but these can be removed and replaced easily, any and everything Google can be taken out.
See the screen shot...
Click to expand...
Click to collapse
Hey can you explain how to debloat, is there a script for it. How do you patch it and deodex it.
Thanks
arjunv said:
Hey can you explain how to debloat, is there a script for it. How do you patch it and deodex it.
Thanks
Click to expand...
Click to collapse
These steps below, you're probably going to wonder, why do I need to Deodex and Signature Spoof just to debloat? Good point, you don't, but then you can only get so far away from Google in your system by not doing this. The point to this method is to have Signature Spoofing support in Android, where you can better utilize microg support, to have it as the alternative instead of Google.
The Deodex and Nanodroid-patcher support, only need to be performed if you are running Stock Android, or a ROM that has not been Deodex and doesn't support Signature Spoofing. This also doesn't have to be done, if you still want to run the Google Services/Framework.
If you only want to Debloat, then follow the Debloat section below.
For the Deodex, YMMV (Your Mileage May Vary), but it's been working great for me, so here goes!
I did this on Stock Oreo 8.1.0 which has both odex and vdex files in /system/framework, so I followed the VDEX method mentioned below.
This is going to be easy if you're a Linux User/Geek, if you are running Windows and have never done anything like this, and if you have both odex and vdex files on your phone in /system/framework, then I can do this for you if you want, unless you want to get into learning this.
If you want me to, then in TWRP, click Mount and click on System at the top to mount it and then run this command in the command prompt, I'm assuming you have adb/fastboot installed...
adb pull /system/framework framework If that doesn't work, it typically ends up being, adb pull /system/system/framework framework
I'm assuming your device is arm64, so then look in the directory; framework/oat/arm64/ or /arm, and attach the services.vdex file and I'll patch it for you.
Deodex & Signature Spoofing
1. Check /system/framework, do you see both .odex and .vdex files?
2. If you have both .odex and .vdex files follow the guide under VDEX, if you only have .odex files, then follow the ODEX section. Don't be confused by the guide as only having either services.vdex or services.odex. You are looking to see if all the files are one or the other or both.
https://gitlab.com/Nanolx/NanoDroid/blob/master/doc/DeodexServices.md
3. If you have both files and need to follow the VDEX method in Windows, then you'll need cygwin as stated on the vdexExtractor Github, and install zlib-devel from the cygwin installer. cygwin as stated on the site is a collection of GNU and Open Source tools, this allows you to compile the vdexExtractor source in Windows into the running program.
https://www.cygwin.com/
4. If you have to do the ODEX method the baksmali.jar and smali.jar are already built, there's a download for them on the GitHub page, and you'll need to have Java JRE installed.
http://www.oracle.com/technetwork/java/javase/downloads/jre8-downloads-2133155.html
Whether I'm patching it, or you follow one of the methods I've described, once this is done, you'll need to download the latest NanoDroid-patcher. This is what patches the Deodex ROM to apply signature spoofing support.
https://forum.xda-developers.com/apps/magisk/module-nanomod-5-0-20170405-microg-t3584928 - Stable Download (Nanolx)
Be sure to also grab NanoDroid-fdroid if you don't have F-droid installed. You might want to also grab NanoDroid-microG while you're at it, if you want to go for a real system Google Debloat too, but any concerns, or issues, please post on Setialpha's NanoDroid post for any microg support.
As soon as you're done with the Deodex steps, at the bottom the tutorials clearly state; unmount /system and flash the NanoDroid-Patcher, so uncheck System that you checked before in Mount, and now install/flash NanoDroid-patcher, TWRP > Install
If the device is not rooted, then make sure to root it with Magisk. Personally I find it best with the Essential to now boot to the bootloader, then boot back into TWRP. In TWRP flash NanoDroid-fdroid if you grabbed it, then the boot.img and then Magisk, then boot into the System.
Debloating Apps Systemlessly
1. Open Magisk Manager - Downloads - search for Debloater, then you should see Debloater (Terminal Emulator).
2. Reboot
3. Now you'll need a terminal emulator in Android because Debloater (Terminal Emulator) runs from the command line, it doesn't have a GUI. I recommend using Termux, it's a very powerful terminal emulator with lots of things going on about it. If you didn't install F-Droid as I mentioned before, then you should of noticed on the NanoDroid download link NanoDroid-fdroid, download this and flash/install it in TWRP.
4. Now with F-Droid, open it, go to Settings and turn on Expert mode and check Privileged Extension, then close and reopen F-Droid. Next, search for and install Termux.
5. Open Termux and at the command prompt type su for superuser access. On a side note, if you don't know, or have never used Termux, press and hold Vol UP on the phone and tap q on the keyboard which will give you some short cut options. But you'll want to go online to their Wiki and learn about the power of Termux.
6. Now simply type debloat and remove what you want. Remember if you make a mistake, you have Option 4 to reinstall what you removed by mistake.
That's all there is to Deodex, Signature Spoof Patching and Debloating apps systemlessly in Android.
If the VDEX/ODEX methods don't work for some strange reason, then you'll want to explore using SuperR's Kitchen to Deodex the rom, and most people recommend you get the donate version for better features and support.
https://forum.xda-developers.com/ap...dows-linux-superr-s-kitchen-v3-0-0-0-t3601702
Good Luck
DoR3M3 said:
These steps below, you're probably going to wonder, why do I need to Deodex and Signature Spoof just to debloat? Good point, you don't, but then you can only get so far away from Google in your system by not doing this. The point to this method is to have Signature Spoofing support in Android, where you can better utilize microg support, to have it as the alternative instead of Google.
The Deodex and Nanodroid-patcher support, only need to be performed if you are running Stock Android, or a ROM that has not been Deodex and doesn't support Signature Spoofing. This also doesn't have to be done, if you still want to run the Google Services/Framework.
If you only want to Debloat, then follow the Debloat section below.
For the Deodex, YMMV (Your Mileage May Vary), but it's been working great for me, so here goes!
I did this on Stock Oreo 8.1.0 which has both odex and vdex files in /system/framework, so I followed the VDEX method mentioned below.
This is going to be easy if you're a Linux User/Geek, if you are running Windows and have never done anything like this, and if you have both odex and vdex files on your phone in /system/framework, then I can do this for you if you want, unless you want to get into learning this.
If you want me to, then in TWRP, click Mount and click on System at the top to mount it and then run this command in the command prompt, I'm assuming you have adb/fastboot installed...
adb pull /system/framework framework If that doesn't work, it typically ends up being, adb pull /system/system/framework framework
I'm assuming your device is arm64, so then look in the directory; framework/oat/arm64/ or /arm, and attach the services.vdex file and I'll patch it for you.
Deodex & Signature Spoofing
1. Check /system/framework, do you see both .odex and .vdex files?
2. If you have both .odex and .vdex files follow the guide under VDEX, if you only have .odex files, then follow the ODEX section. Don't be confused by the guide as only have either services.vdex or services.odex. You are looking to see if all the files are one or the other or both.
https://gitlab.com/Nanolx/NanoDroid/blob/master/doc/DeodexServices.md
3. If you have both files and need to follow the VDEX method in Windows, then you'll need cygwin as stated on the vdexExtractor Github, and install zlib-devel from the cygwin installer. cygwin as stated on the site is a collection of GNU and Open Source tools, this allows you to compile the vdexExtractor source in Windows into the running program.
https://www.cygwin.com/
4. If you have to do the ODEX method the baksmali.jar and smali.jar are already built, there's a download for them on the GitHub page, and you'll need to have Java JRE installed.
http://www.oracle.com/technetwork/java/javase/downloads/jre8-downloads-2133155.html
Whether I'm patching it, or you follow one of the methods I've described, once this is done, you'll need to download the latest NanoDroid-patcher. This is what patches the Deodex ROM to apply signature spoofing support.
https://forum.xda-developers.com/apps/magisk/module-nanomod-5-0-20170405-microg-t3584928 - Stable Download (Nanolx)
Be sure to also grab NanoDroid-fdroid if you don't have F-droid installed. You might want to also grab NanoDroid-microG while you're at it, if you want to go for a real system Google Debloat too, but any concerns, or issues, please post on Setialpha's NanoDroid post for any microg support.
As soon as you're done with the Deodex steps, at the bottom the tutorials clearly state; unmount /system and flash the NanoDroid-Patcher, so uncheck System that you checked before in Mount, and now install/flash NanoDroid-patcher, TWRP > Install
If the device is not rooted, then make sure to root it with Magisk. Personally I find it best with the Essential to now boot to the bootloader, then boot back into TWRP. In TWRP flash NanoDroid-fdroid if you grabbed it, then the boot.img and then Magisk, then boot into the System.
Debloating Apps Systemlessly
1. Open Magisk Manager - Downloads - search for Debloater, then you should see Debloater (Terminal Emulator).
2. Reboot
3. Now you'll need a terminal emulator in Android because Debloater (Terminal Emulator) runs from the command line, it doesn't have a GUI. I recommend using Termux, it's a very powerful terminal emulator with lots of things going on about it. If you didn't install F-Droid as I mentioned before, then you should of noticed on the NanoDroid download link NanoDroid-fdroid, download this and flash/install it in TWRP.
4. Now with F-Droid, open it, go to Settings and turn on Expert mode and check Privileged Extension, then close and reopen F-Droid. Next, search for and install Termux.
5. Open Termux and at the command prompt type su for superuser access. On a side note, if you don't know, or have never used Termux, press and hold Vol UP on the phone and tap q on the keyboard which will give you some short cut options. But you'll want to go online to their Wiki and learn about the power of Termux.
6. Now simply type debloat and remove what you want. Remember if you make a mistake, you have Option 4 to reinstall what you removed by mistake.
That's all there is to Deodex, Signature Spoof Patching and Debloating apps systemlessly in Android.
If the VDEX/ODEX methods don't work for some strange reason, then you'll want to explore using SuperR's Kitchen to Deodex the rom, and most people recommend you get the donate version for better features and support.
https://forum.xda-developers.com/ap...dows-linux-superr-s-kitchen-v3-0-0-0-t3601702
Good Luck
Click to expand...
Click to collapse
Thank you so much for a detailed post
DoR3M3 said:
@lleo_ another thing you can always do, is run Stock Android and Debloat it and run it Gapp Free, just like any custom rom...
As they say YMMV (Your Mileage May Vary), and I found Stock Oreo to be more stable on the Essential, so I debloated it, made it Deodex and patched for Signature Spoofing and of course Gapp Free. I still have the Gboard, Contacts, Messeges, and Phone, but these can be removed and replaced easily, any and everything Google can be taken out.
See the screen shot...
Click to expand...
Click to collapse
Stoked to see two things here...1.) the answer to the question I was searching for about running my Essential with no gapps...and 2.) your choice in file explorers!
We use SuperSU to root our tablets and I was wanting to modify it so that we could make additional modifications during install.
Is the source code for SuperSU publicly available?
This is the version we are using: SR5-SuperSU-v2.82-SR5-20171001224502
Just realized that update-binary is where the love is