Hello,
First of all, im new to android modding and linux. I tried to build a kernel from stock G935FXXU1BPH6 source based on their readme file. My problem is, I don't have a zImage file after build that I could put into a flashable zip. I only have Image and Image.gz (I guess thats normal for arm64 kernels?) and I don't know how to make them flashable. I found a youtube video where the dude placed the Image file in a directory called "tools" in his flashable zip, I tried it and TWRP said I installed it successfully but when I start up my phone and check kernel version its still the previous one not mine.
Used this toolchain: aarch64-linux-android-4.9/bin/aarch64-linux-android-
I've set up CROSS_COMPILE path, then I set up configuration:
make ARCH=arm64 exynos8890-hero2lte_defconfig
make menuconfig (to tweak it a little bit more, like custom kernel version string so I can see if it worked)
Then I started build:
make ARCH=arm64
Output when build finished:
>>>>> Time used for generated all hashes is 6 sec
OBJCOPY arch/arm64/boot/Image
GZIP arch/arm64/boot/Image.gz
DTC arch/arm64/boot/dts/exynos8890-smdk8890.dtb
DTC arch/arm64/boot/dts/exynos8890-universal8890.dtb
Anyone knows how could I make it flashable? Thanks.
keezay said:
Hello,
First of all, im new to android modding and linux. I tried to build a kernel from stock G935FXXU1BPH6 source based on their readme file. My problem is, I don't have a zImage file after build that I could put into a flashable zip. I only have Image and Image.gz (I guess thats normal for arm64 kernels?) and I don't know how to make them flashable. I found a youtube video where the dude placed the Image file in a directory called "tools" in his flashable zip, I tried it and TWRP said I installed it successfully but when I start up my phone and check kernel version its still the previous one not mine.
Used this toolchain: aarch64-linux-android-4.9/bin/aarch64-linux-android-
I've set up CROSS_COMPILE path, then I set up configuration:
make ARCH=arm64 exynos8890-hero2lte_defconfig
make menuconfig (to tweak it a little bit more, like custom kernel version string so I can see if it worked)
Then I started build:
make ARCH=arm64
Output when build finished:
>>>>> Time used for generated all hashes is 6 sec
OBJCOPY arch/arm64/boot/Image
GZIP arch/arm64/boot/Image.gz
DTC arch/arm64/boot/dts/exynos8890-smdk8890.dtb
DTC arch/arm64/boot/dts/exynos8890-universal8890.dtb
Anyone knows how could I make it flashable? Thanks.
Click to expand...
Click to collapse
This particular chipset (64-bit Exynos) uses the uncompressed Image and a separate dtb.img file made from combining all the dtb revisions of your device codename and region into a DTBH format.
You can flash them using my LazyFlasher project.
See: https://github.com/jcadduono/lazyflasher
You will want to use the kernel-flasher branch. The kernel-flasher-samsung branch isn't fully ready and adds additional patch files to remove TIMA/Knox. I've yet to find out everything that needs to be changed from stock state to allow a bootable custom kernel without disabling encryption, unfortunately.
You can simply git clone it, then place your Image and optionally dtb.img in the root folder of the repository, then type "make" to build a TWRP flashable zip. They will be dynamically replaced in the current boot image on the device when the zip is flashed. You can check out the README.md for more info.
If you want to generate your own dtb.img to include in the installer, you can use a script I made from my universal8890 kernel sources on GitHub:
https://github.com/jcadduono/android_kernel_samsung_universal8890/blob/stock-6.0/dtbgen.sh
(correct the toolchain location for your build in the script)
It also requires the scripts/dtbTool folder (from the same git linked above) to be present in your repository. It's not the same as the Qualcomm dtbTool, and the sources are included (and fairly clean!) if you're interested in learning the Exynos dtb.img (DTBH) format.
./dtbgen.sh hero2lte xx
Now, there's still quite a bit that needs to be done to make the device actually boot successfully and be stable with a custom kernel. While the kernel is perfectly stable, the Samsung customized Android OS will absolutely freak out. That's a bit beyond me, and the reason I haven't really worked on any custom kernels for it myself.
Have fun!
jcadduono said:
This particular chipset (64-bit Exynos) uses the uncompressed Image and a separate dtb.img file made from combining all the dtb revisions of your device codename and region into a DTBH format.
You can flash them using my LazyFlasher project.
See: https://github.com/jcadduono/lazyflasher
You will want to use the kernel-flasher branch. The kernel-flasher-samsung branch isn't fully ready and adds additional patch files to remove TIMA/Knox. I've yet to find out everything that needs to be changed from stock state to allow a bootable custom kernel without disabling encryption, unfortunately.
You can simply git clone it, then place your Image and optionally dtb.img in the root folder of the repository, then type "make" to build a TWRP flashable zip. They will be dynamically replaced in the current boot image on the device when the zip is flashed. You can check out the README.md for more info.
If you want to generate your own dtb.img to include in the installer, you can use a script I made from my universal8890 kernel sources on GitHub:
https://github.com/jcadduono/android_kernel_samsung_universal8890/blob/stock-6.0/dtbgen.sh
(correct the toolchain location for your build in the script)
It also requires the scripts/dtbTool folder (from the same git linked above) to be present in your repository. It's not the same as the Qualcomm dtbTool, and the sources are included (and fairly clean!) if you're interested in learning the Exynos dtb.img (DTBH) format.
./dtbgen.sh hero2lte xx
Now, there's still quite a bit that needs to be done to make the device actually boot successfully and be stable with a custom kernel. While the kernel is perfectly stable, the Samsung customized Android OS will absolutely freak out. That's a bit beyond me, and the reason I haven't really worked on any custom kernels for it myself.
Have fun!
Click to expand...
Click to collapse
Thank you very much!
@jcadduono couldn't make the kernel boot after packing it with lazyflasher. I built a completely stock kernel from the mentioned source, pasted the "Image" (not the Image.gz) file in lazyflasher root and then used make command. Tried including "exynos8890-smdk8890.dtb" file as well. Same story. Not sure if I need anything else in the package or I made user mistake. Do you have any ideas how could I debug what makes it stuck on that screen?
Thanks!
EDIT: Solved Problem.
keezay said:
@jcadduono couldn't make the kernel boot after packing it with lazyflasher. I built a completely stock kernel from the mentioned source, pasted the "Image" (not the Image.gz) file in lazyflasher root and then used make command. Tried including "exynos8890-smdk8890.dtb" file as well. Same story. Not sure if I need anything else in the package or I made user mistake. Do you have any ideas how could I debug what makes it stuck on that screen?
Thanks!
EDIT: Solved Problem.
Click to expand...
Click to collapse
Can you help me set up an environment to build a kernel, arm64, for s7? I'm on Ubuntu having a heel of a time..
Galaxy S7 Edge Kernel Flashing Issues
I am currently trying to flash a different kernel into a galaxy s7 edge (SM-G935S).
I have gone as far as building a kernel and extracting a Image file from it, but every time I try flashing a boot.img with a replaced kernel image file, it seems to never work.
A mkbootimg tool that I am currently using requires a dtb file, but I cannot find where to get it from.
I have tried using @jcadduono's git code, but the dtb file created from it doesn't seem to work as well.
Can anyone tell me what I should do to flash a kernel successfully?
kernel panic after flashing
Hi @ll,
with this guide I was able to compile my own kernel and also flashing it to my phone. Unfortunatelly I'm getting kernel panic after rebooting the phone. is there any possibility to get the reason for this? Or do you have any hint, what I may have done wrong?
Thanks for your help.
Kind regards
v0ti
Hey, I noticed while looking through the Stock Firmware AP file, that in meta-data/fota.zip there are .jar files that have to do with package signing. Only issue is that the zip is password protected. If someone has the Compute power and skills to decrypt a zip and look at the jar files and ****, maybe we could find a way to sign our own TWRP recoveries and roms. Just a thought, i'll post a link to the fota.zip file i was talking about in a bit if anyone wants to take a crack at it. (Google drive is taking forever to upload cause of AT&T's ****ty DSL speeds, sorry)
Download Link: htt*ps:/*/drive.*google*.com/file/*d/0B9tb-svjqaVD*b3Y0V0tXR3drSzA/vie*w?usp=sharing (Remove all *'s from link, stupid 10 post until you can post links limitation)
Thanks,
Lavavex
Did you saw this Thread?
https://forum.xda-developers.com/an...signing-boot-images-android-verified-t3600606
About fota.zip...
Did you heard about plain text attack?
In few Seconds... minutes done... no password required but you can unpack.
Best Regards
Yesterday I have download this fota.zip... and yes... same password as for instance from my prior test with:
SM-J330F and 1 more...
Here are the 3 keys to decrypt if somebody want try...
Code:
2b4d493c
6142b289
1b7024aa
Code:
Key0
Key1
Key2
I have used Advanced Archive Password Recovery from elcomsoft...
Best Regards
adfree said:
Yesterday I have download this fota.zip... and yes... same password as for instance from my prior test with:
SM-J330F and 1 more...
Here are the 3 keys to decrypt if somebody want try...
Code:
2b4d493c
6142b289
1b7024aa
Code:
Key0
Key1
Key2
I have used Advanced Archive Password Recovery from elcomsoft...
Best Regards
Click to expand...
Click to collapse
Which will allow unpacking of the above zip? I thought it needed a zip password.
osm0sis said:
Which will allow unpacking of the above zip? I thought it needed a zip password.
Click to expand...
Click to collapse
We never found the Password... but for Decryption you need only these 3 Keys...
They can be easily found in few Minutes... with the right Tool...
Code:
2b4d493c
6142b289
1b7024aa
Here Key0 Key1 Key2 for Samsungs fota.zip...
This is really no rocket science...
Simple read about plain-text attack...
You can see all filenames...
You can see all filesizes etc...
Many files are floating around the Internet... to create ZIP for attack...
Then result is in few Minutes possible... :angel:
Use these 3 Keys in Tool:
Code:
Advanced Archive Password Recovery
And try self to unpack...
Best Regards
Edit 1.
Screenshot added...
Then maybe more clear...
Trial Version have mabye limtations... but to see it work... it is enough to play with trial.
@adfree or to anyone who can answer.
Quick question, what are the legal limitations to what is going on here? I may or not have a file from inside the fota.zip, but will sharing it put me in the legal wrong? If it is within the legal boundaries, I'd be happy to upload it for anyone to take a look at, but I don't want to land on the wrong side of the law by doing so. Please do let me know, as this is the most exciting development we've had when it comes to bootloader unlocking in a while. Also, it seems as though we can't view the entirety of the contents of the fota.zip with the trial version of the zip extraction tool mentioned in this thread, so if someone with more knowledge about this can confirm we could unlock our bootloaders with the contents of the zip (based on what is currently known about this), I'd be happy to bite the bullet of paying for the premium version given we can do this within the boundaries of the law.
Thanks.
1.
Maybe you can answer your question self...
Samsung PROTECTED this ZIP with password.
2.
IMHO it is Kernel related...
Yeah I know... Boot is every irritating...
But it is not sboot.bin related...
3.
About decrypting all files...
There are floating around Command Line Tool...
Code:
pkcrack
Try to Google it...
I have not tried...
I am 1 click Button user...
Best Regards
zipdecrypt from the pkcrack package plus those 3 keys worked flawlessly. :good:
Edit: Crazy number of utilities in this zip, but no script to run them all, and a lot of references to external files. No smoking gun like a "sbootimg_signer" binary or anything to make their proprietary footer signature, and no Samsung signature files.
the password for that zip is fotatest1234
Correct. All fota zips passwords are fotatest1234
Drdra3 said:
Correct. All fota zips passwords are fotatest1234
Click to expand...
Click to collapse
@lavavex , @osm0sis
Yes it is, but now the question still to be answered is, do the tools within the fota.zip file, actually work for legitimately repacking the boot/recovery image? Because in the fota.zip I checked from Android Pie's release it mentioned the "user/test-keys" and very much so had all of the compiled tools to actually patch a system and create and ADB flashable zip for stock recovery.
Could we technically make a signed sideloadable update.zip if the the update package was created on the device itself? The scripts included, along with the updated compiled binary tools, really do seem to be the Toolkit we've been looking for but have overlooked. I haven't tested it out fully, but I'm still reading about how to proceed. It isn't just the S7 either. So are the tools customized to the device, the android branch, or the bootloader?
Delgoth said:
@lavavex , @osm0sis
Yes it is, but now the question still to be answered is, do the tools within the fota.zip file, actually work for legitimately repacking the boot/recovery image? Because in the fota.zip I checked from Android Pie's release it mentioned the "user/test-keys" and very much so had all of the compiled tools to actually patch a system and create and ADB flashable zip for stock recovery.
Could we technically make a signed sideloadable update.zip if the the update package was created on the device itself? The scripts included, along with the updated compiled binary tools, really do seem to be the Toolkit we've been looking for but have overlooked. I haven't tested it out fully, but I'm still reading about how to proceed. It isn't just the S7 either. So are the tools customized to the device, the android branch, or the bootloader?
Click to expand...
Click to collapse
Presumably what I previously said still stands:
osm0sis said:
Crazy number of utilities in this zip, but no script to run them all, and a lot of references to external files. No smoking gun like a "sbootimg_signer" binary or anything to make their proprietary footer signature, and no Samsung signature files.
Click to expand...
Click to collapse
THIS IS NOT A "HOW TO BUILD A KERNEL" POST
The Pixel 2, unlike other phones I've worked with, requires two extra tools: dtc (Device Tree Compiler) and mkdtimg.
Yes, dtc is available in the main repos for most linux distros, but the Pixel 2 kernel requires the AOSP modified version of dtc.
First, grab the Pixel 2 + XL Unified kernel source (wahoo) from https://android.googlesource.com/kernel/msm/+/android-msm-wahoo-4.4-oreo-dr1
Then download wahoo-kernel-tools.zip file attatched to this post and unzip it. Make sure that the 2 files in the bin folder are available in your path (possibly by moving them to ~/bin) and symlink or move the libc++.so into an included library directory, such as /lib, /usr/lib, or /usr/local/lib.
These specific binaries were compiled on Arch Linux by me, so they may not work on every system. To build binaries compatible with your system, sync any android oreo source (AOSP, Lineage, Carbon, etc.) and run "make dtc mkdtimage -jX" instead of "make bacon" or your normal command. The binaries will be located in out/host/linux-x86/.
This is tested and working with the stock google 4.9 toolchain and the initial source as of Oct 23rd, 2017.
frap129 said:
THIS IS NOT A "HOW TO BUILD A KERNEL" POST
The Pixel 2, unlike other phones I've worked with, requires two extra tools: dtc (Device Tree Compiler) and mkdtimg.
Yes, dtc is available in the main repos for most linux distros, but the Pixel 2 kernel requires the AOSP modified version of dtc.
First, grab the Pixel 2 + XL Unified kernel source (wahoo) from https://android.googlesource.com/kernel/msm/+/android-msm-wahoo-4.4-oreo-dr1
Then download wahoo-kernel-tools.zip file attatched to this post and unzip it. Make sure that the 2 files in the bin folder are available in your path (possibly by moving them to ~/bin) and symlink or move the libc++.so into an included library directory, such as /lib, /usr/lib, or /usr/local/lib.
These specific binaries were compiled on Arch Linux by me, so they may not work on every system. To build binaries compatible with your system, sync any android oreo source (AOSP, Lineage, Carbon, etc.) and run "make dtc mkdtimage -jX" instead of "make bacon" or your normal command. The binaries will be located in out/host/linux-x86/.
This is tested and working with the stock google 4.9 toolchain and the initial source as of Oct 23rd, 2017.
Click to expand...
Click to collapse
Thanks for the files dude, you saved me some serious time since I don't need to sync AOSP
DespairFactor said:
Thanks for the files dude, you saved me some serious time since I don't need to sync AOSP
Click to expand...
Click to collapse
No problemo, I figured I'd post this since my fastboot is being retarded and I can't do much else
Forgive me for being a noob, but would these new requirements for the Pixel 2 cause existing tools used to pack/unpack the boot image fail or at least partially fail? I'm wondering if this is why we can't get Magisk to work
edit: to be clear, when I unpack the boot.img file all I see are kernel and ramdisk. When I unpack the boot.img from the Pixel 1 XL, I see those same 2 files along with devicetree.dtb and kernelimage
skaforey said:
Forgive me for being a noob, but would these new requirements for the Pixel 2 cause existing tools used to pack/unpack the boot image fail or at least partially fail? I'm wondering if this is why we can't get Magisk to work
edit: to be clear, when I unpack the boot.img file all I see are kernel and ramdisk. When I unpack the boot.img from the Pixel 1 XL, I see those same 2 files along with devicetree.dtb and kernelimage
Click to expand...
Click to collapse
Maybe? It doesn't seem like how the boot image is packed has been changed, just how the actual kernel image is put together.
nathanchance said:
Maybe? It doesn't seem like how the boot image is packed has been changed, just how the actual kernel image is put together.
Click to expand...
Click to collapse
Strange. Thanks for the response though. In the Magisk thread here, someone has posted a boot image that was simply unpacked/repacked (no changes) and we can't get it to boot. I don't want to derail this thread any further though.
skaforey said:
Forgive me for being a noob, but would these new requirements for the Pixel 2 cause existing tools used to pack/unpack the boot image fail or at least partially fail? I'm wondering if this is why we can't get Magisk to work
edit: to be clear, when I unpack the boot.img file all I see are kernel and ramdisk. When I unpack the boot.img from the Pixel 1 XL, I see those same 2 files along with devicetree.dtb and kernelimage
Click to expand...
Click to collapse
skaforey said:
Strange. Thanks for the response though. In the Magisk thread here, someone has posted a boot image that was simply unpacked/repacked (no changes) and we can't get it to boot. I don't want to derail this thread any further though.
Click to expand...
Click to collapse
No they don't, these just build the dtb/dtbo. The magisk issue is with patching sepolicy likely.
frap129 said:
No problemo, I figured I'd post this since my fastboot is being retarded and I can't do much else
Click to expand...
Click to collapse
Did you try to flash a factory image and get stuck in the bootloader? If so, extract 'image-walleye-[build number].zip' and flash each image manually. fastboot -w update doesn't work for some reason. After you flash all the images, do fastboot format userdata, and you should be back to normal. Took me a couple hours to figure this out.
ryanbg said:
Did you try to flash a factory image and get stuck in the bootloader? If so, extract 'image-walleye-[build number].zip' and flash each image manually. fastboot -w update doesn't work for some reason. After you flash each image, do fastboot format userdata, and you should be back to normal. Took me a couple hours to figure this out.
Click to expand...
Click to collapse
Thanks! I don't get stuck in the bootloader, but it won't let me flash boot images. Fastboot either hangs or spits out "remote: error: max size not reported"
---
DISCLAIMER
The code published here is in a very early stage of development, and was published with the intention of receiving comments that allow me to improve it and develop a more stable version, it is not a software created with the intention that you install it on your device, much less on a different device, therefore, I am not responsible of dead or unusable devices.
I will not mention other users directly until I have finished this project, they will all appear in a list at the beginning of the publication where the final version will be
---
Project status: Starting over from 0.
I apologize for the delay, the protests in my country caused a compression of the university calendar to compensate for the lost time, the holidays officially began on December 17.
Here's a long and unnecessary context where I explain why I am doing this, you can skip it:
I recently changed the motherboard of my 5-year-old Yoga Tab 3, because it's still a good tablet, at least for seeing Netflix with a great audio quality, after replacing the old damaged card for a new one and flashing a clean version of android L with QFIL, I opened the task manager and saw [500MB of 1GB memory available], so I said “Wow, this is still great! If only I could have these numbers in a more modern version of android...”.
Android M is no longer usable in this tablet, the 32-bit processor equipped with 4 cores at 1.3ghz has aged very badly and the Android M experience has become terribly slow, so, updating the tablet is not an option.
But at that point, I remembered that for a while I used a phone with Android Oreo (Go Edition) out of the box, and personally I must say that I really enjoyed the experience. So, I looked at the little APQ8009 chip on my old and damaged motherboard, reasoned for a moment, and I said to myself: Why not?
I took my cell phone and searched "MSM8909 android oreo go" to see if anyone on XDA or another site had tried to develop something similar, but what I found was even more surprising:
The Lenovo Tab E10 (tb-x104f), a 10.1-inch tablet equipped with an MSM8909 processor, 1GB of RAM and 16GB of ROM and a screen resolution of 1280x800 (exactly the same specifications than the YOGA Tab 3!), and most importantly, Android Oreo (Go Edition) out of the box.
I never thought Lenovo would recycle their old plattforms to make new products, but they did it, and obviously this was an opportunity that I couldn't pass up.
This is my first post here, I hope to be welcome.
1) Original process, you might want to skip this point, I basically tried to port the ROM directly from the TB-X104F model (bad idea!):
- I downloaded two versions of the YT3-850F_S000025_151016 compilation of the YOGA Tab 3 from firmware247, one of them is OTA and the other is for flashing with QFIL.
- I downloaded the TB-X104F_S100050_200813 compilation of the E10 Tab from lolinet mirrors (QPST version)
This is because only QPST versions have been released for TB-X104F and not OTA versions, so I decided that I would get the system folder from the QPST files from both ROMs and not from the OTA files, but also, I needed the 850F OTA ROM to get an idea of what an X104F OTA ROM would look like, since I could try to rebuild it using files from the QPST version (which worked out very well).
To do that, I used two tools called packsparseimg and Imgextractor, developed by the members kidd (or kiddlu) and and_pDA, then published by Innfinite4evr and finally republished by the member zround, apparently this tool is no longer available on XDA, but I found it on a page called CaraRoot.
Here is a list with all the changes applied following the guide of The Hard Gamer and mshoaib7, I will highlight the important points.
(This guide was intended for porting Nougat roms, but I suppose it should work just as well for Oreo roms.)
- The META-INF folder did not exist in the rebuilt target rom so it was just copied from the base rom as the guide indicates.
- There is also no recovery folder, it was skipped.
- BIN, ETC, TTS, USR, XBIN and recovery-from-boot.p of the system folder were replaced by those of the base rom (ADDON.D does not exist in any of the 2).
- DRM, HW and SOUNDFX folders were replaced in the lib folder, inside system.
- All files named with LIBGLES*, LIBMM*, LIBHARDWARELEGACY, LIBRIL, LIBRILUTILS and LIBCAMERA* were replaced in the lib folder (there is no file named libwcnss_qmi, it was skipped).
- All files named with libactuator*, libchromatix*, libmmcamera*, libril*, liboemcamera and libimscamera were replaced in lib folder, inside vendor.
- The build.prop file of the target rom was replaced by the base rom file.
The following lines were modified:
ro.build.display.id=YT3-850F_OREO
ro.build.version.incremental=YT3-850F_OREO
ro.build.version.sdk=27
ro.build.version.preview_sdk=0
ro.build.version.codename=REL
ro.build.version.all_codenames=REL
ro.build.version.release=8.1.0
ro.build.version.security_patch=2020-08-05
ro.build.version.base_os=
(...)
ro.build.date=Thu Aug 13 16:55:25 CST 2020
ro.build.date.utc=1597308925
(...)
ro.build.flavor=hq_msm8909go-user
(...)
ro.product.ota.model=
(...)
#
# from device/huaqin/hq_msm8909go/system.prop
#
#
# system.prop for msm8909go
#
The following lines were not modified due to the paragraph that precedes them, I'm sure that not changing this will cause problems, but I don't know what else to do:
# Do not try to parse description, fingerprint, or thumbprint
ro.build.description=msm8909-user 5.1.1 LMY47V 387 release-keys
ro.build.fingerprint=Lenovo/YT3-850F/YT3-850F:5.1.1/LMY47V/YT3-850F_USR_S025_151016_Q1241_ROW:user/release-keys
ro.build.characteristics=tablet
ro.build.phonenumber.minmatch=
ro.build.network.type=wcdma_gsm
ro.build.water.mark=
ro.build.dulemode=
ro.hardware.version=60
ro.build.custom.swversion=YT3-850F_151016
ro.build.custom.hwversion=LenovoPad YT3-850F
and the following lines were not copied, but I'm curious to know what will happen if I do, comment below...
#
# ADDITIONAL_BUILD_PROPERTIES
#
ro.treble.enabled=true
- The boot.img was also modified, the changes were applied.
Additional changes that were not in the guide:
The splash.img, emmc_appsboot, rpm, sbl1 and tz files of the target rom were copied from the QPST folder to the rebuilt OTA folder.
¿Why? Because this is how they appear in the base ROM, I assumed they are necessary files, and the target ROM should have them too.
Also here are some files that the base rom has and the target rom doesn't:
file_contexts
NON-HLOS
data.new.dat
data.patch.dat
system.patch.dat
data.transfer.list
I also thought to include the recovery.img, but that would remove TWRP.
2) The current process:
- Install Ubuntu
- Create a working directory
- Download the Android Oreo source code and if possible Oreo Go directly and combine it with the Lenovo source code (which contains everything related to hardware).
- Compile and test.
3) The files.
Here you will find a direct access to my drive, where you will find everything related to the project.
Project Yoga Tab 3 Oreo
That way and if you are interested in collaborating, you can do more things with them and post your recommendations in this thread. Also don't forget that below you can let me know if I forgot to do something, or if there is anything else I need to do before trying to flash this on my new motherboard.
I hope you liked this work.
With the college exams so close, I hope it won't be long until I post an update at least.
See you soon!
SomeoneNormal07 said:
---
DISCLAIMER
The code published here is in a very early stage of development, and was published with the intention of receiving comments that allow me to improve it and develop a more stable version, it is not a software created with the intention that you install it on your device, much less on a different device, therefore, I am not responsible of dead or unusable devices.
I will not mention other users directly until I have finished this project, they will all appear in a list at the beginning of the publication where the final version will be
---
Here's a long and unnecessary context where I explain why I am doing this, you can skip it:
I recently changed the motherboard of my 5-year-old Yoga Tab 3, because it's still a good tablet, at least for seeing Netflix with a great audio quality, after replacing the old damaged card for a new one and flashing a clean version of android L with QFIL, I opened the task manager and saw [500MB of 1GB memory available], so I said “Wow, this is still great! If only I could have these numbers in a more modern version of android...”.
Android M is no longer usable in this tablet, the 32-bit processor equipped with 4 cores at 1.3ghz has aged very badly and the Android M experience has become terribly slow, so, updating the tablet is not an option.
But at that point, I remembered that for a while I used a phone with Android Oreo (Go Edition) out of the box, and personally I must say that I really enjoyed the experience. So, I looked at the little APQ8009 chip on my old and damaged motherboard, reasoned for a moment, and I said to myself: Why not?
I took my cell phone and searched "MSM8909 android oreo go" to see if anyone on XDA or another site had tried to develop something similar, but what I found was even more surprising:
The Lenovo Tab E10 (tb-x104f), a 10.1-inch tablet equipped with an MSM8909 processor, 1GB of RAM and 16GB of ROM and a screen resolution of 1280x800 (exactly the same specifications than the YOGA Tab 3!), and most importantly, Android Oreo (Go Edition) out of the box.
I never thought Lenovo would recycle their old plattforms to make new products, but they did it, and obviously this was an opportunity that I couldn't pass up.
This is my first post here, I hope to be welcome.
1) Preparing the ROMs to work.
- I downloaded two versions of the YT3-850F_S000025_151016 compilation of the YOGA Tab 3 from firmware247, one of them is OTA and the other is for flashing with QFIL.
- I downloaded the TB-X104F_S100050_200813 compilation of the E10 Tab from lolinet mirrors (QPST version)
This is because only QPST versions have been released for TB-X104F and not OTA versions, so I decided that I would get the system folder from the QPST files from both ROMs and not from the OTA files, but also, I needed the 850F OTA ROM to get an idea of what an X104F OTA ROM would look like, since I could try to rebuild it using files from the QPST version (which worked out very well).
To do that, I used two tools called packsparseimg and Imgextractor, developed by the members kidd (or kiddlu) and and_pDA, then published by Innfinite4evr and finally republished by the member zround, apparently this tool is no longer available on XDA, but I found it on a page called CaraRoot.
2) A list with all the changes applied following the guide of The Hard Gamer and mshoaib7, I will highlight the important points.
(This guide was intended for porting Nougat roms, but I suppose it should work just as well for Oreo roms.)
- The META-INF folder did not exist in the rebuilt target rom so it was just copied from the base rom as the guide indicates.
- There is also no recovery folder, it was skipped.
- BIN, ETC, TTS, USR, XBIN and recovery-from-boot.p of the system folder were replaced by those of the base rom (ADDON.D does not exist in any of the 2).
- DRM, HW and SOUNDFX folders were replaced in the lib folder, inside system.
- All files named with LIBGLES*, LIBMM*, LIBHARDWARELEGACY, LIBRIL, LIBRILUTILS and LIBCAMERA* were replaced in the lib folder (there is no file named libwcnss_qmi, it was skipped).
- All files named with libactuator*, libchromatix*, libmmcamera*, libril*, liboemcamera and libimscamera were replaced in lib folder, inside vendor.
- The build.prop file of the target rom was replaced by the base rom file.
The following lines were modified:
ro.build.display.id=YT3-850F_OREO
ro.build.version.incremental=YT3-850F_OREO
ro.build.version.sdk=27
ro.build.version.preview_sdk=0
ro.build.version.codename=REL
ro.build.version.all_codenames=REL
ro.build.version.release=8.1.0
ro.build.version.security_patch=2020-08-05
ro.build.version.base_os=
(...)
ro.build.date=Thu Aug 13 16:55:25 CST 2020
ro.build.date.utc=1597308925
(...)
ro.build.flavor=hq_msm8909go-user
(...)
ro.product.ota.model=
(...)
#
# from device/huaqin/hq_msm8909go/system.prop
#
#
# system.prop for msm8909go
#
The following lines were not modified due to the paragraph that precedes them, I'm sure that not changing this will cause problems, but I don't know what else to do:
# Do not try to parse description, fingerprint, or thumbprint
ro.build.description=msm8909-user 5.1.1 LMY47V 387 release-keys
ro.build.fingerprint=Lenovo/YT3-850F/YT3-850F:5.1.1/LMY47V/YT3-850F_USR_S025_151016_Q1241_ROW:user/release-keys
ro.build.characteristics=tablet
ro.build.phonenumber.minmatch=
ro.build.network.type=wcdma_gsm
ro.build.water.mark=
ro.build.dulemode=
ro.hardware.version=60
ro.build.custom.swversion=YT3-850F_151016
ro.build.custom.hwversion=LenovoPad YT3-850F
and the following lines were not copied, but I'm curious to know what will happen if I do, comment below...
#
# ADDITIONAL_BUILD_PROPERTIES
#
ro.treble.enabled=true
- The boot.img was also modified, the changes were applied.
3) Additional changes that were not in the guide.
The splash.img, emmc_appsboot, rpm, sbl1 and tz files of the target rom were copied from the QPST folder to the rebuilt OTA folder.
¿Why? Because this is how they appear in the base ROM, I assumed they are necessary files, and the target ROM should have them too.
Also here are some files that the base rom has and the target rom doesn't:
file_contexts
NON-HLOS
data.new.dat
data.patch.dat
system.patch.dat
data.transfer.list
I also thought to include the recovery.img, but that would remove TWRP.
4) The files.
this link should give you access to the folder on my drive where the 3 zip files are, the two base roms and the resulting oreo rom.
Project Yoga Tab 3 Oreo
That way and if you are interested in collaborating, you can do more things with them and post your recommendations in this thread. Also don't forget that below you can let me know if I forgot to do something, or if there is anything else I need to do before trying to flash this on my new motherboard.
I hope you liked this work.
With the college exams so close, I hope it won't be long until I post an update at least.
See you soon!
Click to expand...
Click to collapse
Hello looking forward to helping you in this project, as i do not know much about compiling android roms but as i own this device and been looking internet about any new rom or a way that we can still use this tablet
jimmy619 said:
Hello looking forward to helping you in this project, as i do not know much about compiling android roms but as i own this device and been looking internet about any new rom or a way that we can still use this tablet
Click to expand...
Click to collapse
You are welcome to help, although I don't know much about teamwork (especially online).
Ok, today I just installed this version with TWRP and surprise! Dead device!
(Revived with QFIL in an instant.)
With this experience I confirmed that I have definitely forgotten something...
SomeoneNormal07 said:
Ok, today I just installed this version with TWRP and surprise! Dead device!
(Revived with QFIL in an instant.)
With this experience I confirmed that I have definitely forgotten something...
Click to expand...
Click to collapse
I'll put a bit of context:
At the end, I have modified the lines that in the post I said that I did not want to modify, maybe that caused the problem or contributed to it, in any case, I will repeat the experiment and be more careful with what I touch in buildprop.
Ok, there are bad news.
Based on the unformation I was reading, I was committing a huge hazing, it seems that porting a stock ROM to a device with another stock ROM is not a good idea at all, instead I should use an AOSP rom as a target, and last but not least, I'm trying to run android Oreo on this thing.
There is a lot of information out there about how the functioning of android changed with the arrival of Treble, on the one hand, there are those who say that porting ROMs from one device to another has become much easier with Treble, and it is true, but mainly for the devices that already support Treble, for the rest of the devices (as this tablet), that will be more complicated.
My hopes are now based on a comment from an XDA member with a tb-X104F claiming to have flashed Lineage OS 15.1 and another member claiming to have flashed Resurrection Remix, both are different Roms than stock so I should be able to use one of them as a base.
My questions now are:
Do I need a copy of the rom already installed on your devices to work on it or will it be enough to just download the generic image of Lineage OS / Resurrection Remix?
Will the port to android Oreo work or do I need to add files to ROM?
(I hope I have enough time on vacation to investigate all of this)
Then, I must create an update script, (which the Lollipop firmware has but does not say anything that it should say, also the Oreo firmware does not have one because there is not a Meta-Inf folder, my last hope is to find a updater script in the Marshmallow firmware)
Finally, something very strange happens with version 2.8.7.7 of TWRP, and it is that no matter how hard I try, I cannot get it to install a different ROM than the official one, it install applications, install other recovery images, but don't install roms, no matter what I do, I actually tried modifying a few things in the stock ROM to see if those changes applied, and guess what, they don't! the system image is still intact, so now I feel pretty lost.
So, following the tutorials for this tablet, I will have to install Marshmallow and flash the modern version of TWRP (dark theme with blue) available for this tablet and try this again.
Extra: the last files I added weren't necessary either, what's more, I surely came close to ruining my tablet with that flash, I just need the Meta-Inf, system files, apparently a folder called install (which I can't find anywhere but surely contains apps or something like this), a recovery folder (which would delete TWRP but I suppose it is necessary), the boot.img (the only thing that seems to have been done right) and finally the file_contexts.bin file (from I don't know which of the 2 tablets).
Ok guys, some things happened in the short time since i published the last update, I found the solution to the problem with TWRP (SPOILER: another huge hazing).
Along the way I learned a bit about how to write updater-scripts, and now I have a 100% flashable file, the problem now is that the OS does not load and it returns me to TWRP.
But I haven't given up yet, I'll keep working in this until it works.
Now I would like to dig a little more into the hardware files, bloatware and how Lenovo's signature and security work.
the file was android 5 wtf
If you mean the yt3-850f file in the folder, that's android 5.1.1
Excuse me, I deleted the oreo file as soon as I realized my mistake, a new file will be available in a while with a changelog.
SomeoneNormal07 said:
If you mean the yt3-850f file in the folder, that's android 5.1.1
Excuse me, I deleted the oreo file as soon as I realized my mistake, a new file will be available in a while with a changelog.
Click to expand...
Click to collapse
thanks
btw do you have a lineage os rom for the m model or is it possible to compile this to the "m" model?
(as in yt-850m)
Ok guys, here are some news.
I am completely sure that this thing will start, even so, I have prepared an alternative, in this link you will find some downloads of Lineage GSIs, the version "ARM32 A-only device with Android Go gapps" as I am reading inside the build.prop was made to work with 32-bit systems.
Now, as I have been researching and also testing on my own on this device, what we now need is a COMPILED KERNEL FOR THIS DEVICE that can run the ROM, since with the boot.img files and Android Image Kitchen for Windows 10 I am not able to get it to work in any way, so I will have to compile the kernel from 0, at first this may sound complicated, but luckily Lenovo published all the source code for both devices (for Linux), apparently including all the hardware files required for both boards on their support website.
So next on my to-do list is compiling the kernel, but here's when the bad news comes:
College is getting a bit heavy now, so I'll take a break from this project to put 100% of my attention on the exams.
But don't worry, before that, I have updated the project folder with new files, and also, I have prepared the next notes for you:
Through experimentation and research, I have learned how the android update works, here are some notes for other newbies on this topic.
As we already know, android is updated using a file called updater-script, found in /META-INF/com/google/android, in modern versions of this file (Android 5 onwards) we can find the following line:
block_image_update("/dev/block/bootdevice/by-name/system", package_extract_file ("system.transfer.list"), "system.new.dat", "system.patch.dat");
This is the line responsible for updating the system, it is a very simple method, and that is why I will adopt it to launch the rom, it is very important to have the 3 files that this code mentions in the ROM, otherwise, the system files will not be copied (TWRP will skip any command with missing files.)
The system.new.dat file can be created from our system folder using 2 Tools:
- The first one is Tool Unpack Repack 3.0, but I do not recommend it very much since the way it is made only allows you to directly convert .img files into .dat, and not a system folder directly to .dat, this happens because instead to unzip the rom directly to a folder that you can modify, the tool store the files for recompression in a hidden file called new.system.img, also the program should include a tutorial where it tells you that the size of the final image must be the same as the file in /System_Unpack/temp_working/new.system.img, because I spent about half an hour looking for the correct size.
- The second tool is IMG extractor, which in addition to creating .dat files can also create .img files that you can convert to .dat with the first tool in case you get an error with it, this tool is included with another program called Brotli Extractor.
To create system.new.dat, you need to have file_contexts from the /boot.img/ramdisk of the ROM you are building, and the system.transfer.list (you can find one in the update_files.zip), once the system.new.dat has been created, a new system.transfer.list should appear next to it, you must copy and replace this file in your ROM.
The Lollipop ROM has provided me a 0 byte system.patch.dat file, the sole purpose of which here is to allow the line of code to run, since there is nothing to patch.
Also, in the project folder you will find:
- Source code of both devices (the code of the tb-x104f is of the normal Oreo version, not Oreo go).
- ROMs (these are not flash files, you need to convert the system folder to .dat and add the META-INF folder and the patch and list files).
- Unzipped boot.img from both devices (Android L and M come from the YT3).
- system_test.zip, which is the image that I am trying to run (this time I used android 6 as a base instead of android 5).
skeyvin said:
thanks
btw do you have a lineage os rom for the m model or is it possible to compile this to the "m" model?
(as in yt-850m)
Click to expand...
Click to collapse
There are no "official" custom ROMs for this tablet, but it should be possible to compile them.
SomeoneNormal07 said:
There are no "official" custom ROMs for this tablet, but it should be possible to compile them.
Click to expand...
Click to collapse
any way how?
Hi guys,
thank you very very very...very much SomeoneNormal07 !!!!
I'm so happy to see that someone is investing his time on this project for this device (I've the model YT3-X90L, but I hope the ROM will work also for this model).
I cheer for you (unfortunately I am not a developer).
Thanks
Bye
Alex