Database Info

[HELP!] Velocity Cruz T301 Full Brick Recovery

Hi XDA,
so basically i bought a Velocity Cruz T301 recently and followed the known procedures for rooting, flashing ClockworkMod Recovery and custom rom (SJHill Rom v0.3).
before the full brick my device was at ClockworkMod 5 and rooted with SJHill Rom v0.3.
i installed CWM by flashing the zip in stock recovery, then succesfully rooted the device, finally wiped and flashed my custom rom
after major dissapointment in this tablets performance i decided i wanted to get rid of it.
So i downloaded the stock rom, wipe and flashed it onto the tablet...
the tablet turned off when it was finished (i think it was attempting to reboot) and never turned back on again...EVER! :good:
i cant even get to recovery
i tried flashing with adb and fastboot but the device is never even presents itselft to the computer.
i found out that you can boot the device into USB boot mode where you hold the "VOL -" (Volume Down) button and press the reset button and while connected to the computer (windows only) a "JZ4760 USB Boot Device" appears.
i did some googling and also found out that the T301 is based on similar tech to a bunch of tablets and they can all be modified by some software released by Ingenic called USBBootTool.exe
the tool is written in chinese and i cant decypher it all, though i found out how to use it based on its usage for other Ingenic based tablets
1.) you will need to disable driver signature verification (press F8 on boot of windows and toggle the setting, i hate rebooting too but it has to be done)
2.) boot your tablet into USB Boot Mode (hold down Vol - and press Reset button)
3.) install the driver for your device (included in the files below)
4.) with the tablet disconnected you would open the USBBootTool.exe
5.) select your tablet in the options and fill each box with the files needed to flash (files included below)
6.) reconnect the tablet while still in USB Boot Mode and the software will flash your device on detection
everything goes fine for me except when i get to the flashing part in the end.
when USBBootTool detects my tablet, it attempts to flash and gives me a stream of errors and never flashes my device.
i dont know what to do at this point. i have provided direct links to all the software im using and also links to where i got them.
any help would be appreciated, thank you to the XDA community in advance
>------------------- DOWNLOADS ------------------------<
USBBootTool.exe / Tablet Drivers (4725 / 4725B / 4740 / 4750 / 4755 / 4760 / 4770)
http://dl.dropbox.com/u/79196608/burn_tools_3.0.16.rar
obtained from - http://forum.xda-developers.com/showthread.php?t=1720621
Velocity Cruz T301 Update.zip (contains the system.img / data.img / mbr-xboot.bin files)
http://www.cruztablet.com/T301update.zip
obtained from - http://www.cruztablet.com/Article_861.php
SJHill Rom v0.3
http://www.androidfilehost.com/?fid=9390362690511176486
obtained from - http://www.slatedroid.com/topic/27583-rom-t301-sjhill-rom-17-feb-2012-download-link-updated/
ClockworkMod 5
http://files.androtab.info/ingenic/cwm/20120514/T301-recovery-signed.zip
obtained from - http://androtab.info/mips/ingenic/clockworkmod/

I have the same situation. I have gone through every menu in the USB Boot tool and to no avail am I able to recover my T100.

gmick is redoing the software because the coding is set up wrong. Once he gets that figured out there should be a fool proof unbricking method that we can follow. He is posting information over on Slate Droid if you want to take a look.

feyerbrand said:
gmick is redoing the software because the coding is set up wrong. Once he gets that figured out there should be a fool proof unbricking method that we can follow. He is posting information over on Slate Droid if you want to take a look.
Click to expand...
Click to collapse
ok post the link to the thread, and ill add it to the first post as a solution if its found to be a working one

JustSayTech said:
ok post the link to the thread, and ill add it to the first post as a solution if its found to be a working one
Click to expand...
Click to collapse
*Cross Post from SlateDroid* (but I can't post the link because XDA won't allow it)
I found out why the USB boot isn't working. Well, more appropriately I know where it fails but not exactly "why".
The USB Boot tool works like this:
1) Send x00 command (Get CPU Info)
2) Device responds with "JZ4760V1"
3) Host sends two binaries, stage1 and stage2. Stage 1 sets up memory stuff, and Stage 2 sets up USB flashing functions.
4) Host checks that the binaries executed by issuing another x00 command (Which serves as an "Are you still there?" function)
5) If the response is good, the host will flash the images, if the response is bad, it will abort.
Our devices are failing at step 4. The linux usb boot tools (xburst-tools) fail in an identical fashion.
I know that the first stage binary transfers and executes fine because if it didn't the device would be limited to 16k. The second stage is 120K and is transferred successfully. Once the second stage "execute" command is sent, the device crashes.
The second stage is also unique to the CPU type. I've used all of the binaries for JZ4760 I could find on the net and when that failed I cross compiled my own binary from source and it still crashed.
At this point I highly doubt I'll ever be able to fix it, and this completely explains why no one could get any usb recovery tool to work while others using similar devices could. I guess our board is modified just enough for ingenic's stock binaries to fail. Without knowing what's changed (getting Velocity Micro's source) we're SOL.
I can open it up again and solder on the serial header but I'm betting it's going to give me some generic "couldn't execute" message that isn't going to help me. I'll probably do this anyway though because I've come this far so what's the loss.

wow, i learned alot from that post, seems like writing a usbboottool-like application that can send the commands but also log and possibly bypass security checks etc but that def would take sometime. thank you for your insight, seems youve come the closest to cracking the case, actually you found the fault, hopefully your methods can eventually bring about a fix

JZ 4770
gmick said:
*Cross Post from SlateDroid* (but I can't post the link because XDA won't allow it)
I found out why the USB boot isn't working. Well, more appropriately I know where it fails but not exactly "why".
The USB Boot tool works like this:
1) Send x00 command (Get CPU Info)
2) Device responds with "JZ4760V1"
3) Host sends two binaries, stage1 and stage2. Stage 1 sets up memory stuff, and Stage 2 sets up USB flashing functions.
4) Host checks that the binaries executed by issuing another x00 command (Which serves as an "Are you still there?" function)
5) If the response is good, the host will flash the images, if the response is bad, it will abort.
Our devices are failing at step 4. The linux usb boot tools (xburst-tools) fail in an identical fashion.
I know that the first stage binary transfers and executes fine because if it didn't the device would be limited to 16k. The second stage is 120K and is transferred successfully. Once the second stage "execute" command is sent, the device crashes.
The second stage is also unique to the CPU type. I've used all of the binaries for JZ4760 I could find on the net and when that failed I cross compiled my own binary from source and it still crashed.
At this point I highly doubt I'll ever be able to fix it, and this completely explains why no one could get any usb recovery tool to work while others using similar devices could. I guess our board is modified just enough for ingenic's stock binaries to fail. Without knowing what's changed (getting Velocity Micro's source) we're SOL.
I can open it up again and solder on the serial header but I'm betting it's going to give me some generic "couldn't execute" message that isn't going to help me. I'll probably do this anyway though because I've come this far so what's the loss.
Click to expand...
Click to collapse
for my JZ4770 Earlier USB tool was flashing .img without any problem but for now it is saying "load cfg failed". "API downlaod failed' like dialogues and doesnt flash anything. Any idea? Thanks in advance!!

