I need help figuring out how to install a Google Apps .zip (or gapps package) on an Android device without using recovery. I have not seen this process documented anywhere, and before I go manually copying files from the zip onto a device, I'd like to see if anyone can give me some guidance. The device in question is rooted, but installing a custom recovery (such as Clockwork) is not an option. It seems straightforward enough (as the zip's internal file structure is recognizably an android fsh), but before I go and happily copy a bunch of files to a critical test device I'd like some input as to whether or not there is a preferred method.
It's a little late but i have done this yesterday because i have the same probleme.
The option i use is open a root shell with adb.
Then use the linux mount command
I don't remember the exact command but it's look like this:
"mount -o remount,rw ext4 /system"
And then i copy the file of the system folder of the gapps zip to /system then i reboot my phone and all gapps were installed
Hope it help you or someone who found this like me in the futur.
Related
my Samsung S2 does not boot anymore because I deleted the file
/system/fonts/Roboto-Regular.ttf
I have a copy of this file as
/system/fonts/Helvetica.ttf
How can I copy Helvetica.ttf to Roboto-Regular.ttf in recovery mode?
I have a rooted phone and use PhilZ-cwm6-XWMS2-MOT-5.15.9
Thanks for any help.
I could solve the problem myself.
For anybody having a similar issue:
As mentioned above, I use the rooted kernel PhilZ-cwm6-XWMS2-MOT-5.15.9.
This can also be installed by a zip-file within the recovery mode.
The simple solution now was to modify the shell-script inside this zip-file:
At the end of this shell-script, right before the "exit"-command, I wrote the following shell-commands
# to be sure that /system (still) is mounted read-write:
mount -o remount,rw /system
# copying the font-file:
cp /system/fonts/Helvetica.ttf /system/fonts/Roboto-Regular.ttf
Then I only had to copy the modified zip-file to a micro-sd-card, insert this into the phone, start recovery mode, where I chose from the menu: install zip-file > (external) sdcard > install ...
Then I rebooted the phone, et voilà.
Of course, this also reinstalled the kernel, which was not needed but also not a problem to me. (Before doing the above I tried to start a very simple script in a custom zip-file with the "install zip-file" command, to prevent going through the whole procedure of kernel-installation, but did not succeed with this trick. Maybe someone else can find a way.)
I want to change the init.rc file of an android pad. But after I change it and reboot the system, the original init.rc comes back.
How can I make the change to the init.rc persistently without rebuild the system (since I don't have the source code of the system)? Or is there any way to work around?
Unpack the uramdisk using following command in host PC(Linux)
mkdir /tmp/initrc cd /tmp/initrd
sudo mount /dev/sdb1 /mnt
sdb1 is partion where uramdisk/uInitrd resides.
dd bs=1 skip=64 if=/mnt/uInitrd of=initrd.gz
gunzip initrd.gz
At this point running the command file initrd should show:
mkdir fs
cd fs
cpio -id < ../initrd
Make changes to init.rc
Pack uramdisk using following commands:
find ./ | cpio -H newc -o > ../newinitrd
cd ..
gzip newinitrd
mkimage -A arm -O linux -C gzip -T ramdisk -n "My Android Ramdisk Image" -d newinitrd.gz uInitrd-new
A number of Android devices include code to prevent root modifications to the system files. The way this is done is by using the recovery partition. On reboot, they basically restore the system partition using the recovery image. If your system is doing that then you cannot make persistent changes - the best you could do would be to hook up something to run after reboot to re-apply your change. In CyanogenMod they had hooks in the init.rc to run sdcard scripts if found. Perhaps you can create an app or widget to then launch a script to make the mods required using a setuid root script from the data partition. Without building your own ROM you are quite restricted in this area.
Possibly you could fetch the recovery image and try unpacking that, making your changes and repacking and flashing it. But make sure you can recover with fastboot before you try this.
Try this site:
http://bootloader.wikidot.com/linux:boot:android
Read the section at the bottom:
•The Android boot image: boot.img
◦Unpack, re-pack boot image: http://android-dls.com/wiki/index.php?title=HOWTO:_Unpack%2C_Edit%2C_and_Re-Pack_Boot_Images#Background
When an android system boots, uboot unpacks a special compressed ball of files in your boot partition called 'uRamdisk' to RAM, and defines those files to comprise the root directory of the system. uRamdisk normally contains a bunch of directories (system, data, media, etc.) that serve as mountpoints for partitions that contain the files that go in them, but also has some very basic files vital to your system, including the init binary and startup scripts like init.rc.
when you edit the init.rc, you've actually just edited the unpackaged copy of init.rc that resides in your RAM. To really change it then, you have to copy your uRamdisk, extract it, edit the init.rc from there, repackage uRamdisk and then replace the new one with the old one in /boot.
Try looking up the 'xuramdisk' and 'mkuramdisk' scripts, these make the process very simple.
Your root partition (where /init.rc lives) is a ramdisk which is unpacked from an initrd file and mounted every time your device boots. Any changes you make are to the ramdisk only, and will be lost on the next reboot.
If you can get the initrd file, you can mount it on your Linux host system, modify the files there, unmount it, and write it back to your Android.
The initrd file exists in its own partition on the device. If you can figure out which partition it is, you can grab it from the device onto your host, mount it, modify it, and write it back to the device. This is what tripler was talking about above.
In general, modifying boot.img is something that only system developers do. If you're building the entire Android system, you'll have access to the necessary source code. My workflow for this looks like this:
# Modify init.rc
m -j8 bootimage_signed
adb reboot bootloader
fastboot flash boot $OUT/boot.img
fastboot reboot
I don't know if you are still trying to do this but without knowing your exact device nobody can give you an exact answer.
Try taking a dd image of all your internal partitions and use some scripts like those included with android kitchen on xda forums. Your recovery and boot partitions will both have a ram disk but odds are you want to modify the init.rc in the boot.img not recovery, unless you only want the changes present in recovery mode.
The unyaffs thing doesn't apply to all devices and most devices have different partition layouts so you have to figure out which is boot and what type of fs it is. Maybe if you give your device specs you can get a better answer.
Please note that it may be easier for you to use an app like Scripter to run a script at boot time than modify this file.
Before following #tripler's instructions above you need a file called boot.img which can be extracted by (run on rooted Android device, untested without root):
dd if=/dev/block/platform/<someplatform>/by-name/boot of=/sdcard/boot.img
Then connect your Android to your computer and copy the boot.img file from there.
Script:
http://linuxclues.blogspot.ca/2012/11/split-bootimg-python-android.html
Here is a modified, easier to see version of tripler's instructions (assuming boot.img is in tmp):
cd /tmp
mkdir fs
# Now use the linked script above to split the boot.img file into ramdisk.gz and kernel
python split_boot_img.py -i boot.img -o parts
cd fs
gunzip -c ../parts/ramdisk.gz | cpio -id
# make changes to init.rc
At that point you will have to rebuild the boot.img back together before reflashing, which will be device-specific. Can't help you with that, sorry!
You have to edit/change the init.rc before building your Android pad file system. This is the preferred way, and always works.
I have my Nexus One connected with the USB.
When I visit the File Explorer of the DDMS, if I click on the "data" folder the little plus near the name "data" disappear for 2-6 seconds and then reappear but the contenct of the folder "data" is not showed!
Here some other information:
the folder data has permissions drwxrwx--x
the OS of my PC is Windows XP
Eclipse v. 3.5.2
Android SDK 1.6
If the adbd daemon is running as root, you can browse /data using adb-based tools such as the DDMS file explorer or the adb shell.
If it's not, you can access a few files under /data and its children directly by their full path names, but you cannot browse (or 'cd' to) most of the folders, including /data itself.
"rooting" as an unofficial process means varying things and produces varying results - ie, adbd may or may not run as root.
If ro.secure is set to 0 in the startup scripts such as /init.rc, adbd will run as root, but that may not be a good idea on a user device. It is set to 0 on the emulator, and that's why you can browse /data there.
Finally, note that /init.rc is usually contained in a ramdisk image packed onto the kernel - you can't really edit it on the phone but would have to modify the image offline, re-attach it to the kernel, and re-flash them. Though if you have some sort of working 'su' hack you may be able to change the property temporarily and restart adbd.
In this link (http://denniskubes.com/2012/09/25/read-android-data-folder-without-rooting/) Dennis Kubes shows a method for accessing your application's data folder without root access.
Turns out there is a simple solution, the run-as command.
run-as com.your.package ls -l /data/data/com.your.package
run-as com.your.package rm /data/data/com.your.package/databases/mydatabase.db
That will allow you to run commands as your app. You can also use run-as in interactive mode.
run-as com.your.package
shell#android:/data/data/com.your.package $ ls
cache
databases
lib
shared_prefs
rm databases/mydatabase.db
Interactive mode will drop you into the data folder for your app. You can navigate from there.
I don't think anyone really understands this question. Giorgio can use the DDMS File Explorer to browse the ./data folder on his phone. Pentium10 talks about needing root access on the phone.
Well I a retail Nexus One and a developer Nexus. I have always been able to use DDMS File Explorer to browse the ./data folder on my developer phone but not my retail phone. So I rooting my retail phone would help. I didn't.
So the bottom line is there is something different about the retail and developer phones. Until more research is done you won't be able to browse the data folder on your phone.
Hope this helps.
I feel a bit blind developing on an emulator for Android and not being able to see the file system on the AVD (.img).
Is there a way to mount it in Windows or Linux, so that I could at least see the file listing and maybe contents?
Bonus if it's mounted with write permissions as well.
Thank you.
You can just mount the device in Linux:
sudo mount -o loop ~/.android/avd/<myvirt>/sdcard.img <destdir>
How about "adb shell"?
This will give you a root shell (on the emulator)..
For MacOS X users:
$ hdiutil attach ~/.android/avd/Samsung_Nexus_S.avd/sdcard.img
For Windows, I just ran across the ImDisk Virtual Disk Driver
Install this utility, and you can then mount sdcard.img. There's a nice tutorial here
Yes, they can be mounted. Under Ubuntu you can mount sdcard.img via vfat and system.img and userdata-qemu.img via yaffs2. See also: "Whats Android file system ??".
Note that the file system yaffs2 is not included in the standard Ubuntu kernel. Thus, in case of Ubuntu, you have to build your own kernel with yaffs2 support before you are able to mount the system.img and the userdata-qemu.img. Alternatively, you can also take a look at the yaffs2utils which allow you to extract files from yaffs2 images or to create new image files. The advantage is that you do not have to build your own kernel for using these tools.
Another option would be to use the File Explorer in DDMS (Eclipse SDK), you can see the whole file system there and download/upload files to the desired place. That way you don't have to mount and deal with images.
I tried mounting and it's cumbersome, for example if the emulator is running you can't do it. Plus you would need to mount each image if you want to see all contents.
Disk Utility in OSX easily mounts an SD Card image as a device, but not so the other img files.
I want to get the database I just created in the Android Emulator off the drive and into my osx file system.
I updated my system with qemu using macports but no combination I try succeeds. Anyone figured out how to do this?
Obviously one way I can do this is run the app on my phone than mount the phone as a USB drive. But I don't wanna. I wanna get it off the drive the emulator uses :-)
Thanks in advance, folks.
Michael
Can't you just use adb to pull the database off of the emulator? I actually just answered a similar question... here it was:
The database for a specific app lives in /data/data/[packagename]/databases
The packagename is the package you define in your manifest, for instance /data/data/org.vimtips.supacount/databases/counts.db.
You can view it with adb shell and type sqlite3 /data/data/org.vimtips.supacount/databases/counts.db
Or you can pull it from the device to look at it with a third party utility, with a command like adb pull /data/data/org.vimtips.supacount/databases/counts.db ..
Use the File Explorer in DDMS (from Eclipse SDK), you can see the whole file system there and download/upload files to the desired place. That way you don't have to mount and deal with images, and no adb commands either