I built a recovery.img (using flo lunch setup) for my Nexus 7 device using AOSP source code. I can use it like:
$ adb reboot bootloader
$ fastboot boot recovery.img
However, when I unpack and re-pack the recovery.img file using abootimg utility (without making any modifications to ramdisk) and retry to boot using recovery.img, my Nexus 7 simply goes into Google splash screen loop. Device keeps rebooting after coming to splash screen.
For details, here are my steps:
$ ls
recovery.img
$ abootimg -x recovery.img
$ abootimg-unpack-initrd initrd.img
$ abootimg-pack-initrd myinitrd.img ./ramdisk
$ abootimg -u recovery.img -r myinitrd.img
Resulting updated recovery.img doesn't work as intended, even though its simply an unmodified copy of original recovery.img file.
I had the same problem some weeks ago, but with the boot image, not the recovery... The only solution I found to be working is to extract the initfs from the img file extracted from the device after being installed by using dd command:
dd if=/dev/block/mmcblk0pX of=/sdcard/recovery.img
(Where X is the number of your recovery partition)
You can find the number of your recovery partition by using:
ls -l /dev/block/platform/soc.0/7824900.sdhci/by-name
(Please, note this path may be device specific, but should be similar for all. This one worked for Sony Xperia X Compact device)
Then, the recovery.img file being extracted, you can now extract the initfs and repack again
Related
I've been trying to run some sqlite3 commands once shelled into a Nexus Player via adb and it can't find the sqlite3 command.
Is this not available on Android TV builds? Is there a location to pull this from that would work on it?
I've worked around this by pushing a sqlite3 binary to the nexus player.
Keep in mind: the Nexus Player by ASUS is a x86 device, so you should get a x86 binary.
Push by
adb push X:\sqlite3 /data/local/tmp
After pushing, navigate to the path you've pushed the binary to
adb shell
cd /data/tmp/local
When in the appropiate directory, set the permissions
chmod +x ./sqlite3
Then you can run it by
./sqlite3 <path-to-your-sqlite-db>
I have a smartphone without the possibility to insert an SD-card.
I would like to make a dump of the biggest partition (cause I lost files and I'd like to use a dump to recover them).
The partition is 10GB.
I was looking for an ADB command to pull using dd but nothing...
I tried to use Carliv touch recovery with a 32GB usb key by OTG but the USB key didn't mount ... Then I couldn't use "dd" directly on the phone using Aroma file manager and a terminal emulation.
Thank you!
I don't understand why they closed a question that has already an accepted answer by linking a completely different question. Copying a file and copying a partition are 2 different things.
As said in comment, adb pull /dev/block/mmcblk0 mmcblk0.img worked for me. A "DD image" is only a binary image file of the device.
You want to copy a disk from your android device to your computer (preferably on your fastest drive) for faster and lossless analysis/recovery.
This is short step-by-step guide in windows (linux: scroll down) to achieve it using the linux tool dd intended for precise, bit-wise copies of data. Credits go to scandium on xda for the code, see his post for more details.
Prerequisites
make sure your device is rooted and busybox is installed
Windows:
install cygwin. During install, add netcat (under Net) and pv (under util-linux) packages; the standard install is located in C:\ so make sure you have enough disk space beforehand;
install adb e.g. through Android Studio. Make sure to add adb.exe executable file to the path variable to access it properly (guide).
Open two cygwin consoles/terminals (one sending data, one receiving data) and enter in one of the terminals to enter the device:
# terminal 1
adb forward tcp:5555 tcp:5555 # forward data over tcp connection
adb shell # open a connection
su # gain root access
BUSYBOX=/system/xbin/busybox # default location for most bb installers
# note: adapt the variable `BUSYBOX` to point to your install directory
# the TWRP default is `BUSYBOX=/sbin/busybox` (in case of bricked device)
Decide what partition to copy, the /dev/block/mmcblk0 partition is usually the one containing the data you typically would want.
In the following code, adapt the partition name according to 4. and quickly one after another type in terminal 1 and terminal 2:
# terminal 1
$BUSYBOX nc -l -p 5555 -e $BUSYBOX dd if=/dev/block/mmcblk0
# terminal 2
nc 127.0.0.1 5555 | pv -i 0.5 > $HOME/mmcblk0.raw
This saves the partition in the cygwin home directory (in a nutshell: it sends/receives output of dd over a tcp connection)
Look at the files / analysis
To mount the partition in Windows you can use (OSFmount).
To analyze the files I recommend Active# Undelete but there are tons of alternatives. With that program you can also directly load all partitions from the file (without mounting it, so step 5 is redundant in this case).
Guide for GNU/Linux users: install netcat and pv (step 1), use the Disks utility to analyze
Run as root:
adb root
Use dd to output content into stdout and write file on your computer:
adb shell 'dd if=/dev/block/platform/msm_sdcc.1/by-name/XXXXXX 2>/dev/null' > XXXXXX.img
Or all (see cat /proc/partitions)
adb shell 'dd if=/dev/block/mmcblk0 2>/dev/null' > mmcblk0.img
I have run the following commands -
I cleaned up the existing build using command - make clean
source build/envsetup.sh OR . build/envsetup.sh
lunch full_crespo-userdebug
make -j4 (make fastboot adb)
adb reboot bootloader
fastboot -w flashall
I did these in my MAC OSX 10.9.1 and for the phone Nexus S (crespo). I have no clue why it is not generating the android-info.txt file. Every time I run fastboot command, it says it's missing. However, I have also set up the path ANDROID_PRODUCT_OUT in my .bash_profile file. Still no luck. Can anyone suggest anything?
I know this is a recurrent question when working with the Android emulator, but is there a way to force the emulator to accept persistent changes to /system?
The emulator is based on QEMU, so it should be possible, in theory, to force the system image to behave the same way userdata (for instance) does, but I'm not familiar with how QEMU handles things. Any pointers?
At the moment (with Build Tools v26, if Google doesn't change things as often as they do) if you use the -writable-system directive while booting up the emulator from the command line, it will allow persistence to the /system partition through reboots. That is you will be able to write to the /system partition and if you reboot, the changes will still be maintained.
emulator -avd <AVD_NAME> -writable-system
This will also persist your changes to a qcow2 image file usually in .android/avd/<AVD_NAME>.avd/system.img.qcow2
You can even copy this system.img.qcow2 file, wipe the data off the AVD using the -wipe-data directive, place this file back into the directory, reboot and the system changes you made initially will still be persisted. (Caveat: at least for now, coz Google keeps changing things)
Update: The -nand option was apparently removed from the most recent versions of QEMU, so the following may not work anymore.
Update: See the accepted answer for the current way of doing things.
Yury's answer is the common one, but if you want to be able to script things (which is what I want in the end), you need to be able to find the emulator image in the /tmp directory.
I discovered that you can override QEMU's behavior. This is a bit hackish, but it works, so I ended up doing this :
Copy system.img from the platform directory to your AVD directory.
Convert the amount of space you need to hex. For instance, if you need 500M, this is 0x1f400000.
Run the emulator in read-write mode :
emulator -avd Galaxy_Nexus -qemu -nand system,size=0x1f400000,file=/home/fx/.android/avd/Galaxy_Nexus/system.img
(If you put the emulator in verbose mode, you'll notice that it will, by default, use initfile= instead of just file=)
Make your changes, they are immediately saved to the local system.img
Now you can just start the emulator with emulator -avd Galaxy_Nexus, and it'll use your changes
Update: If scripting, QEMU does not sync changes immediately to the image, so if you're rebooting immediately after changing something, chances are you will lose data. I'm looking for a way around this...
Next update: Use adb -e emu kill to stop the emulator. reboot will just do bad things.
It's actually a very good question. I had the same troubles. Here are my findings. Actually, I use Ubuntu and I'll describe the steps for Ubuntu. If you use Windows, you should just change the paths.
Create new AVD, for instance example.avd
Copy system.img from android-sdk-linux/platforms/android-10/images
to ~/.android/avd/example.avd
Make system.img as writable and readable (either in the properties
or simply using terminal)
Run your AVD using command emulator -avd example
Remount your system as rw using adb shell mount -o rw,remount -t
yaffs2 /dev/block/mtd0 /system (to discover the partition use
command cat /proc/mtd)
Make your changes...
Now during the run of emulator find tmp emulator in
/tmp/android-<your_computer_name> with strange name like:
emulator-PQ7LgE and copy it in ~/.android/avd/example.avd
Delete system.img and rename copied tmp emulator into system.img
Close emulator
Delete cache.img, userdata.img and userdata-qemu.img from
~/.android/avd/example.avd
Run your emulator once again
Good luck!
The solution #2 is amazing.
Here are some hints if you are using MS Win as host
AVD directories are located as below, but the "short" path names should be used
as file= path parameter. The quoted path variant doesn't work for some reason.
Win XP: C:\Documents and Settings\ (username) \ .android\avd\ ...
Short C:\DOCUME~1\ (username) \ANDROI~1\avd\ ...
Win 7 C:\Users\ (username) \ .android\avd\ ...
You can create an own bat file, say "startrw.bat" as per following example:
#echo off
C:\<ADTFOLDER>\sdk\tools\emulator -avd <AVDNAME> -qemu -nand system,size=0x1f400000,file=C:\DOCUME~1\<USERNAME>\ANDROI~1\avd\<AVDNAME>.AVD\system.img
cd C:\<ADTFOLDER>\sdk\platform-tools
echo .
echo Wait ...
echo .
echo When emulator is FULLY loaded press any key to connect adb shell to it
echo To make /system writeable type in adb shell:
echo .
echo -----------------------------
echo mount -o rw,remount /system
echo -----------------------------
echo .
echo You can use the Eclipse ADT DDMS File Browser to browse or push-pull files now.
echo .
echo Closing this window closes the emulator !
echo .
echo Wait emulator to load Android. When done
pause
C:\<ADTFOLDER>\sdk\platform-tools\adb shell
This way you can load in one click.
Once finished modifying, just close the current command window to kill the emulator.
It takes long time for most of things to load like Emulator, the ADT editor, Hooking DDMS file browser (you need to click on the emulator line left side to see the files tree on right window) and so on.
I had trouble finding the system.img file and AVD directory that F.X. posted about. On Mac you can find them here:
system.img: ~/Library/Android/sdk/system-images/android-19/default/
AVD Directory: ~/.android/avd/Nexus.avd/
I don't have enough reputation to add it as a comment, so I had to post it like this. Sorry.
use this command in terminal
cd /Users/NAME_USER/Library/Android/sdk/emulator # Move to emulator folder
sudo ./emulator -writable-system -avd NAME_AVD -partition-size 280 # Run avd by writable system
sudo adb root # Change to root
sudo adb remount # remount again
sudo adb shell
su
mount -o remount,rw -t yaffs2 /dev/block/mtdblock3 /system
change NAME_USER and NAME_AVD
F.X.'s answer does not work for me with Android API 19 and 21 on Windows as it stands. With the given parameters
emulator -avd <AVD> -qemu -nand system,size=0x<SIZE IN HEX>,file=<PATH/TO/system.img>
the system fails to mount the image. By looking at the kernel output I found out that it uses suspicious page size (2048) and two nonzero parameter values: extra size and "erase". These parameters are not documented anywhere, but you can see them in qemu's source code. What ended up working for me was
emulator -avd <AVD> -qemu -nand system,size=0x<SIZE IN HEX>,file=<PATH/TO/system.img>,pagesize=512,extrasize=0
With those parameters specified, "erase" gets set to 0 as well.
I was also surprised to find out that with these parameters the system is unable to boot to the graphical environment, but adb works.
The best way to do this is to use the following command:
<path-to-emulator-executable> -avd <AVD> -partition-size 512
As said here at https://justus.berlin/2015/02/make-persistent-changes-to-system-in-android-emulator/
Copying system.img into avd folder will work.
New year new solutions.
Just copy the system.img to your avd folder and rename the system.img to system-qemu.img
For me, copying C:\Android\sdk\system-images\android-22\android-tv\armeabi-v7a\system.img
to C:\Users\Neil Agarwal\.android\avd\Android_TV_1080p_API_22.avd\
and renaming it to system-qemu.img did the trick.
Please restart your avd after this.
How can I install the Google Play .apk onto my Android 4.0 emulator?
Download Google apps (GoogleLoginService.apk , GoogleServicesFramework.apk , Phonesky.apk) from here.
Start your emulator:
emulator -avd VM_NAME_HERE -partition-size 500 -no-audio -no-boot-anim
Then use the following commands:
# Remount in rw mode.
# NOTE: more recent system.img files are ext4, not yaffs2
adb shell mount -o remount,rw -t yaffs2 /dev/block/mtdblock0 /system
# Allow writing to app directory on system partition
adb shell chmod 777 /system/app
# Install following apk
adb push GoogleLoginService.apk /system/app/.
adb push GoogleServicesFramework.apk /system/app/.
adb push Phonesky.apk /system/app/. # Vending.apk in older versions
adb shell rm /system/app/SdkSetup*
For future visitors.
As of now Android 4.2.2 platform includes Google Play services. Just use an emulator running Jelly Bean. Details can be found here:
Setup Google Play Services SDK
EDIT:
Another option is to use Genymotion (runs way faster)
EDIT 2:
As #gdw2 commented: "setting up the Google Play Services SDK does not install a working Google Play app -- it just enables certain services provided by the SDK"
After version 2.0 Genymotion does not come with Play Services by default, but it can be easily installed manually. Just download the right version from here and drag and drop into the virtual device (emulador).
I do this in a more permanent way - instead of installing the APKs each time with adb, permanently add them to the system image that the emulator uses. You will need Yaffey on Windows, or a similar utility on other systems, to modify YAFFS2 images. Copy GoogleLoginService.apk, GoogleServicesFramework.apk, and Phonesky.apk (or Vending.apk in older versions of Android) to the /system/app folder of the system.img file of the emulator. Afterwards I can start the emulator normally, without messing with adb, and Play Store is always there.
Obtaining the Google Play app from your device
Downloading Google Apps from some Internet site may not be quite legal, but if you have a phone or tablet with a corresponding Android version, just pull them out of your device:
adb -d root
adb -d pull /system/app/GoogleLoginService.apk
adb -d pull /system/app/GoogleServicesFramework.apk
adb -d pull /system/app/Phonesky.apk
You must have root-level access (run adb root) to the device in order to pull these files from it.
Adding it to the image
Now start yaffey on Windows or a similar utility on Linux or Mac, and open system.img for the emulator image you want to modify. I modify most often the one in [...]\android-sdk\system-images\android-17\x86.
Rename the original system.img to system-original.img. Under yaffey, copy the APK files you pulled from your device to /app folder. Save your modified image as system.img in the original folder. Then start your emulator (in my case it would be Android 4.2 emulator with Intel Atom processor running under Intel HAX, super-fast on Windows machines) and you'll have Play Store there. I did not find it necessary to delete SdkSetup.apk and SdkSetup.odex - the Play Store and other services still work fine for me with these files present.
When finished with your testing, to alleviate your conscience guilty of temporarily pirating the Google Apps from your device, you may delete the modified system.img and restore the original from system-original.img.
Download the gapps package from http://goo.im/gapps
extract GoogleLoginService.apk,GoogleServicesFramework.apk and Vending.apk
Go to cmd window type
adb shell
on the shell type mount -o rw,remount -t yaffs2 /dev/block/mtdblock3 /system
then press Ctrl+c to exit.
cd to the directory where apks has been extracted,
type adb push <appname>.apk /system/app
then type adb reboot
It is simple for me i downloaded the apk file in my computer and drag that file to emulator it install the google play for me
Hope it help some one
You could download it from a Android 4.0 phone and then mount the system image rw and copy it over.
Didnt tried it before but it should work.
Playstore + Google Play Services In Linux(Ubuntu 14.04)
Download Google apps (GoogleLoginService.apk , GoogleServicesFramework.apk )
from here http://www.securitylearn.net/2013/08/31/google-play-store-on-android-emulator/
and Download ( Phonesky.apk)
from here https://basketbuild.com/filedl/devs?dev=dankoman&dl=dankoman/Phonesky.apk
GO TO ANDROID SDK LOCATION>>
cd -Android SDK's tools Location-
TO RUN EMULATOR>>
Android/Sdk/tools$ ./emulator64-x86 -avd Kitkat -partition-size 566 -no-audio -no-boot-anim
SET PERMISSIONS>>
cd Android/Sdk/platform-tools
platform-tools$ adb shell mount -o remount,rw -t yaffs2 /dev/block/mtdblock0 /system
platform-tools$ adb shell chmod 777 /system/app
platform-tools$ adb push /home/nazmul/Downloads/GoogleLoginService.apk /system/app/.
PUSH PLAY APKS >>
platform-tools$ adb push /home/nazmul/Downloads/GoogleServicesFramework.apk /system/app/.
platform-tools$ adb push /home/nazmul/Downloads/Phonesky.apk /system/app/.
platform-tools$ adb shell rm /system/app/SdkSetup*
Have you ever tried Genymotion? I've read about it last week and it is great. They have several Android Images that you run (with their own software). The images are INCREDIBLY fast and they have Google Play installed on them. Check it out if it is the kind of thing that you need.
http://www.genymotion.com/