Related
Questions? Use Q&A!
Please read the FAQ before reporting any bugs or errors!
If you post in the main thread not having read the FAQ or error message itself, not included a debug log when reporting a malfuction or reporting a Force Closure without a logcat, your post will be ignored by the developers!
Not because we are evil, but because the same questions keep popping up over and over again and too often we get a "X doesn't work, plz fix" without any clue what is happening. We don't have telepathic connection to your device and all the time unnecessarily wasted on this can't be spend on development of Open GApps itself.
The Latest builds of Open GApps for Android can easily be downloaded from the:
Open GApps Homepage -> All architectures & download options
Open GApps App
FAQ @ GitHub
Package comparison @ GitHub
Advanced Features and Options @ GitHub
Development Repository @ GitHub
I work on this project for FREE and putting in a lot of hours into it. While not mandatory, donations encourage me to continue to further pursue this project and I'd deeply appreciate them, if you feel generous.
Donate to The Open GApps Project
Are you a ROM developer and want to hotlink to the latest Open GApps package? Then check this wiki entry for details.
Please don't publicly mirror the prebuilt packages without explicit consent of @MastahF, to ensure that users will always be directed to the very latest version and the source code of the project.
About The Open GApps Project
Open GApps is a Google Apps package completely developed by writing buildscripts which allow for the automated creation of new up-to-date packages automatically.
The development process is completely open-source (GPLv3) and the goal is to have multiple contributors involved, to secure and reinforce the sustainability of Open GApps development.
Builds are generated every (European) night automatically (if there are any changes) and uploaded to GitHub.
Official AROMA Open GApps package is developed in collaboration with long-time LP-AROMA-developer @raulx222 and has a dedicated XDA thread
For any questions about the AROMA installer development, please refer to that thread. Of course, general support questions can also be asked in our own Q&A thread.
Official Open GApps For Stock support is developed in collaboration with @Rapper_skull and has a dedicated XDA thread
For any questions about the GApps for Stock development, please refer to that thread. Of course, general support questions can also be asked in our own Q&A thread.
The x86 package branch of the package is focused on Zenfone support and is maintained by @deadman96385 of the famous Zenfone GApps packages and has its own topic for x86 related questions
For those that cook their own ROM, an AOSP-build mechanism for Open GApps has been developed by @blystad and can be found at GitHub, remember that you should not bundle any pre-packaged Google Apps with any ROMs you want to distribute further though.
To gather all the various APKs that are necessary for the packages our master of the APK Universe @MNBooZe has written a tool called APKCrawler that scrape these from the internet, e.g. from APKMirror, it can be found at GitHub too.
Characteristic of Open GApps:
Some highlights about the characteristics of the Open GApps packages:
All platforms and and all Android versions are supported
DPI-optimized support for all Google packages (unlike other GApps)
Frequently updated Google Apps: The pre-built OpenGApps.org packages are updated every (European) night (if there are any updated Google Apps available)
Strong compression, allowing for relatively small downloads of even the most complete packages
Automatic backup: It is not necessary to re-flash Google Apps when you flash a ROM update. Most ROMs support this (addon.d) function
The installer checks your device’s capabilities, like the system partition size. It will notify you, before making any changes, if it finds any problems
Several package variations, from a Google Super Package (includes all applications that ever shipped on a Google device), to a Stock package that equals the set of applications found on the most current and complete Nexus, to smaller, minimalist packages and an AROMA package that allows graphically selection of what to install
A special ‘for Stock ROM’ installation mode that allows to update the Google Apps on Stock ROMs that conform to the original Google Nexus filesystem structure
All package installations can be customized to your individual preferences using our Advanced Features and Options
The idea behind this project:
I believe a big source of the problem for many GApps packages to stay up-to-date (or not be forfeited) is the lack of time for developers to do labour-intensive repetive every time a new google-app apk is released.
That is why I have taken it upto myself to write some Linux shell scripts to automate the packaging and to share these efforts with the world with the goal to create a team to continue this package together under the name Open GApps.
This project should not be managed by a person, but by a team, so volunteers willing to help are more than welcome!
Team management and projectleader: @[COLOR="blue"]MastahF[/COLOR]
Writing of the scripts: @[COLOR="blue"]MastahF[/COLOR] & @[COLOR="blue"]Rapper_skull[/COLOR] or check the team on GitHub and many other contributors
Updating GApp sources: @[COLOR="blue"]MNBooZe[/COLOR] & @[COLOR="blue"]DJAlik[/COLOR] & @[COLOR="blue"]bgiesing[/COLOR] & @[COLOR="blue"]mc1100[/COLOR] & @[COLOR="blue"]deadman96385[/COLOR] or check the team on GitHub
AROMA installer: @[COLOR="blue"]raulx222[/COLOR] using LibAroma
Custom compiled commandline tools: @[COLOR="blue"]YashdSaraf[/COLOR]
Website: @[COLOR="blue"]raulx222[/COLOR] & @[COLOR="blue"]MastahF[/COLOR] & signalv hosted by GitHub and created with Material Design Lite and JQuery
Artwork: @[COLOR="blue"]Yeti12[/COLOR]: Yeti-Designs website
Documentation: @[COLOR="blue"]Trafalgar-Square[/COLOR] and @[COLOR="blue"]MastahF[/COLOR] and many other contributors.
Open GApps installer uses open source third-party tools, like busybox and xzdec, compiled by @YashdSaraf; See his busybox thread for more info.
Open GApps is originally based on the now discontinued PA GApps package of @TKruzze and @osm0sis
I suggest to @hellowasif and @sir*mez to take a look at this
Hi, @provolinoo suggested me to take a look at this topic.
I made my own GApps, derived from PA GApps by TKruzze and without knowing I solved some problems that the people that were trying to continue the PA GApps are having.
I completely removed the sizes.prop file and now I measure the sizes of the apps on the fly using unzip. I took a look at your scripts and they're really useful, and reminded me that the APKs need to be zipaligned, which I forgot.
Maybe we can join your scripts, my changes, and a fast internet connection to bring PA GApps back to life.
If you're interested here's the link to my topic, please take a look at it: http://forum.xda-developers.com/android/general/alpha-gapps-stock-t3093389
Well i wanted to say thankyou so much for such wonderful work you did, Before this i was maintaining the PA-Gapps Packages PA Gapps 4.4.4 and PA-Gapps 5.X everything was going great and i must say i learned a lot by maintaining these Gapps packages and that was very wonderful experience but i was only updating Gapps and Libs, But than i realized that they weren't as perfect as the original gapps packages because the original Gapps package uses two important files which were size and libs list which the packages uses and they were the most important part of PA-Gapps. I tried to update these two files manually but they were two time consuming so i decided to drop this project due to lack of resources but by these scripts it will very easy to create Gapps Packages so i wanted to say thankyou again
Rapper_skull said:
Hi, @provolinoo suggested me to take a look at this topic.
I made my own GApps, derived from PA GApps by TKruzze and without knowing I solved some problems that the people that were trying to continue the PA GApps are having.
I completely removed the sizes.prop file and now I measure the sizes of the apps on the fly using unzip. I took a look at your scripts and they're really useful, and reminded me that the APKs need to be zipaligned, which I forgot.
Maybe we can join your scripts, my changes, and a fast internet connection to bring PA GApps back to life.
If you're interested here's the link to my topic, please take a look at it: http://forum.xda-developers.com/android/general/alpha-gapps-stock-t3093389
Click to expand...
Click to collapse
Hey, I looked at your work. Some things are indeed good improvements and I will try to incorporate them into my work if you don't mind.
I also looked at your sizes.prop solution, but honestly I don't like it that much, because although the calculation will be very exact, I don't think it is a good idea to unzip large files and pipe all this data through on our small little phones . I prefer to keep the sizes.prop estimations on the generating-side rather than on the execution-side.
I really would like you to be involved in the project, somebody else also already PMed on the forum, wanting to be involved. I described which tasks and roles are very welcome to be fulfilled within a joint team effort.
MastahF said:
Hey, I looked at your work. Some things are indeed good improvements and I will try to incorporate them into my work if you don't mind.
I also looked at your sizes.prop solution, but honestly I don't like it that much, because although the calculation will be very exact, I don't think it is a good idea to unzip large files and pipe all this data through on our small little phones . I prefer to keep the sizes.prop estimations on the generating-side rather than on the execution-side.
I really would like you to be involved in the project, somebody else also already PMed on the forum, wanting to be involved. I described which tasks and roles are very welcome to be fulfilled within a joint team effort.
Click to expand...
Click to collapse
Thank you for your appreciation. The files however are not extracted but I used "unzip -l" that lists the content of the archive with the file sizes. Keep me informed about this project.
hellowasif said:
Well i wanted to say thankyou so much for such wonderful work you did, Before this i was maintaining the PA-Gapps Packages PA Gapps 4.4.4 and PA-Gapps 5.X everything was going great and i must say i learned a lot by maintaining these Gapps packages and that was very wonderful experience but i was only updating Gapps and Libs, But than i realized that they weren't as perfect as the original gapps packages because the original Gapps package uses two important files which were size and libs list which the packages uses and they were the most important part of PA-Gapps. I tried to update these two files manually but they were two time consuming so i decided to drop this project due to lack of resources but by these scripts it will very easy to create Gapps Packages so i wanted to say thankyou again
Click to expand...
Click to collapse
Hi hellowasif,
would you be interested in collaborating then together with other people in a team to bring back PA Gapps using these scripts?
MastahF said:
Hi hellowasif,
would you be interested in collaborating then together with other people in a team to bring back PA Gapps using these scripts?
Click to expand...
Click to collapse
Yes that will be wonderful to work as a team and you count me in. :highfive:
Rapper_skull said:
Thank you for your appreciation. The files however are not extracted but I used "unzip -l" that lists the content of the archive with the file sizes. Keep me informed about this project.
Click to expand...
Click to collapse
Ah, then i misread your code, I will take a look at it then again. Anyhow, since the files in the package are static, I think at moment of generation is a good moment to get the file sizes
I have btw a question for you, a problem I was not able to resolve myself yet, even though trying a lot.
When creating the .zip-package to be signed and afterwards flashed, I am at the moment not using any compression (but use the -Z store flag).
If I use *any* kind of compression, the package refuses to flash at my phone (GT-i9300) with the message error executing update binary error.
I tried a lot of combinations, like using a different zip-application, compressing only the files outside META-INF etcetera, but nothing seems to work.
So my question is: how do you generate and sign your zip file? On which platform? With which application? With which parameters?
MastahF said:
Ah, then i misread your code, I will take a look at it then again. Anyhow, since the files in the package are static, I think at moment of generation is a good moment to get the file sizes
I have btw a question for you, a problem I was not able to resolve myself yet, even though trying a lot.
When creating the .zip-package to be signed and afterwards flashed, I am at the moment not using any compression (but use the -Z store flag).
If I use *any* kind of compression, the package refuses to flash at my phone (GT-i9300) with the message error executing update binary error.
I tried a lot of combinations, like using a different zip-application, compressing only the files outside META-INF etcetera, but nothing seems to work.
So my question is: how do you generate and sign your zip file? On which platform? With which application? With which parameters?
Click to expand...
Click to collapse
You will maybe laugh at my reply, but I simply use WinRAR, on Windows, with maximum compression. I do not yet sign the ZIPs because I wanted to generate my own private key instead of using the generic test-key. What you can try to do is update your recovery (if it's not updated) to see if the problem is solved.
dowloaded your GitHub project and ran through the scripts to create the signed zip file. So far everything is running smoothly. Did a full wipe. Great Job!
Question I have. Do you know why the com.android.vending is still installed in the user space (/data/app) vs system space?
Chrome doesn't seem to be working. It crashes every time I try to run it.
DJAlik said:
dowloaded your GitHub project and ran through the scripts to create the signed zip file. So far everything is running smoothly. Did a full wipe. Great Job!
Question I have. Do you know why the com.android.vending is still installed in the user space (/data/app) vs system space?
Click to expand...
Click to collapse
Thank you for your feedback, at the moment I was extracting the Play Store from a Nexus Image under the cryptic name of Phonesky.
I only found out just now that this Phonesky is the same as android.vending (the Play store) and updated this.
DJAlik said:
Chrome doesn't seem to be working. It crashes every time I try to run it.
Click to expand...
Click to collapse
Also thank you for your feedback. Using your feedback I discovered some nasty typos in my script which were breaking Chrome and Talkback.
I fixed those and will be uploading a new package later today. The fixes are already on github.
hellowasif said:
Yes that will be wonderful to work as a team and you count me in. :highfive:
Click to expand...
Click to collapse
Nice
Very happy to hear that! Tomorrow I will be heading for an island for a week, for holidays, so lucky for me, but unlucky for those interested in updates .
After that holiday I will set-up the basic infrastructure for the team.
I also thought about how to make packages for older android versions and I came up with the following solution that I will be then implementing next week:
*Within the SourceAPKs folder we will put some meta-data or an overlay that specifies the minimal SDK/API version that the package requires
*I will update the scripts in such a way that you can target various android versions, including such a sdk/api version.
*When building for a target, the highest version of the APK that still support that sdk/api version will be selected
*A seperate output directory will be created for each target
*All scripts will be executed from a single Makefile
E.g., the directory structure will look like:
SourceAPKs/18/com.google.android.apps.maps-9.8.1-908101124-minAPI18.apk
SourceAPKs/14/com.google.android.apps.books-3.3.41-30341-minAPI14.apk
Scripts/extract_sources.sh
Output/4.4/pa_unsigned.zip
Output/5.0/pa_unsigned.zip
Output/pa_gapps-4.4-20150504.zip
Output/pa_gapps-5.0-20150504.zip
Makefile
If anybody has any feedback on these ideas, you are welcome!
MastahF said:
Nice
Very happy to hear that! Tomorrow I will be heading for an island for a week, for holidays, so lucky for me, but unlucky for those interested in updates .
After that holiday I will set-up the basic infrastructure for the team.
I also thought about how to make packages for older android versions and I came up with the following solution that I will be then implementing next week:
*Within the SourceAPKs folder we will put some meta-data or an overlay that specifies the minimal SDK/API version that the package requires
*I will update the scripts in such a way that you can target various android versions, including such a sdk/api version.
*When building for a target, the highest version of the APK that still support that sdk/api version will be selected
*A seperate output directory will be created for each target
*All scripts will be executed from a single Makefile
E.g., the directory structure will look like:
SourceAPKs/18/com.google.android.apps.maps-9.8.1-908101124-minAPI18.apk
SourceAPKs/14/com.google.android.apps.books-3.3.41-30341-minAPI14.apk
Scripts/extract_sources.sh
Output/4.4/pa_unsigned.zip
Output/5.0/pa_unsigned.zip
Output/pa_gapps-4.4-20150504.zip
Output/pa_gapps-5.0-20150504.zip
Makefile
If anybody has any feedback on these ideas, you are welcome!
Click to expand...
Click to collapse
The idea of automating all the process is certainly good, but we have to keep in mind that things changes really fast. For example in an update Google can add a library to an application that previously didn't have one. We have to check if there's a lib folder inside the APK instead of assuming that all the APKs that now don't have libs will never have them. Also the idea of various app versions is very good, but also error prone. Maybe we can just put all the APKs in one folder and use the filename to determinate the app name and the minAPI (if we don't want to make a step further and read directly from the AndroidManifest.xml, using aapt).
MastahF said:
Thank you for your feedback, at the moment I was extracting the Play Store from a Nexus Image under the cryptic name of Phonesky.
I only found out just now that this Phonesky is the same as android.vending (the Play store) and updated this.
Also thank you for your feedback. Using your feedback I discovered some nasty typos in my script which were breaking Chrome and Talkback.
I fixed those and will be uploading a new package later today. The fixes are already on github.
Click to expand...
Click to collapse
latest commit:
$ sh make_package.sh
rm: missing operand
DJAlik said:
latest commit:
$ sh make_package.sh
rm: missing operand
Click to expand...
Click to collapse
You can ignore that error-message. I just delete all the temporary files of my text editor (ending with a ~) before packaging using this 'rm' command.
Rapper_skull said:
The idea of automating all the process is certainly good, but we have to keep in mind that things changes really fast. For example in an update Google can add a library to an application that previously didn't have one. We have to check if there's a lib folder inside the APK instead of assuming that all the APKs that now don't have libs will never have them. Also the idea of various app versions is very good, but also error prone. Maybe we can just put all the APKs in one folder and use the filename to determinate the app name and the minAPI (if we don't want to make a step further and read directly from the AndroidManifest.xml, using aapt).
Click to expand...
Click to collapse
Very good comments. I have been looking into the possibility of using aapt. With 'aapt d badging file.apk' I will be able to retrieve the API information and app/packagename from any apk.
Using this information I could make an add-script or an 'add-directory' that would scan any new apks and archives them automatically in a storage. This could help to maintain overview, and to automatically discard older versions of the app if the api-level is not changed. It could also allow for adminstation of x86 and arm64 packages in the tree.
So a 'storage' filetree could become in that case like:
/arm/packagename/api14/maps2.apk
/x86/packagename/api11/maps1.apk
/x86/packagename/api14/maps2.apk
My goal is also to indeed in the future to (more) automatically process the existence of a 'lib' and automatically incorporate into the output process. For this I will have (as within my goals set out for next week) to upgrade the process of generating the output folder. Because at this very moment the scripts still assume availability of (most of the) outputfolders to be there already.
MastahF said:
Very good comments. I have been looking into the possibility of using aapt. With 'aapt d badging file.apk' I will be able to retrieve the API information and app/packagename from any apk.
Using this information I could make an add-script or an 'add-directory' that would scan any new apks and archives them automatically in a storage. This could help to maintain overview, and to automatically discard older versions of the app if the api-level is not changed. It could also allow for adminstation of x86 and arm64 packages in the tree.
So a 'storage' filetree could become in that case like:
/arm/packagename/api14/maps2.apk
/x86/packagename/api11/maps1.apk
/x86/packagename/api14/maps2.apk
My goal is also to indeed in the future to (more) automatically process the existence of a 'lib' and automatically incorporate into the output process. For this I will have (as within my goals set out for next week) to upgrade the process of generating the output folder. Because at this very moment the scripts still assume availability of (most of the) outputfolders to be there already.
Click to expand...
Click to collapse
Exactly, in this way it would be possible to easily maintain arm64 and x86 packages too. The scripting is not complicated, it just requires some time. If you want I can contribute too (I had some experience with shell scripting). If the final scripts are not too long or complicated we can plan a Windows port too, if some future team member is not used to Linux.
We can also try to contact AP to request an RSS feed for new APKs on APKMirror.
EDIT: It seems that adding /feed to any URL will give you the corresponding RSS feed. Good to know.
Rapper_skull said:
Exactly, in this way it would be possible to easily maintain arm64 and x86 packages too. The scripting is not complicated, it just requires some time. If you want I can contribute too (I had some experience with shell scripting). If the final scripts are not too long or complicated we can plan a Windows port too, if some future team member is not used to Linux.
We can also try to contact AP to request an RSS feed for new APKs on APKMirror.
Click to expand...
Click to collapse
I've been using Cygwin on Windows and the scripts work great.
Hi all , I'm new here and I would like to present to you this simple application which backup, edit, repack and flash kernel.img or recovery img with a single click.
This apk need root.
All credit of unpak/repack tools used in my apk are to @osm0sis
atoxyd said:
Hi all , I'm new here and I would like to present to you this simple application which backup, edit, repack and flash kernel.img or recovery img with a single click.
This apk need root.
Click to expand...
Click to collapse
can I use this on snapdragon 615 stock kernel
Sent from my 6045X using Tapatalk
Yes, you can try
tested on htc desire 816, cm13
unpacks and repacks kernel and ramdisk successfully, but didn't extract or repack the dtbs (device tables image, kernel 3.4) so the repacked image won't boot.
Well I use in my apk AIK.mobile tools proposed by osm0sis.
atoxyd said:
Well I use in my apk AIK.mobile tools proposed by osm0sis.
Click to expand...
Click to collapse
https://github.com/osm0sis/AnyKernel2/ ?
from http://forum.xda-developers.com/showthread.php?t=2670512
bigsupersquid said:
tested on htc desire 816, cm13
unpacks and repacks kernel and ramdisk successfully, but didn't extract or repack the dtbs (device tables image, kernel 3.4) so the repacked image won't boot.
Click to expand...
Click to collapse
Hi, I test it on cm13 and I unpack recovery.img for HTC desire 816, I think it work fine.
If the apk didn't work properly that's means the boot image doesn't not following Google's standard format so you'll need to find other tools to unpack and edit your image.
atoxyd said:
Hi, I test it on cm13 and I unpack recovery.img for HTC desire 816, I think it work fine.
If the apk didn't work properly that's means the boot image doesn't not following Google's standard format so you'll need to find other tools to unpack and edit your image.
Click to expand...
Click to collapse
I can unpack, edit, and repack successfully.
but, it wont boot.
I used official twrp 3.0.0-0 recovery.img and cm13 boot.img both, tried without editing.
just unpack/repack/flash.
boots straight into hboot, which is what happens if I build a boot.img or recovery.img without dtbs.
I pointed to the anykernel2 link because I know its scripting handles dtbs.
the whole kernel device table thing is new to me, and so far only on this device, so I'm not very savvy with dtb work. been lucky enough that it was preconfigured in the build system for cm.
nero curin said:
can I use this on snapdragon 615 stock kernel
Sent from my 6045X using Tapatalk
Click to expand...
Click to collapse
Hi, did my apk work for you?
atoxyd said:
Hi, did my apk work for you?
Click to expand...
Click to collapse
only unpacking and repacking,didnt help on my device but yet again nothing else helps me compile kernel for this idol 3 so i guess this app works just not for me, bad luck :/
Sent from my 6045X using Tapatalk
Well, this is a beta version of my apk, only for testing, I use @osm0sis tools ,this doesn't mean that you have bad luck my friend, this is due to the limitation of @osm0sis tools, but I will find another way to make it universal apk. Okay
atoxyd said:
Well, this is a beta version of my apk, only for testing, I use @osm0sis tools ,this doesn't mean that you have bad luck my friend, this is due to the limitation of @osm0sis tools, but I will find another way to make it universal apk. Okay
Click to expand...
Click to collapse
The scope of my tools is for Google's Android image standard as defined in the bootimg.h header from AOSP/CM. My tool forks have the widest support available for images which are standards compliant, supporting all commonly used ramdisk compression formats.
Supporting Sony's ELF, MTK's labeled and Samsung's headerless image formats along with the standard images (not to mention Samsung's and others' various deviations based on the standard header) and having the script/app differentiate between them would be a very large and difficult undertaking indeed. If that's your plan then I wish you the best of luck in your efforts.
hey, ran more tests.
no issues with the dtb or other functions either.
backup and flash functions working fine too.
here, for your devices.xml
Code:
<!-- Desire 816 a5 (710C) added by bigsupersquid -->
<device>
<model>710C</model>
<kernel>/dev/block/mmcblk0p40</kernel>
<recovery>/dev/block/mmcblk0p41</recovery>
<cache>/dev/block/mmcblk0p42</cache>
</device>
thanks for your work.
eagerly awaiting your open source as well
atoxyd said:
Hi all , I'm new here and I would like to present to you this simple application which backup, edit, repack and flash kernel.img or recovery img with a single click.
This apk need root.
All credit of unpak/repack tools used in my apk are to @osm0sis
Click to expand...
Click to collapse
Thank you for adding the appropriate credit back to your post. Patching, cross-compiling and scripting has taken significant work. :good:
The only other thing that I'd ask is that you do not use the name of Android Image Kitchen or AIK in the title of your app. I'd like to suggest maybe "Image Editor and Flasher" as a snappy alternative?
bigsupersquid said:
hey, ran more tests.
no issues with the dtb or other functions either.
backup and flash functions working fine too.
here, for your devices.xml
Code:
<!-- Desire 816 a5 (710C) added by bigsupersquid -->
<device>
<model>710C</model>
<kernel>/dev/block/mmcblk0p40</kernel>
<recovery>/dev/block/mmcblk0p41</recovery>
<cache>/dev/block/mmcblk0p42</cache>
</device>
thanks for your work.
eagerly awaiting your open source as well
Click to expand...
Click to collapse
Thank you my friend , you are the only one who supported me , and from the beginning.
atoxyd said:
Thank you my friend , you are the only one who supported me , and from the beginning.
Click to expand...
Click to collapse
it's a useful project, definitely worth a little testing and feedback.
besides, i remember what a pain it was getting my xda account eligible for posting the project i was all gung-ho about sharing (optimus v boot from sd card if i remember correctly)
sharing is cool, but a lot of the feedback tends to be annoying when there's no logs or other usable information, just "it's broken" or "can you implement for me on device XYZ."
bigsupersquid said:
I can unpack, edit, and repack successfully.
but, it wont boot.
I used official twrp 3.0.0-0 recovery.img and cm13 boot.img both, tried without editing.
just unpack/repack/flash.
boots straight into hboot, which is what happens if I build a boot.img or recovery.img without dtbs.
I pointed to the anykernel2 link because I know its scripting handles dtbs.
the whole kernel device table thing is new to me, and so far only on this device, so I'm not very savvy with dtb work. been lucky enough that it was preconfigured in the build system for cm.
Click to expand...
Click to collapse
Did you have an unlocked bootloader ?
nothing changed on the device, unlocked and still s-on, I'm not sure what went wrong the first try.
PEBKAC error probably
(problem exists between keyboard and chair)
I release AIK&Flasher v2 , I use @xiaolu unpack/repack tools.
atoxyd said:
I release AIK&Flasher v2 , I use @xiaolu unpack/repack tools.
Click to expand...
Click to collapse
Please use a different name for your app as I have requested.
I have been playing around with kernels (for nexus 5), to add some features to the stock kernel. But I have problem with Samsung. I am trying to build a flashable custom kernel for Samsung S7 edge (G935F). .Steps I followed to create the boot.img are:
Get the stock source code (Samsung openSource)
Modify the kernel (just add/remove some TCP features)
Build the kernel (as per the kernel READ.ME, with aarch64-linux-android-4.9 toolchain)
-->created Image, with no loadable modules (*.ko)
Unpack the boot.img from the stock kernel (abootimg -x )
Create new boot.img replacing the original zImage with the custom kernel Image (abootimg --create . . . )
Make tar.md5 file of the custom boot.img for Odin3
Pushed the custom kernel using Odin3, but it fails to boot ("kernel not enforcing seadnroid"). I have tried using TWRP (install from zip), but it just does bootloop. Can anyone see what I am doing wrong? Am I missing something? I have read most of the "Build kernel from source" dev-threads but have not found a solution for this, nor am I allowed to post my questions there as I am just a junior member.
I would highly appreciate any help, as I have already invested some days with no avail
mdh-labs said:
I have been playing around with kernels (for nexus 5), to add some features to the stock kernel. But I have problem with Samsung. I am trying to build a flashable custom kernel for Samsung S7 edge (G935F). .Steps I followed to create the boot.img are:
Get the stock source code (Samsung openSource)
Modify the kernel (just add/remove some TCP features)
Build the kernel (as per the kernel READ.ME, with aarch64-linux-android-4.9 toolchain)
-->created Image, with no loadable modules (*.ko)
Unpack the boot.img from the stock kernel (abootimg -x )
Create new boot.img replacing the original zImage with the custom kernel Image (abootimg --create . . . )
Make tar.md5 file of the custom boot.img for Odin3
Pushed the custom kernel using Odin3, but it fails to boot ("kernel not enforcing seadnroid"). I have tried using TWRP (install from zip), but it just does bootloop. Can anyone see what I am doing wrong? Am I missing something? I have read most of the "Build kernel from source" dev-threads but have not found a solution for this, nor am I allowed to post my questions there as I am just a junior member.
I would highly appreciate any help, as I have already invested some days with no avail
Click to expand...
Click to collapse
I dont want to tell you something you have already read, if you have been through the Dev forums, But on the off chance:
Have you removed the Fingerprint reader?
The Kernel will fail to boot with it enabled, Unless you know the workaround (EchoTeam)
dave7802 said:
I dont want to tell you something you have already read, if you have been through the Dev forums, But on the off chance:
Have you removed the Fingerprint reader?
The Kernel will fail to boot with it enabled, Unless you know the workaround (EchoTeam)
Click to expand...
Click to collapse
Hmm ... Fingerprint reader? No, I have not removed anything. I was thinking that since I am not adding anything that was not already in the stock kernel source, I do not need to do any modifications. How can I remove this reader?
Here are the temporary solutions.
Way A:
Remove /system/lib/libbauth* , /system/lib64/libbauth*
Way B: (If you want to completely disable (or bypass) TEE)
Remove /system/lib/libbauth* , /system/lib64/libbauth*
Replace /system/lib64/hw/gatekeeper.exynos8890.so,/system/lib64/hw/keystore.exynos8890.so with these i uploaded.
Both of them will make your FP Sensor not working.
(Lock Screen will work)
But,at least,you get a stable custom kernel.
Click to expand...
Click to collapse
http://forum.xda-developers.com/s7-...m-g935f-fd-t3361460/post66762787#post66762787
Thank @Jesse Chan He also fixed the fingerprint too.
dave7802 said:
http://forum.xda-developers.com/s7-...m-g935f-fd-t3361460/post66762787#post66762787
Thank @Jesse Chan He also fixed the fingerprint too.
Click to expand...
Click to collapse
Thanks a lot, I will try that. I have already seen his custom kernel (would love to ask something on his thread but . . . )
mdh-labs said:
Thanks a lot, I will try that. I have already seen his custom kernel (would love to ask something on his thread but . . . )
Click to expand...
Click to collapse
I saw someone mention me.
Well, you must disable all TIMA-related configs as well as KNOX_KAP to get kernel boot.
And then, if you want to get a stable kernel with FP, you must apply my FP fix.(could be found in my Kernel's flashable zip)
Jesse Chan said:
I saw someone mention me.
Well, you must disable all TIMA-related configs as well as KNOX_KAP to get kernel boot.
And then, if you want to get a stable kernel with FP, you must apply my FP fix.(could be found in my Kernel's flashable zip)
Click to expand...
Click to collapse
I appreciate that you have had the time to look at my question. I've tried the tricks you suggested but my kernel still cannot boot. Modified the .config file (with menuconfig):
disabled
# CONFIG_KNOX_KAP is not set
# CONFIG_TIMA is not set
# CONFIG_TIMA_LKMAUTH is not set
not in config anymore
-CONFIG_TIMA_LOG=y
-CONFIG_TIMA_RKP=y
Then built a custom boot.img as mentioned in my question and added the META and mcRegistry folders from your flashable zip file to create a zip file out of the three.
I have also tried by removing the libbauth* files from system/lib/ and system/lib64 directories?
One more thing, does it matter whether I get just an Image file or zImage from kernel build (I get only Image and .gz of it)?
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!
Hi everyone. I'm scratching my head here and struggling to find a solution that doesn't require root.
I've got a hosts file that I love as it blocks nearly all advert servers on my phone.
I know there are several adblocking apps but they all require root.
I have had to remove root as I have some critical apps that still don;t work, even after hiding magisk from the apps within the Magisk Manager.
I've got a magisk patched image that I can "fastboot boot" with and can edit the hosts file (after remounting /system as rw) but when I then reboot afterwards, the hosts file has been overwritten.
Can anyone help me please or give me a pointer of how to make the hosts edits remain following a reboot?
edit2add
I am using stock ROM with latest August patches on my Mi A1
You can't without root even if you do it your system partition will be modified and it will result in phone not booting or just safetynet won't pass.
Use a vpn or I'm pretty sure there's app that can fake a vpn with a ad ban list
Dead-neM said:
You can't without root even if you do it your system partition will be modified and it will result in phone not booting or just safetynet won't pass.
Use a vpn or I'm pretty sure there's app that can fake a vpn with a ad ban list
Click to expand...
Click to collapse
Interesting idea regarding spoof VPN.
Do you know how the hosts file is generated? If it's copied over from somewhere during boot then could I edit the source file it's copied from?
If it's generated procedurally, might I be able to script it to add my edits during creation?
wodgey said:
Interesting idea regarding spoof VPN.
Do you know how the hosts file is generated? If it's copied over from somewhere during boot then could I edit the source file it's copied from?
If it's generated procedurally, might I be able to script it to add my edits during creation?
Click to expand...
Click to collapse
System partition ? so that's a good idea but you'll have to compile a rom to change this file. On Linux distro the host file is a thing you can modify easily. On android it's just deprecated by google as it's use mostly used as an adfilter. And google is an ad company. That's my guess.
Anyway host file will always need root even on Linux.
Simply because it can be used against you.
The problem is more on apps that blocks you because you're rooted than being rooted for changing this file.
If any app could modify host then bang you go to YouTube and it redirect you to something else.
Maybe for you it's just an adblock file but it's a little more than that.
So sorry but it's root or vpn.
Dead-neM said:
System partition ? so that's a good idea but you'll have to compile a rom to change this file. On Linux distro the host file is a thing you can modify easily. On android it's just deprecated by google as it's use mostly used as an adfilter. And google is an ad company. That's my guess.
Anyway host file will always need root even on Linux.
Simply because it can be used against you.
The problem is more on apps that blocks you because you're rooted than being rooted for changing this file.
If any app could modify host then bang you go to YouTube and it redirect you to something else.
Maybe for you it's just an adblock file but it's a little more than that.
So sorry but it's root or vpn.
Click to expand...
Click to collapse
So? Could I possibly extract the system.img from the stock ROM, make the edits there and then recompile?
(I've got a copy of payload.bin that I extracted a few weeks ago, when trying to flash the August security patches (this was before I did a compete flash of stock ROM using fastboot)
That actually seems like it wouldn't take too much effort
wodgey said:
So? Could I possibly extract the system.img from the stock ROM, make the edits there and then recompile?
(I've got a copy of payload.bin that I extracted a few weeks ago, when trying to flash the August security patches (this was before I did a compete flash of stock ROM using fastboot)
That actually seems like it wouldn't take too much effort
Click to expand...
Click to collapse
This will lead to a corrupt system partition modified. As i said the worse thing is you could not boot and the good just won't pass safetynet.
Dead-neM said:
This will lead to a corrupt system partition modified. As i said the worse thing is you could not boot and the good just won't pass safetynet.
Click to expand...
Click to collapse
Ok I understand.
How does the device 'know' that the system partition is corrupt? Does it perform a hash check perhaps?
How would compiling my own custom ROM avoid this same problem?
wodgey said:
Ok I understand.
How does the device 'know' that the system partition is corrupt? Does it perform a hash check perhaps?
How would compiling my own custom ROM avoid this same problem?
Click to expand...
Click to collapse
It does many thing to know that its have been touched. You'll have to modify some stuff and it will work. You'll loose certification but you'll have you own rom.
Dead-neM said:
It does many thing to know that its have been touched. You'll have to modify some stuff and it will work. You'll loose certification but you'll have you own rom.
Click to expand...
Click to collapse
Any chance you can outline the other stuff I'd need to change?
If it's really in-depth then don't worry but if it's just a few bullet-points that I can Google more info on, I'd appreciate it.
wodgey said:
Any chance you can outline the other stuff I'd need to change?
If it's really in-depth then don't worry but if it's just a few bullet-points that I can Google more info on, I'd appreciate it.
Click to expand...
Click to collapse
Search "dm-verity" and "safetynet". The first one is what will look at any r/o partition like system and kernel. It's been a long time since i dig into this. I'm not into this anymore.
But You can disable it but you'll loose safetynet, encrypted partition etc... (i may be wrong but you got the idea). And safetynet look if partition have been modified and you are a certified device if it won't pass the banking app and apps like Pokemon go etc won't work.
Magisk hide the fact that the kernel img have been touch and most app that detect it detect just the app itself. That means magisk capability (su, hide and module)
So you could maybe compile stock rom with a custom host file. Never touch vendor partition! Make a backup before! By booting and not flashing twrp. Do not flash twrp just use the "fastboot boot command"
You'll need to make a custom kernel and system img to flash in order to do it.
I'll try to do a rom without anything modded except kernel without dm verity and system with your host and i guess it needs change too.
I dunno if it will pass safetynet after.
Just don't brick your phone ?
Keep in mind that you'll loose ota. There's a chance that the rom work with just some changes but i can be a mess to do.
Why not trying a custom rom like lineage os?
Using their supersu zip won't you be able to replace the host file then remove root?
Once you make a backup a move it to a pc as a savestate. You are free to try different solution
Dead-neM said:
Search "dm-verity" and "safetynet". The first one is what will look at any r/o partition like system and kernel. It's been a long time since i dig into this. I'm not into this anymore.
But You can disable it but you'll loose safetynet, encrypted partition etc... (i may be wrong but you got the idea). And safetynet look if partition have been modified and you are a certified device if it won't pass the banking app and apps like Pokemon go etc won't work.
Magisk hide the fact that the kernel img have been touch and most app that detect it detect just the app itself. That means magisk capability (su, hide and module)
So you could maybe compile stock rom with a custom host file. Never touch vendor partition! Make a backup before! By booting and not flashing twrp. Do not flash twrp just use the "fastboot boot command"
You'll need to make a custom kernel and system img to flash in order to do it.
I'll try to do a rom without anything modded except kernel without dm verity and system with your host and i guess it needs change too.
I dunno if it will pass safetynet after.
Just don't brick your phone ?
Keep in mind that you'll loose ota. There's a chance that the rom work with just some changes but i can be a mess to do.
Why not trying a custom rom like lineage os?
Using their supersu zip won't you be able to replace the host file then remove root?
Once you make a backup a move it to a pc as a savestate. You are free to try different solution
Click to expand...
Click to collapse
Thanks for info I'll investigate later in the week when I have more time. Monday has arrived too quickly!
Appreciated though