i modify /framework/base/services/core/java/com/android/server/am/ActivityManagerService.java some logcat output string.
and i try to use different ways to rebuild it:
make -jN from top folder or
mmm /framework/base -jN or
mmm /framework/base/services -jN
and then i get a new output file in /out/target/product/generic_x86/system/framework/x86/services.odex
and then i update system.img by make snod
then i try to restart emulator, or adb remount adb sync, or kill system_server process
but sadly, no matter what kinds of methods i use, the emulator always output the original string.(so angry)
i even extract the new output system.img to get the new services.odex file, and use oat2dex.jar to decompile it to java code, and i indeed see the string has changed in it.
so why when i run the emulator, it won't become effective...
The system image file used by the emulator is system-qemu.img.
For some reason that file isn't made by make snod, which only makes system.img. I think what is needed is an additional target so you could say make qsnod or something, but there doesn't seem to be one. I don't know how anyone can work like this.
I don't understand the Makefile structure well enough at this point to figure out how to add a qsnod target, but here's a way to hand-roll
system-qemu.img.
Notice that the very last step that make -nN reports is:
[100% 255/255] Create system-qemu.img
To find out what command it ran there, you can say make showcommands -jN. I did this, and found it was the following, on my Macbook Pro:
[100% 255/255] /bin/bash -c "(export SGDISK=out/host/darwin-x86/bin/sgdisk; device/generic/goldfish/tools/mk_qemu_image.sh out/target/product/generic_x86_64/system.img)"
So that's the command for making system-qemu.img from input system.img (which is what make snod makes).
So, my recipe for rebuilding system.img on my machine, after changing a .java file under framework/base, is:
mmm frameworks/base -jN
make snod -jN
SGDISK=out/host/darwin-x86/bin/sgdisk device/generic/goldfish/tools/mk_qemu_image.sh out/target/product/generic_x86_64/system.img
Then when I restart the emulator, I see that my change has taken effect.
Related
I'm trying to extend Android's PackageManager functionalities modifying this file:
frameworks/base/services/core/java/com/android/server/pm/SELinuxMMAC.java
When I perform a make clean && make after editing the file and I start the emulator, the changes are there, but this takes too long even with the cache enabled. I tried using mmm framework/base but it does not seem to rebuild the services.core module.
Does anyone know a reliable method to modify a system service and then rebuild efficiently?
mmm and submodules
Create the new classes.dex for the services.core module:
mmm frameworks/base/services/core
Creates the services.jar file including the services.core module that we just rebuilt:
mmm frameworks/base/services
Creates the new system.img for the emulator:
make snod
If the emulator (or the device) is already running, you can use the new services.jar with:
adb remount && adb sync && adb shell stop && adb shell start
In fact mm and mmm do not check for modified submodules, so rebuilding the services module (step 2) without previously rebuilding the services.core (step 1) module is not enough.
DEXPREOPT
If you see the message:
Warning: with dexpreopt enabled, you may need a full rebuild.
You have to turn off the dex preoptimization performing a make clean and then use the following flags in make and mm: WITH_DEXPREOPT=false and DISABLE_DEXPREOPT=true.
For academic/forensic reasons I want to get an image from my SmartPhone and study it.
The File System is YAFFS2.
From adb shell and using 'cat proc/mtd' I can see that I have for partitions: system,appslog,cache,userdata.
I can get the four images using dd command, like 'dd if=/dev/mtd/mtd1 of=/mnt/sdcard/appslog.img bs=4096',
and then using pull command to get data.
-> Is it a good idea to have a format file like .img?
-> How to study (mount/ just read) these *.img files?
..I am using Ubuntu 13.10.
An .img file is less likely to be read as an image file by the Open Source forensic tool Autopsy 3.3.3 (+ Sleuth Kit) [Latest Release at the time being]. However, it can still be opened as a logical file set.Nonetheless, I suggest that you should save it in .dd format instead.
When I build CM7 's system app (eg. ADWLauncher) , I switch to ADWLauncher's folder and run "mm" command, then I get .apk and .odex file, How can I just get .apk file with dex in it. I mean should I change somewhere in Android.mk or generic.mk to let the compilation just result apk file which can instsall directly.
Try this mm WITH_DEXPREOPT=false -B
You can use backsmali which can combine odex and apk files
baksmali -a [api_level] -x [odex_file] -d [framework_dir]
Or change the WITH_DEXPREOPT environment variable in
build/target/board/generic/BoardConfig.mk
This usually happens (at least to me) when I have not declared a device I'm building for with breakfast. For example, without running breakfast hammerhead, I got Dialer.apk and arm/Dialer.odex in the output directory. Furthermore, the device refused to run the binary, even after putting the .odex file in place.
Running breakfast first causes make to generate a single proper Dialer.apk that installs cleanly (using adb root/remount/push) on my device.
I'm facing a bug in a makefile build system (Android built under Linux) - some files are removed by an 'rm' command, and I can see that command in the build log.
How can I find the exact line in the makefiles which calls the 'rm' ? Is there any automated method?
For GNU Make you can do the following trick:
__shell := $(SHELL)
SHELL = \
$(warning making '$#'$(if $^, from '$^')$(if $?, because of '$?'))$(__shell)
SHELL variable is expanded each time when Make invokes a sub-shell to execute a recipe. In these lines it is replaced so that on each expansion it will print a target, its prerequisites and prerequisites that are newer than the target. Also each debug message is prepended with the file and line number of the rule being executed.
The same technique is used in GMD to set breakpoints to certain targets.
Assuming your make is a Gnu make, you can also pass some debugging options, like --debug=b (basic debugging messages, very often enough) or --debug=all which is the same as -d
Some files may be removed because they are intermediate. Read also about secondary files and precious files in make
You may try make -d -w and then grep your file from huge amount of output lines.
Hi I need to copy/move the contents of data/tombstones to sdcard/tombstones
I'm using the command below:
mv data/tombstones /sdcard/tombstones
"failed on 'tombstones' - Cross-device link"
but I'm getting above error.
You have a SANE VERSION of the mv command
paraphrasing a few bits from lbcoder from xda and darkxuser from androidforums
"failed on 'tombstones' - Cross-device link"
It means that you can't create a hard link on one device (filesystem) that refers to a file on a different filesystem.
This is an age-old unix thing. You can NOT move a file across a filesystem using most implementations of mv. mv is not made to copy data from device to device, it simply changes a file's location within a partition. Since /data and /sdcard are different partitions, it's failing.
Consider yourself fortunate that you have a SANE VERSION of the mv command that doesn't try anyway -- some old versions will actually TRY to do this, which will result in a hard link that points to NOTHING, and the original data being INACCESSIBLE.
The mv command does NOT MOVE THE DATA!!! It moves the HARDLINK TO
THE DATA.
If you want to move the file to a different filesystem, you need to use the "cp" command. Copy the file to create a SECOND COPY of it on a different filesystem, and then DELETE the OLD one with the "rm" command.
A simple move command:
#!/bin/bash
dd if="$1" of="$2"
rm -f "$1"
You will note that the "cp" command returns true or false depending on the successful completion of the copy, therefore the original will only be removed IF the file copied successfully.
OR
#!/bin/bash
cat data/tombstones > sdcard/tombstones
rm data/tombstones
These script can be copied into some place referenced by the PATH variable and set executable.
Different Interface
If you need a different interface from adb you may move files using the FileExplorer in DDMS View.
Side note:
You can move a file into a folder when:
You're root;
It is your app directory;
You've used chmod from adb or elsewhere to change permissions
Basically you don't have permission to access /data/tombstones in a production version .
It seems we have to 'root' the device first.
But I failed to root my Samsung S4 which is using Android 4.3