First restart your computer (actually restart it) then redownload the USB boot tool and save it in a completely new directory and use a different USB port
Sent from my Pokeball

Yes, I did
JustSayTech said:
First restart your computer (actually restart it) then redownload the USB boot tool and save it in a completely new directory and use a different USB port
Sent from my Pokeball
Click to expand...
Click to collapse
Yes, I tried with this suggestion. Rather I reinstalled xp and the tried again. But the dialogues are same. The history is like this. Was having ICS on JZ 4770. Formatted with usb tool and put JB updates. It was not sensing touch so reflashed another JB updates. Now the tab boots, it reaches to boot logo for around 12 seconds and restarts in stock recovery. While it is in booting stage it get detected by windows and adb also. In stock recovery mode it get detected by windows and in turn by adb also. If I tried to install updates through SD card it shows it had installed and reboots after completion. But again the same way it goes to boot logo and then back to stock JB recovery. It also boots in ingenic boot device mode and gets detected by USB burn tools. But when try to flash any of the ROM it gives the same dialogues "check cfg failed" "api download failed" "boot. fw failed" and cant flash anything.
Is there any tool which can be flashed or a script which can be used from SD card for completely formatting flash memory so that USB burn tool can flash required ROM?

can you flash the stock rom in recovery?

Managed using USB BOOT TOOL for ingenic JZ 4770 board in English
JustSayTech said:
can you flash the stock rom in recovery?
Click to expand...
Click to collapse
thanks man but I managed to boot the device. I used following USB BOOT TOOL for ingenic 4770 boards. The goodness with this tool, this is completely in English. You will know what you are doing. Even after opening the main window of the tool you can right click and then get another options(yes again in English). My problem with this device was bad blocks at 1024. In the options there is chance to force erase whole the nand partitions which I used and erased all the partitions thereby made all the partions available for flashing and readable by the tool. Then from File option selected stock rom files and flashed them. While flashing selected JZ4770 iNanad.ini file in manual configuration. This tool has really helped me to come out of the issue and will be useful for guys using JZ 4770 board.
http://www.4shared.com/rar/m1BUV5r2/USBBurnTool_20120401_for_relea.html

