I want to create C++ executables to flash ROMs over ADB on android phones, can anyone help me on this?
I have a basic knowledge of C++ but cannot understand from where I should start
The logic is
Initialize header files-->Initialize ADB service-->Start ADB shell-->Flash the .img files using flash_image binary--> ADB reboot
Can anyone give me a simple example for flashing boot image?
I m unaware what header files should I include, which compiler should I use.
created a new thread as I didn't find anything regarding this
Thank you
adb has nothing to do with flashing ROMs, adb is the debugger interface, which requires system up and running on your phone. And trying to reflash the ROM image with fully running system is like performing a heart surgery without an anaesthetic.
There are two basic ways of reflashing of ROM images correctly:
update.zip
fastboot
The former one is when you copy/download your ROM image as update.zip to the sdcard and then use recovery to update the system. This usually involves users pushing some buttons and powering phone off and on back again. This is the best method, because the update file is already safely stored on the sdcard, can be checked and verified, and the chance of bricking the phone is slim to none.
The second one is when you connect your phone to the PC, switch it to fastboot mode with 'adb reboot bootloader' (or switching off/on and holding some buttons), and then use fastboot to perform ROM update magic. Problem is, when using fastboot you need a very reliable USB connection. Any communication error and the phone is bricked. This is why I don't use and don't recommend fastboot method to reflash ROMs.
If you don't mind bricking your phone using fastboot method, the C++ program would be quite simple.
unpack ROM image somewhere (if you have it packed inside the program)
issue exec() or system() calls to run 'adb reboot bootloader' and then 'fastboot flash*' commands, then, finally 'fastboot reboot'
if you have done everything correctly (catch and process the output of adb and fastboot to check the results), your device will get reflashed and rebooted.
Finally, I'd like to stress again, reflashing ROMs with fastboot is quite dangerous, and I'd recommend to avoid it if possible.
Related
Objective
I'm developing a custom app for internal use on a rooted android mini-pc.
The goal (between others... so...many...others...) is to be able to turn on and off a tv using the serial port embeeded on the tv.
I'm using an FTDI UART RS232 serial usb cable for it.
Status
The application is working right now, using an android library (serial-driver) i can communicate with the tv, but the problem is that the device asks for permissions every install (and sometimes, weirdly, again on the same device), so it needs to be improved.
Issue
Since the device doesn't have mouse or keyboard by default, when this happens someone has to click the buttons, and since the device is normally hidden behind the screen, it can be really annoying.
My two bits
This problem, i feel, can be solved by two methods, but i still haven't been able to make them work.
Since the device is rooted, i might be able to modify an unknown (to me) parameter that allows me to bypass the permission request. For this i have tried to make an intent filter for the usb device, and to rewrite the interface that controlls this behaviour, both without success. Is there a way to make this android version more lenient about permissions?
I use for other reasons SuperSU inside the app, so i can use the full width of the might shell power. Using this i've been trying to send commands manually to the device (/dev/bus/usb/00X/00Y), but this haven't worked. My theory is that it's beacuse of the permissions of the device path, but even doing an unhealthy chmod 777 i cannot have them working.
So, that's my problem right now. I hope someone here can help me.
Additional data
Running: Custom Android 4.4.2 (Cannot be changed)
Needs to be doable solely from within the apk (but it can use shell commands)
We don't have the manufacturer signature to install it as a system app
We can use only one app, so i cannot have another one to move this one to /sys/apps, and i don't know if an app can do that to itself.
using Busybox stty -F /dev/.../ returns "Operation not permitted"
My question is that is there any chance that any command in adb can damage (both hardware and software) my android phone (my phone is not rooted) and if software can it be recovered by factory reset? It is Micromax A120 and runs on android 4.4.2.
Yes, you can easily mess up your phone if you mess with ADB and don't know what you are doing. This is particularly true if you are using the 'Recovery' options (flashing new software to your device) in particular, if don't do this correctly, there are opportunities to mess things up (particularly if you are not patient, and don't wait for all operations to complete).
For the most part ADB is just a communication mechanism, and if you are careful to do only things you are confident are safe, there is minimal risk.
Bottom line, there is nothing specific about ADB that is risky, but it is a tool, and if mis-used could cause issues. Use it carefully, and you should be fine.
With adb you can delete and copy data on your mobile phone. So you can loose data or damage the Android System. However you have every time the chance to go into fastboot mode and flash a new Android ROM using the fastboot tools. You only can damage your Android device if you flash a corrupted bootloader using fastboot.
So in short form:
ADB: You can delete data but you have everytime the chance to recover your system. (However you can loose all your data!)
Fastboot: You can destroy your Android device if you flash a corrupted bootloader. It's irreparable.
I am reading a tutorial on the sideload command at link.
It contains the steps of rebooting into recovery mode and using adb sideload [file].zip.
My question is that what does sideload actually do with that zip file ? In the past I have compiled AOSP and flashed a device using
adb reboot-bootloader
adb fastboot flashall -w
Is sideload trying to achieve something similar to the above ?
Edit:
I think my confusion relating to sideload stems from my lack of understanding of how Android's memory is structured. I found two links.
First is a link that explains Android partitions : partitions
Second is a SO answer, that explains Android's memory: memory
Now my understanding so far is this :
Android has RAM and ROM. ROM is divided into several partitions, namely, /system, /data, /boot, /recovery, /cache, /misc and /sdcard.
Now the link relating to sideload states that this command installs a zip file.
What I don't understand still is that, is this zip file, going to replace the entire ROM in Android ? Namely, will it have to have the right partitions as in the list above ?
This also makes me confused about a similar command 'fastboot flashall'. I know when I run it, the terminal goes by saying its writing to several of the partitions. So my questions boil down to these :
1) Is sideload replacing entire ROM ?
2) Is the related command 'fastboot flashall' also replacing entire ROM ?
3) Are there ways to replace select partitions ?
Thanks.
Yes and no. adb reboot-bootloader is used to get yoi into fastboot mode ard sideload is used to apply updates to a system which can be (and is oftenly) used to overwrite a stock OS. I used sideload for exactly that, my fairphone also delivers a small utility to factory reset every partioin of it using adb and sideload (this is the Windows version from scroll down here). Consider chris stratton's comment. You can look into adb backup and adb restore to only deal with user data and apps. Click me tenderly, click me hard. Pay attention as to apps can opt out of this - explanation in this brilliant answer by Izzy.
Depends but more or less yes. fastboot flashall is typically used to flash the recovery partition only to boot from there and continue with sideload (see 1.).
There definitely are, but I'm not able to do it on my own. The referred utility does exactly that. It should be possible to figure out the exact commands or find a similar utility for your manufacturer. I misused mine to flash everything I needed for me. To do so, i just replaced the respcetive .img files such as boot.img
Looking for the command (or steps) to create a shell script on android that tells the device to reboot into recovery mode and automatically restore a backup located in the /sdcard/clockworkmod/backup/ folder. I know the reboot is:
reboot recovery
But I imagine there is something else I either need to add to that line or perhaps create a file somewhere that instructs cwm to automatically restore a backup and reboot.
Found my own answer... For the folks in the ether...
Install ROM Manager Premium (small $$).
Use Koush's test rom manage project (https://github.com/koush/TestRomManager) to connect to ROM Manager and essentially ask it to reboot the device into recovery and do a backup. The system is actually incredibly powerful in that you can do some kool stuff over the air. This is a good setup for internally managed devices... You can even run your own update.zip scipts...
Optionally you can add a couple of exec lines to click ok automatically to the ROM Managers popup "do you want to reboot now?".
Thats it. Lots of research, as usual a Frankenstein of source from a great world full of devs.
If you follow the comments on this file, you will manage to do what you want
https://android.googlesource.com/platform/bootable/recovery/+/fadc5ac81d6400ebdd041f7d4ea64021596d6b7d/recovery.c
Specifically, you will have to deal with the file
/cache/recovery/command
And include there the command you want to issue. Root access is needed to do so.
Alternatively, if your recovery admits it (CWM, TWRP) you can just use the recovery command through adb once you rebooted there.
the camera of my mobile (running Eclair-update1) keeps being non-responsive in 90% of the time, so I assumed a hardware defect at first. After whiping the cache and the phone user data sereval times it worked again. At least for a while. Now it stopped working again.
Browsing the net I found quite some users who experience the same problem and had a hard time after whiping their user data off the device.
So my question would be: how close can I get to the hardware with the SDK? I'd like to write an app to influence hardware states (e.g. re-initializing the camera, remounting the SDcard aso.), but I'd prefer doing it - if possible - with the SDK instead of NDK.
Thanks in advance!S.
It's not a question of sdk vs. ndk, but of underlying operating system level permissions preventing ordinary (aftermarket vs. manufacturer/carrier installed) android applications in general from doing raw hardware access.
Download Android SDK to your computer
Boot device to recovery
Connect USB cable to PC
Run adb shell then
umount /data
umount /system
e2fsck -fv /dev/block/stl9
e2fsck -fv /dev/block/stl10
Taken from forum.xda-developers.com/showthread.php?t=1396366