Got USBBootTool.exe kind of working.
1. Download the following file from Ingenic.
ftp * ingenic * cn/3sw/01linux/tmp/jz4770-20110610.rar
2. Download Applocale from Microsoft.
www * microsoft * com/en-us/download/details.aspx?id=13209
3. Extract the jz4770-20110610.rar and find the folder. (Using 7zip should keep the UTF encoding in Chinese)
20110610\04burn\20110524_4770_Programmer
4. Copy the folder 20110524_4770_Programmer to location you want to use it in.
5. Install Microsoft Applocale (Just in case, I don't think it is required)
Now Start Applocale and create a shortcut to USBbootTool.exe inside 20110524_4770_Programmer
中文(简体) is simplified Chinese option and should let you view the GUI correctly.
6. Now with the Applocale Shortcut created for USBbootTool.exe you can start the application with correct fonts.
Now this is where is breaks down.
TABLET-8 NAND FINAL BSP(S3 TEST) will allow you to read from it and write to it, but the CFG is off.
\tool_cfg\tablet-8-nand-final.ini is the configuration for it.
DO NOT CONNECT THE DEVICE WITH ANY OPTIONS CHECKED OR LOAD ANY FILES.
See Attached Images.
Next to the Read button is some Boot Option menu. I am not fulling aware of what this does.
What I need is a someone to help me fix/correct the ini/cfg files in
\20110524_4770_Programmer\tool_cfg\.ini
\20110524_4770_Programmer\4760\
to correctly match the files of the NAND.
Also if anyone has a copy (dd to img) or (cat to img) of the block devices.
That would help a ton.
# cat /proc/partitions
# cat /proc/mtd
I would also love another T10x Tablet for cheap.
I want to start building things like new bootloader, kernel, system image,
performance libraries to take full use of the Ingenic JZ4760 (www * ingenic * cn/product.aspx?CID=11)
I also bring Christmas gifts
2 APKS. You can place them in /system/app or /data/app.
Google Play will crash now and again, but it will load and work. (Vending.apk)
Secondly I bring the gift of performance increase, just by a slight bit.
edit the line of the heapsize in /system/build.prop dalvik.vm.heapsize=96m
Remember to make sure the permissions are set back to 666 or 644.
Original Vending.Apk before updates came from here: (Incase you are paranoid)
code * google * com/p/ics-nexus-s-4g/source/browse/trunk/system/app/Vending.apk?spec=svn20&r=18
ics-nexus-s-4g * googlecode * com/svn-history/r18/trunk/system/app/Vending.apk
To prevent spam on the XDA forums, ALL new users prevented from posting outside links in their messages. After approximately 10 posts, you will be able to post outside links. Thank you for
Click to expand...
Click to collapse
Stupid. how do you expect real people to help post Tech Docs? That is bad Moderating and Administrating.
Make sure to replace the Asterisk's with spaces to normal dots.

Requesting Block Images.
Does anyone have a copy of it they can send me for a T10x?

block images......
IceGryphon said:
Does anyone have a copy of it they can send me for a T10x?
Click to expand...
Click to collapse
Which block images do you want?
...also is there a way to rip the stock images off the jz4760 in the t301.
Such as:
Can i usethe ingenic uboot tool?
Anybody find the jtag pins?
Is the 4 pin conn next 2 the batt for serial?
.......i guess ill try to take a look this weekend
Ics would be really nice, but probably slower than stock..... especially with the limited ram
I unpacked the stock rom. I also unpacked an ics rom for a jz4770, and repo sync'd the aosp and mips 3.0.8 android kernel.
I'm still trying to figure out specs for the processor though. I know that its mips32 - el- fp- r1, but i cannot figur out the dsp version ... if it has one?

Error in erasing nand
nanachitang420 said:
thanks man but I managed to boot the device. I used following USB BOOT TOOL for ingenic 4770 boards. The goodness with this tool, this is completely in English. You will know what you are doing. Even after opening the main window of the tool you can right click and then get another options(yes again in English). My problem with this device was bad blocks at 1024. In the options there is chance to force erase whole the nand partitions which I used and erased all the partitions thereby made all the partions available for flashing and readable by the tool. Then from File option selected stock rom files and flashed them. While flashing selected JZ4770 iNanad.ini file in manual configuration. This tool has really helped me to come out of the issue and will be useful for guys using JZ 4770 board.
http://www.4shared.com/rar/m1BUV5r2/USBBurnTool_20120401_for_relea.html
Click to expand...
Click to collapse
I used english ingenic tool to erase bad blocks but m nt able erase bad blocks live suit is giving eror id=0x4848

Signing boot images for Android Verified Boot (AVB) [v8]

Various Android devices support Android Verified Boot (AVB). A part of this is more commonly known as dm-verity, which verifies system (and vendor) partition integrity. AVB can however also verify boot images, and stock firmwares generally include signed boot images. Of course this does not mean that all signed boot images are using AVB, many OEMs have their own signature verification scheme.
Note: AOSP is moving towards the use of avbtool (taken from Brillo), the following is the old way for signing boot images.
Bootloaders might or might not accept unsigned boot images, and might or might not accept boot images signed with our own keys (rather than the OEM's keys). This depends on the device, bootloader version, and bootloader unlock state.
For example, with the bootloader unlocked, the Google Pixel (and XL) devices accepted unsigned boot images up to (but not including) the May 2017 release. From the May 2017 release onwards, the boot images must be signed if flashed (booted works without), but may be signed with your own key rather than the OEM's.
Note: The situation changes when you re-lock the bootloader. I have not tested this, but documentation implies that (one of) the keys used in the current boot image must be used for future flashes until it is unlocked again.
Generating custom signing keys
The following openssl commands generate all the keys we need. Execute them line-by-line rather than copying the whole block, as you will be asked for input.
Code:
# private key
openssl genrsa -f4 -out verifiedboot.pem 2048
openssl pkcs8 -in verifiedboot.pem -topk8 -outform DER -out verifiedboot.pk8 -nocrypt
# public key
openssl req -new -x509 -sha256 -key verifiedboot.pem -out verifiedboot.x509.pem
openssl x509 -outform DER -in verifiedboot.x509.pem -out verifiedboot.x509.der
For future signings, you do not need the .pem files, and they can safely be deleted once the .pk8 and .der files are generated. In AOSP's implementation, they were never even written to disk in the first place.
Security-wise, documentation states it is advisable to use a different set of keys for each device you support; though obviously this doesn't matter much if the device is running with the bootloader in unlocked state.
Signing the boot image
Download the attached BootSignature.jar file (built from AOSP sources), and sign the boot image using the keys generated above with the following commands:
Code:
java -jar BootSignature.jar /boot boot.img verifiedboot.pk8 verifiedboot.x509.der boot_signed.img
java -jar BootSignature.jar -verify boot_signed.img
Instead of /boot, /recovery and other values may be used. Their use should be obvious.
From Android
Attached is also BootSignature_Android.jar, which is a version ProGuard-reduced against SDK 21 and then dexed. Provided /system is mounted as is usual on Android (on the Pixel (XL), TWRP mounts this differently by default!), it can be used like this:
Code:
dalvikvm -cp BootSignature_Android.jar com.android.verity.BootSignature /boot boot.img verifiedboot.pk8 verifiedboot.x509.der boot_signed.img
dalvikvm -cp BootSignature_Android.jar com.android.verity.BootSignature -verify boot_signed.img
The base command can be extended as follows to make it able to run without any precompiled files present on the device:
Code:
/system/bin/dalvikvm -Xbootclasspath:/system/framework/core-oj.jar:/system/framework/core-libart.jar:/system/framework/conscrypt.jar:/system/framework/bouncycastle.jar -Xnodex2oat -Xnoimage-dex2oat -cp BootSignature_Android.jar com.android.verity.BootSignature ...
Flashable ZIP
Attached is also VerifiedBootSigner.zip, this is a flashable ZIP for FlashFire/TWRP/etc that signs the currently flashed boot image, if it isn't signed already. You can simply flash this after installing a SuperSU version or custom boot image or whatever that doesn't sign the boot image itself already.
I've tried to make it very portable (borrowing ample script from the SuperSU ZIP, as well as its signing keys), but I have only tested it on my Pixel XL.
Note that it does depend on Android files in the system partition, so if (aside from the unsigned boot image) your system isn't functional, the ZIP may not work either.
If the boot image is already signed when you flash the ZIP, it will offer to abort or force re-sign.
If you place custom.pk8 and custom.x509.der files inside the ZIP, these keys will be used for flashing instead of SuperSU's default keys. Additionally, /tmp/avb/custom.pk8 and /tmp/avb/custom.x509.der will override any keys from the ZIP.
There is some more documentation in the update-binary file inside the ZIP as well.
Note: If you're using TWRP's manual slot selection on the Pixel (XL), you must be using TWRP-v3.1.0-RC2 or newer, or it will not work as expected.
Todo
- test what happens when the bootloader is re-locked on multiple devices supporting AVB
- test what happens when dm-verity is kept enabled on a custom/modified boot image with a different image signature than dm-verity signature

-reserved-
*finally my dream come true, btw, nice job on doing this, keep it up man*

Super great

Great write up! So I take it we can no longer distribute kernel images without first integrating them into the boot image and then signing it? That negates the whole point of being able to flash the kernel individually with fastboot!

thank God Chanifire hasnt left us entirely!!!

This gives me hope my Pixel isn't dev dead. Thank you, CF!

@Chainfire you not going to reply but still, you are responsible i have faith in Android... Development is most of the times happens because of you ....It always revolves around you ... One man army i would say. Thank you for all your works. We all owe you a lot...

Is it possible to create the signature for boot bundle with openssl alone (i.e. without this BootSignature.jar ) ?

Wasn't self-signing boot images already kind of possible?

cr2 said:
Is it possible to create the signature for boot bundle with openssl alone (i.e. without this BootSignature.jar ) ?
Click to expand...
Click to collapse
Not just with openssl, no. How the boot signature works is not properly documented, but of course you could read the source in AOSP and make your own version.
mirhl said:
Wasn't self-signing boot images already kind of possible?
Click to expand...
Click to collapse
Apart from both of these things talking about signatures, they are unrelated. However, self-signing images has been supported for quite a while on several devices, it just wasn't required. CopperheadOS - as far as I know - is the only project that has actively been using it until now.

is it possible to sign the boot image in recovery?
Hi @Chainfire ! Thank you for this great find (and for everything else what you have done for us during the last years )!!
I would like to ask one question... Do you think it would be possible to sign the boot image on the fly in recovery? For example when changing the recovery image, before flashing the boot image back?
Your instructions use "dalvikvm" on android, and I ran the command successfully under a running android system. But what about recovery ?
I would be interested in your thoughts on this
Or am I completely wrong, and images "dumped" via dd can't be signed and flashed back?
I would really appreciate if you could point me in the right direction, how it could be possible to do this. (create an executable instead of the BootSignature.jar file? leave this, because it is not possible? start a java vm under recovery? ....)
Thanks in advance!

gubacsek said:
Hi @Chainfire ! Thank you for this great find (and for everything else what you have done for us during the last years )!!
I would like to ask one question... Do you think it would be possible to sign the boot image on the fly in recovery? For example when changing the recovery image, before flashing the boot image back?
Your instructions use "dalvikvm" on android, and I ran the command successfully under a running android system. But what about recovery ?
I would be interested in your thoughts on this
Or am I completely wrong, and images "dumped" via dd can't be signed and flashed back?
I would really appreciate if you could point me in the right direction, how it could be possible to do this. (create an executable instead of the BootSignature.jar file? leave this, because it is not possible? start a java vm under recovery? ....)
Thanks in advance!
Click to expand...
Click to collapse
Yes, this is possible - I have already tested this on my PIxel XL. SuperSU ZIP will do exactly this in a future update, and @Dees_Troy is also aware of all of this, so I assume TWRP will be updated to do this sooner or later as well.
If I can find the time I'll make a ZIP that does this.

Chainfire said:
Yes, this is possible - I have already tested this on my PIxel XL. SuperSU ZIP will do exactly this in a future update, and @Dees_Troy is also aware of all of this, so I assume TWRP will be updated to do this sooner or later as well.
If I can find the time I'll make a ZIP that does this.
Click to expand...
Click to collapse
Okay! I am very curious about how you solve it... Until then, I'll experiment a bit further
Can't wait to see your result!
Thanks! And have a very nice weekend!

I have attached a flashable ZIP to the opening post. Just flash it after SuperSU / custom boot image / whatever to fix the current boot image.
gubacsek said:
Okay! I am very curious about how you solve it... Until then, I'll experiment a bit further Can't wait to see your result!
Click to expand...
Click to collapse

Chainfire said:
I have attached a flashable ZIP to the opening post. Just flash it after SuperSU / custom boot image / whatever to fix the current boot image.
Click to expand...
Click to collapse
Thank you so much, it worked beautifully on my VZW Pixel with the May update.

:good: working fine on the May update with May bootloader, FK, TWRP and SuperSU
Outstanding as usual!

Chainfire said:
I have attached a flashable ZIP to the opening post. Just flash it after SuperSU / custom boot image / whatever to fix the current boot image.
Click to expand...
Click to collapse
I almost got it I could install TWRP and root but only by signing the boot images on my laptop...
I had a few errors (mounting /system did create a /system/system mount point, and I tried to copy the dalvikvm binary to the zip ), and I wouldn't ever have thought of clearing LD_LIBRARY_PATH
Thank you very much for this solution, and your time spent on this! I learnt a lot today
Nice job!

Chainfire said:
Various Android devices support Android Verified Boot (AVB). A part of this is more commonly known as dm-verity, which verifies system (and vendor) partition integrity. AVB can however also verify boot images, and stock firmwares generally include signed boot images. Of course this does not mean that all signed boot images are using AVB, many OEMs have their own signature verification scheme.
Note: AOSP is moving towards the use of avbtool (taken from Brillo), the following is the old way for signing boot images.
Bootloaders might or might not accept unsigned boot images, and might or might not accept boot images signed with our own keys (rather than the OEM's keys). This depends on the device, bootloader version, and bootloader unlock state.
For example, with the bootloader unlocked, the Google Pixel (and XL) devices accepted unsigned boot images up to (but not including) the May 2017 release. From the May 2017 release onwards, the boot images must be signed if flashed (booted works without), but may be signed with your own key rather than the OEM's.
Note: The situation changes when you re-lock the bootloader. I have not tested this, but documentation implies that (one of) the keys used in the current boot image must be used for future flashes until it is unlocked again.
Generating custom signing keys
The following openssl commands generate all the keys we need. Execute them line-by-line rather than copying the whole block, as you will be asked for input.
For future signings, you do not need the .pem files, and they can safely be deleted once the .pk8 and .der files are generated. In AOSP's implementation, they were never even written to disk in the first place.
Security-wise, documentation states it is advisable to use a different set of keys for each device you support; though obviously this doesn't matter much if the device is running with the bootloader in unlocked state.
Signing the boot image
Download the attached BootSignature.jar file (built from AOSP sources), and sign the boot image using the keys generated above with the following commands:
Instead of /boot, /recovery and other values may be used. Their use should be obvious.
From Android
Attached is also BootSignature_Android.jar, which is a version ProGuard-reduced against SDK 21 and then dexed. Provided /system is mounted as is usual on Android (on the Pixel (XL), TWRP mounts this differently by default!), it can be used like this:
Flashable ZIP
Attached is also VerifiedBootSigner.zip, this is a flashable ZIP for FlashFire/TWRP/etc that signs the currently flashed boot image, if it isn't signed already. You can simply flash this after installing a SuperSU version or custom boot image or whatever that doesn't sign the boot image itself already.
I've tried to make it very portable (borrowing ample script from the SuperSU ZIP, as well as its signing keys), but I have only tested it on my Pixel XL.
Note that it does depend on Android files in the system partition, so if (aside from the unsigned boot image) your system isn't functional, the ZIP may not work either.
Todo
- test what happens when the bootloader is re-locked on multiple devices supporting AVB
- test what happens when dm-verity is kept enabled on a custom/modified boot image with a different image signature than dm-verity signature
Click to expand...
Click to collapse
So are Samsungs latest devices now using this. Reason I ask is because in the S8 and Tab S3 stock firmware there is a META-DATA folder in the AP firmware tar. Inside is a fota.zip containing various folders with all sorts of utilities and files, one of which is BootSignature.jar.
It seems it is required to flash the META-DATA folder with the boot.img in ODIN or it will not boot. So I'm guessing the boot.img is being signed as part of the flashing process?

ashyx said:
So are Samsungs latest devices now using this. Reason I ask is because in the S8 and Tab S3 stock firmware there is a META-DATA folder in the AP firmware tar. Inside is a fota.zip containing various folders with all sorts of utilities and files, one of which is BootSignature.jar.
It seems it is required to flash the META-DATA folder with the boot.img in ODIN or it will not boot. So I'm guessing the boot.img is being signed as part of the flashing process?
Click to expand...
Click to collapse
Possibly. Which S8 are you talking about? I thought there was already working TWRP for S8 Exynos that didn't require anything special?

Chainfire said:
Possibly. Which S8 are you talking about? I thought there was already working TWRP for S8 Exynos that didn't require anything special?
Click to expand...
Click to collapse
New S8. Qualcomm Snapdragon 835 MSM8998 bootloader locked versions.
It's got an eng kernel available, but it's a no go with your s7 script due to no adb write access.
https://forum.xda-developers.com/galaxy-s8/how-to/rd-carrier-switch-root-snapdragon-t3597473/page54

[Patch] Persistent automatic disabling SELinux in any kernel

Warning: SELinux – important security feature.
After disabling it you obliviously make Android less secure. Use it on your own risk.
Why it needed?
SELinux can prevent work some mods, like Viper. Or you can have own reasons.
Executing in Terminal "setenforce 0" or via scripts / apps turns SELinux off only after booting: this is not good.
This solution disables SELinux directly in kernel.
Compatible with any MIUI or custom ROM.
How it works
After flashing ZIP creates kernel dump, then it repacks with new command line androidboot.selinux=permissive and writes back.
Into /system/bin copied script.sh and two binaries: mkbootimg and unpackbootimg plus auto-restore script (addon.d)
Last required for keeping and launching that files at every ROM update. This works only on custom ROM's, on MIUI you need re-apply patch manually.
Note: on previous phone at some rare unknown conditions after updating ROM kernel repackaging ended with error and device can't boot.
In this case enter recovery and restore boot from backup or flash boot.img from ROM via fastboot / TWRP.
How to install
1. Once flash attached ZIP
2. Then flash required mods
How to delete
1. Delete file /system/addon.d/99-selinux.sh (and other, that belong to mods that not work with SELinux)
2. Flash current ROM
P.S. This patch probably will work on any device (at least with custom ROM because stock kernel can use different structure).
Rare, but may be required change path to boot partition in script.sh: /dev/block/bootdevice/by-name/boot, twice.

Hi does this method still work in Android 10 and newer?
Great job. This is exactly what I was searching for!

lebigmac said:
does this method still work in Android 10 and newer?
Click to expand...
Click to collapse
Very likely, don't know for sure because still on Pie. Try yourself and share result

When I run this command:
Code:
cat /proc/cmdline
I get this result:
Code:
BOOT_IMAGE=/boot/vmlinuz-5.0.0-13-generic root=UUID=XXXXX-XXXX-XXXX-XXXX-XXXXXXXXX ro quiet splash vt.handoff=1
Maybe in Android 10 and newer they moved the androidboot.selinux=permissive parameter to somewhere else kind of like how they moved the system partition into the super image?

lebigmac said:
Maybe in Android 10 and newer they moved parameter to somewhere else
Click to expand...
Click to collapse
Parameter not present by default.
It's not clear if you tried to flash ZIP. If yes and got no result: probably script can't handle changes in boot.img structure because it was created 4 years ago. Try some tool on PC to unpack boot and add line manually.

[stock Rom] Blu G-90 G0310WW

Blu G90 device shipped from factory with Android 10
as with other devices from blu they do not have a public download of there roms. So here is the stock rom pulled from the device with SP-Flash tool.
Both the shipped rom build fingerprint
Code:
ro.bootimage.build.fingerprint=BLU/G90/G0310WW:10/QP1A.190711.020/1585383273:user/release-keys
And the ota update from June fingerprint
Code:
ro.system.build.fingerprint=BLU/G90/G0310WW:10/QP1A.190711.020/1592848714:user/release-keys
are in android file host flash-able with spflash tool, if needed.
I know the first thing to have before modifying android is the method to recover from bad edits. So here they are.
Other works will be stored in this same folder.
https://www.androidfilehost.com/?w=files&flid=315927
First stock rom is Dumped to github, If you need or want specific files, without needing to download whole rom.
https://github.com/mrmazakblu/blu_g0310ww_dump
Stock kernel source:
https://github.com/mrmazakblu/Blu_G90_G0310WW_stock_kernal
Device INFO
*******Above links are pulled firmware. Below is an official firmware file, w/ verified images.********
https://www.mediafire.com/folder/ocmvgrcd73bqy/G90
**
.

Bootloader unlock is same as past devices.
1. enable develper options
2. enable OEM unlock , from inside developer options
3. Reboot to bootloader (adb reboot bootloader, or button combo)
4. fastboot flashing unlock
5. Select confirm on device
6. fastboot reboot (causes factory reset)

Flashing GSI
few more steps than Pie devices, but not too complicated.
You will need recent fastboot tools as tested these steps were done with V30.0.4
https://developer.android.com/studio/releases/platform-tools
Verified boot is enabled on device. The verity key is stored into 3 section.
vbmeta.img
vbmeta_system.img
vbmeta_vendor.img
All found in stock rom. Shared in first post.
1. Unlock bootloader. (see last post)
2. Reboot to bootloader to disable verity
Code:
fastboot --disable-verity --disable-verification flash vbmeta vbmeta.img
fastboot --disable-verity --disable-verification flash vbmeta_system vbmeta_system.img
fastboot --disable-verity --disable-verification flash vbmeta_vendor vbmeta_vendor.img
3. Reboot from bootloader to fastboot(new interface for android 10)
Code:
fastboot reboot fastboot
4. flash sysem from "fastbootd"
Code:
fastboot flash system **gsi-system.img**
Use 64 bit AB GSI
5. Wipe data so the new system will work
Code:
fastboot -w

ROOT::
Not yet confirmed yet. Magisk patched_boot has not provided root as of yet.
Currently looking into pre-rooting the system.img, but not success yet.

TWRP;;
https://forum.xda-developers.com/android/development/twrp-twrp-3-4-0-0-blu-g90-g0310ww-t4163497
.

I have been able to edit the stock /system and flash it back to phone.
--I have added adaway host file
--Removed the SIMO app
-- Removed the IGNITE adware app (dti.blu)
--Removed The Verizon Remote SIM lock app
--Removed Blu-Privacy app
--Removed Opera browser app
--Deodexed Rom (rom would not boot past splash screen without this)
Uploaded edited sysem.img to device folder listed in OP.
Flash with same instructions as How to flash GSI
--Attempting to add SU binary makes rom fail to boot. So still no stock rooted.
Maybe soon.
/

Blu released kernel source today. 8-27. The tar.hz is dated April, eh, whatever.
I added the source files to the wip twrp tree, it compiles without error. (Not my normal experience , on first time out with Blu kernel).
But as mentioned before, the twrp will not pack the image correctly. Because of the need for new dtb commands that twrp 9.0 build environment does not accept.
And when building in the twrp 10.0-wip tree, the results have not booted for me yet. (I'm on build attempt 12, or so)
I'm rambling, sorry.
When I repack the twrp using the built kernel, twrp has only blank screen, and adb is active. So kernel is slightly off.
Build did not output separate dtb or dtbo.

Well I confirmed it, the screen on this phone is not the one the kernel is building for.
I compared the defconfig from source, the one that matches the name in build prop, to the one I pulled from /proc. And they are different, and the kernel errors out during build when using right defconfig. So, waiting again for Blu to provide the files.

There does not appear to be any interest in this phone, other than my own.
Well maybe it will catch on
It's been advertised on many mm ore locations than the average BLU phone.
Amazon
Ebay
Walmart
Newegg
Best buy
B&H photo
Time will tell.

mrmazak said:
Well I confirmed it, the screen on this phone is not the one the kernel is building for.
I compared the defconfig from source, the one that matches the name in build prop, to the one I pulled from /proc. And they are different, and the kernel errors out during build when using right defconfig. So, waiting again for Blu to provide the files.
Click to expand...
Click to collapse
Any luck with Blu providing the correct kernel files?

Ivisibl3 said:
Any luck with Blu providing the correct kernel files?
Click to expand...
Click to collapse
Not yet. They acknowledged my email, but as yet have not updated there posted source.

Root is half way achieved.
Factory rom was found. It included a boot-debug.img
When this image is used in boot partition, adb root is allowed.
It is only limited root. Example: blockdev command , used to allow remount / to rw, is not permitted. Bit is start.
Factory flashtool rom shared on Blu developers mediafire page.
Will add link to debug-boot.img soon
added to device folder listed in OP
google information on debug-boot.img
https://source.android.com/compatibility/vts/vts-on-gsi

if you have the stock boot.img, and magisk manager, why cant you patch the boot.img and then disable dm-verity by flashing vbmeta.img/vbmeta_system.img/vbmeta_vendor.img and then flash the boot.img via sp flash tool to give you root access?

aryanhington said:
if you have the stock boot.img, and magisk manager, why cant you patch the boot.img and then disable dm-verity by flashing vbmeta.img/vbmeta_system.img/vbmeta_vendor.img and then flash the boot.img via sp flash tool to give you root access?
Click to expand...
Click to collapse
because magisk init is not starting on a patched image. have no sign on magisk in the any of the logs.
the issue is posted on magisk github issue tracker. no solution as of yet.

mrmazak said:
because magisk init is not starting on a patched image. have no sign on magisk in the any of the logs.
the issue is posted on magisk github issue tracker. no solution as of yet.
Click to expand...
Click to collapse
why this that occurring, because for umidigi devices on android 10 work fine https://community.umidigi.com/forum.php?mod=viewthread&tid=19114 and they also use a mediatek chipset?

aryanhington said:
why this that occurring, because for umidigi devices on android 10 work fine https://community.umidigi.com/forum.php?mod=viewthread&tid=19114 and they also use a mediatek chipset?
Click to expand...
Click to collapse
different brand, so built differant. just like ther are redmi (xiamoi) devices with mtk, but fastboot unlock doe not work, it needs redmi app to unlock. and flash tool not work on all devices with MTK, like amazon fire device , they have mtk and do not work with fastboot unlock, or spflash.

mrmazak said:
I have been able to edit the stock /system and flash it back to phone.
--I have added adaway host file
--Removed the SIMO app
-- Removed the IGNITE adware app (dti.blu)
--Removed The Verizon Remote SIM lock app
--Removed Blu-Privacy app
--Removed Opera browser app
--Deodexed Rom (rom would not boot past splash screen without this)
Uploaded edited sysem.img to device folder listed in OP.
Flash with same instructions as How to flash GSI
--Attempting to add SU binary makes rom fail to boot. So still no stock rooted.
Maybe soon.
/
Click to expand...
Click to collapse
which steps did you take to modify the stock /system?

aryanhington said:
which steps did you take to modify the stock /system?
Click to expand...
Click to collapse
used superr script to unpack stock super.img and continued to extract system.img
manually went through the extracted system/system/app folder and deleated the aps I did not want (adware// bloate)
used the rom tools option / deodex
then repacked the system.img

aryanhington said:
why this that occurring, because for umidigi devices on android 10 work fine https://community.umidigi.com/forum.php?mod=viewthread&tid=19114 and they also use a mediatek chipset?
Click to expand...
Click to collapse
This is not entirely true.
Many Umidigi phones have been upgraded from 9 to 10. So the partitions would be very similar and considerably easy to root.
But for new phones coming with 10 the story changes. Read the last pages of your link's article. In addition, I know why and effect on Umidigi Power 3 still has limitations on root.
So this BLU G90 is not very different and depends on a lot of experimentation and tests. I believe that the OP is doing a great job mainly taking everything to github and trying to compile the kernel and firmware.

DragonPitbull said:
This is not entirely true.
Many Umidigi phones have been upgraded from 9 to 10. So the partitions would be very similar and considerably easy to root.
But for new phones coming with 10 the story changes. Read the last pages of your link's article. In addition, I know why and effect on Umidigi Power 3 still has limitations on root.
So this BLU G90 is not very different and depends on a lot of experimentation and tests. I believe that the OP is doing a great job mainly taking everything to github and trying to compile the kernel and firmware.
Click to expand...
Click to collapse
can you elaborate what you mean by this?

Question Many questions from a total Android newbie

Hi,
Although I passed my 40 I just bought my first smartphone a few week ago. It’s a Doogee S96Pro. As somebody who like to understand how it works, I already learn a few thing on the Android ecosystem.
I’ve been able to activate the developer mode and to use adb to uninstall some apps. I also managed to boot in fastboot mode to unlock the phone.
My first attempt at flashing was a fail, the phone was rebooting in a loop, indicating "Red state". I guess I should have never "fastboot flash boot/recovery foo.img" if "fastboot boot foo.img" didn’t work? What’s your opinion on this?
The Doogee support sent me a link to the files for my phone. In fact someone on this forum has had already posted it. The two archives are named :
S9S88A7.DGE.DOOGEE.EEA.HB.HJ.AYYDVFAZ.1130.V3.02.zip
S9S88A7.DGE.DOOGEE.HB.HJ.AYYDVFAZ.1203.V3.04.zip
To make the phone boot again I flashed the boot partition with the boot.img file I found in the second archive. If I understood what I read, the file with "EEA" in it’s name is the "European version" while the other one is the "Global version".
Although I flashed with the boot.img that was in S9S88A7.DGE.DOOGEE.HB.HJ.AYYDVFAZ.1203.V3.04.zip, if I go to the update info (About the phone > Update), I can see the string S9S88A7.DGE.DOOGEE.EEA.HB.HJ.AYYDVFAZ.0128.V3.03_20210128-1612. I don’t understand why this difference (v3.03 vs. v3.04).
Then I used the Magisk Manager to patch this boot.img file and flash it again. I now have root access on the phone which is nice.
Now the questions!
When booting the phone says: “Orange state, your phone’s unlocked”, then it boots normally. What’s the implication of this? I’m not sure but I think I tried to lock it again (fastboot flashing lock) but the message remains. Does it sound possible to you? I should check again this point…
In the Magisk Manager I also tried the "SafetyNet" check, which is refused. Is it OK? What does it imply? Why would I need to pass this SafetyNet test for?
I’m not sure I understood how the recovery thing works… I understand it’s another partition than "boot", and I know I can boot on it using the boot menu (pressing volume up when turning on the phone). What I don’t know is if it starts a recovering of the system automatically when booting on this partition (then erasing all data on the phone), or not.
Let’s say I flash the boot.img on the recovery partition (fastboot flash recovery boot.img). If I do a normal boot it should boot as usual, but if I boot on recovery it would boot on a virgin system. Am I right? Let says I configure nothing and reboot again, a normal boot this time. I then should get back to my usual, already configured system, as the "boot" partition hasn’t been modified. Is this also right?
Before doing anymore tests I would like to be able to backup an image with the phone already configured, with data and root access and applications. One (or maybe two or three?) file I can keep on my computer, and in case I break the boot on the phone, I could just fastboot flash boot my_custom_image.img to recover my phone configured. Oy maybe also flashing a "userdata" partition? Would I need some other partition? Is it more complicated than that?
It seems I have to identify the right partition(s) and carefully use dd to dump the partition to an image file… Before trying to do so I’d like to have some advice, hence this post!
Also. I read about a software called TWPR. Should I use it, and why ? I understand it’s a system aimed to be flashed on the recovery partition, is it right? What’s its use?
Finally I read about LineageOS which is the ultimate customization for the phone, it’s a “pure” Android, which is totally opensource (but it has to uses a lot of proprietary blob for devices AFAIK). I don’t think I’ll get there anyway. If I’m not mistaken it’s hard to do, especially with new phones nobody has ran LineageOS on, and there is something like no probability all the devices would work anyway.
Have a nice day.

there's no implication when you see "Orange state, your phone’s unlocked” unless you didn't the one who did it that means your device is tampered ..
also on SafetyNet is broad topic you can learn what it is here https://www.didgeridoohan.com/magisk/MagiskHideSafetyNet also
"Why would I need to pass this SafetyNet test for?" there are multiple reason such as you can't install banking apps,netflix, ...etc nor download them via playstore
moving on it is not recommend to backup userdata partition since it just contain all contains evidence of user activity. It contains call and SMS records, contacts, user-installed apps, app data, settings, and so-on-and-so-forth. In most newer phones, it also is likely to contain photos and videos and other user-generated files unless an external SD card is present. Also it would be impossible to restore userdata partition since android is encrypting it with unique key every time you set up your device https://source.android.com/security/encryption/full-disk
this prevent rooted application crawling on other application data such as paypal just stealing your login info and money
TWRP is like recovery mode but more feature packed (you can backup partition with it not available on stock recovery)
also experience is the best teacher you must experience failure to improve

ineedroot69 said:
Also it would be impossible to restore userdata partition since android is encrypting it with unique key every time you set up your device https://source.android.com/security/encryption/full-disk
this prevent rooted application crawling on other application data such as paypal just stealing your login info and money
Click to expand...
Click to collapse
With a simple ADB command you can decrypt Android partitions:
Code:
adb shell "recovery --set_encrypted_filesystem=on|off" <- enables / diasables encrypted fs

Hi,
Many thx for your answers.
also experience is the best teacher you must experience failure to improve
Click to expand...
Click to collapse
I can confirm that. I accidentally uninstalled the stock launcher with ADB. I’ve been able to install another launcher (I think I’ll keep on Nova Launcher). I tested a few (Launcher<3 and KISS Launcher), although they work fine none of them support switching between running apps. It’s a little bit annoying but I have another way to stop running apps (with App Manager). I guess the only way to get this functionality back is to flash again the boot partition with the Magisk patched image I already used, and to re-configure all the phone again (this is good to learn and luckily I don’t have important data in the phone yet).
Also it would be impossible to restore userdata partition since android is encrypting it with unique key every time you set up your device https://source.android.com/security/encryption/full-disk
Click to expand...
Click to collapse
Couldn’t be possible to dump both boot and userdata partitions and then flash them back both “at once”. The key for encrypting/decrypting the user data being contains in the boot (system ?) partition?
I realize Android has a bunch of security configuration you rarely find on a Linux server. Also the hardware is full of devices which require close-source firmware to operate. This is definitively not a good platform for hacking, like most PC are or a Rasberry Pi is . And I bet Windows and Apple phones are evermore closed…
About encrypting, I have a file called "googlekey/kb_0000000000.bin", which is the same in two archives the support sent me
$ md5sum S9S88A7.DGE.DOOGEE.*/googlekey/kb*
ead8a1d0f11e5f12bdda0f7a22935c2b S9S88A7.DGE.DOOGEE.EEA.HB.HJ.AYYDVFAZ.1130.V3.02/googlekey/kb_0000000000.bin
ead8a1d0f11e5f12bdda0f7a22935c2b S9S88A7.DGE.DOOGEE.HB.HJ.AYYDVFAZ.1203.V3.04/googlekey/kb_0000000000.bin
Click to expand...
Click to collapse
This file is not “per device” knowing every S96Pro users get the same archives. What’s its purpose?
I wonder the same for many files in this archive but I won’t bother you, I’ll make some search.
The one thing I’d like to understand is why the archive is labelled "1203.V3.04" and the system on my phone (after I flashed the boot partition with (a Magisk patched made from) the boot.img in this archive says : "0128.V3.03_20210128". Could it be related to the Magisk patching? (I didn’t check what I had with the stock boot.img). Or I have been downgraded by Google during install?
With a simple ADB command you can decrypt Android partitions:
Click to expand...
Click to collapse
Thx for this. What does it imply to do so? Will the Android system run with this unencrypted data partition? Is there a way to encrypt it again? (With ADB or directly in the phone?)
I’ve seen there are dozens of partitions on a running Android. So far this is what I understood (is this correct?) : There are three important partitions : boot, recovery and userdata. "boot" et "recovery" are the only ones the device can boot on (except booting from an image in fastboot mode using "fastboot boot boot.img"?). Are they some other important partitions this is important to be aware of?
Having a bootable "boot" and a bootable "recovery" partitions, it should be possible to install two different Android OS? I guess this is not possible and the "recovery" partition is dedicated to recovering (ie: reinstall the system) but I don’t understand how and why exactly. The encrypting thing maybe? The system must have a userdata partition and this one can’t be shared between to system…
I think I should buy an older Android smartphone to make all that kind of test, especially knowing I don’t have any other phone I can use for everyday use… Do you have some advice on brands and models which are more friendly with customization of the system?
Apart of ADB and fastboot, what are the other important tools to know about?
For Android development (I mean development of apps for Android), does everyone use an emulator? What’s the best option for such an emulator on Linux?
Have a nice day.

Marotte said:
For Android development (I mean development of apps for Android), does everyone use an emulator? What’s the best option for such an emulator on Linux?
Click to expand...
Click to collapse
My recommendation is GenyMotion for Linux. This emulator requires VirtualBox for Linux gets installed before.
Install GenyMotion
How To Install GenyMotion (Android Emulator) On Linux | 2DayGeek
2daygeek.com Linux Tips, Tricks & News today :- How to Install GenyMotion (Android Emulator) on Ubuntu, Debian, Linux Mint, openSUSE, Arch Linux, Fedora, CentOS, RHEL, Mageia, Manjaro
www.2daygeek.com
DL VirtualBox
Linux_Downloads – Oracle VM VirtualBox
www.virtualbox.org

Marotte said:
Having a bootable "boot" and a bootable "recovery" partitions, it should be possible to install two different Android OS? I guess this is not possible and the "recovery" partition is dedicated to recovering (ie: reinstall the system) but I don’t understand how and why exactly. The encrypting thing maybe?
Click to expand...
Click to collapse
Partitions /boot & /recovery explained:
/boot
This is the partition that enables the phone to boot, as the name suggests. It includes the kernel and the ramdisk. Without this partition, the device will simply not be able to boot.
/recovery
The recovery partition can be considered as an alternative boot partition that lets you boot the device into a recovery console for performing advanced recovery and maintenance operations on it.
That's what you can do from within the recovery console:
Reboot system now
Install ZIP from SD-card
Install ZIP from Sideload
Wipe data / factory reset
Wipe cache partition
Backup and restore

Hi,
Many thx for your answers.
also experience is the best teacher you must experience failure to improve
Click to expand...
Click to collapse
I can confirm that. I accidentally uninstalled the stock launcher with ADB. I’ve been able to install another launcher (I think I’ll keep on Nova Launcher). I tested a few (Launcher<3 and KISS Launcher), although they work fine none of them support switching between running apps. It’s a little bit annoying but I have another way to stop running apps (with App Manager). I guess the only way to get this functionality back is to flash again the boot partition with the Magisk patched image I already used, and to re-configure all the phone again (this is good to learn and luckily I don’t have important data in the phone yet).
Also it would be impossible to restore userdata partition since android is encrypting it with unique key every time you set up your device https://source.android.com/security/encryption/full-disk
Click to expand...
Click to collapse
Couldn’t be possible to dump both boot and userdata partitions and then flash them back both “at once”. The key for encrypting/decrypting the user data being contains in the boot (system ?) partition?
I realize Android has a bunch of security configuration you rarely find on a Linux server. Also the hardware is full of devices which require close-source firmware to operate. This is definitively not a good platform for hacking, like most PC are or a Rasberry Pi is . And I bet Windows and Apple phones are evermore closed…
About encrypting, I have a file called "googlekey/kb_0000000000.bin", which is the same in two archives the support sent me
$ md5sum S9S88A7.DGE.DOOGEE.*/googlekey/kb*
ead8a1d0f11e5f12bdda0f7a22935c2b S9S88A7.DGE.DOOGEE.EEA.HB.HJ.AYYDVFAZ.1130.V3.02/googlekey/kb_0000000000.bin
ead8a1d0f11e5f12bdda0f7a22935c2b S9S88A7.DGE.DOOGEE.HB.HJ.AYYDVFAZ.1203.V3.04/googlekey/kb_0000000000.bin
Click to expand...
Click to collapse
This file is not “per device” knowing every S96Pro users get the same archives. What’s its purpose?
I wonder the same for many files in this archive but I won’t bother you, I’ll make some search.
The one thing I’d like to understand is why the archive is labelled "1203.V3.04" and the system on my phone (after I flashed the boot partition with (a Magisk patched made from) the boot.img in this archive says : "0128.V3.03_20210128". Could it be related to the Magisk patching? (I didn’t check what I had with the stock boot.img). Or I have been downgraded by Google during install?
With a simple ADB command you can decrypt Android partitions:
Click to expand...
Click to collapse
Thx for this. What does it imply to do so? Will the Android system run with this unencrypted data partition? Is there a way to encrypt it again? (With ADB or directly in the phone?)
I’ve seen there are dozens of partitions on a running Android. So far this is what I understood (is this correct?) : There are three important partitions : boot, recovery and userdata. "boot" et "recovery" are the only ones the device can boot on (except booting from an image in fastboot mode using "fastboot boot boot.img"?). Are they some other important partitions this is important to be aware of?
Having a bootable "boot" and a bootable "recovery" partitions, it should be possible to install two different Android OS? I guess this is not possible and the "recovery" partition is dedicated to recovering (ie: reinstall the system) but I don’t understand how and why exactly. The encrypting thing maybe? The system must have a userdata partition and this one can’t be shared between to system…
I think I should buy an older Android smartphone to make all that kind of test, especially knowing I don’t have any other phone I can use for everyday use… Do you have some advice on brands and models which are more friendly with customization of the system?
Apart of ADB and fastboot, what are the other important tools to know about?
For Android development (I mean development of apps for Android), does everyone use an emulator? What’s the best option for such an emulator on Linux?
Have a nice day.
Have a nice day.
jwoegerbauer said:
My recommendation is GenyMotion for Linux. This emulator requires VirtualBox for Linux gets installed before.
Install GenyMotion
How To Install GenyMotion (Android Emulator) On Linux | 2DayGeek
2daygeek.com Linux Tips, Tricks & News today :- How to Install GenyMotion (Android Emulator) on Ubuntu, Debian, Linux Mint, openSUSE, Arch Linux, Fedora, CentOS, RHEL, Mageia, Manjaro
www.2daygeek.com
DL VirtualBox
Linux_Downloads – Oracle VM VirtualBox
www.virtualbox.org
Click to expand...
Click to collapse
I went for the official Android Studio from Google. I guess it’s the best for a complete newbie like me. I’ve been able to start a virtual phone with it.