Develop Reference

How to rename multiple files with adb?

I want to rename all files in my /sdcard/Android/data/com.miui.gallery/files/gallery_disk_cache/small_size folder to shorter names.
Each file is 65 characters long and i would like that to be as short as possible, there are +- 9000 files in my folder. The file names contain both letters and numbers.
I have acces to adb debugging with my windows pc and USB-Debugging is turned on
I however cant acces my phone, it is stuck in a bootloop and turns off after 20 seconds, touch is only usable to enter my passcode so that i can acces the above named directory.
I have pulled 5GB so far, but cmd is limited to 8000 characters and it would take ages to pull everything without renaming files first

This is certainly possible with tasker, though I cannot give you the "complete recipe". Basically, you could create a task like this:
Execute Command: ls -1 /path/to/your/files, and capture the output into a variable
the command will list all files in the given directory, one file per line
Work on the variable. There are possibilities to convert it into an array, so you can use a for loop to handle each file
again with variables, you can setup the rename command (e.g. using Variable Search Replace) in a new variable. Pseudo-Code: mv "$old_name" "$(s/ /_/,$old_name)"
But it is much easier to use a simple shell script in some terminal app (or via adb shell) to achieve the same:
cd /path/to/your/files
for file in $(ls -1); do mv "$file" "$(echo $file|sed 's/ /_/g')"; done

Linux Kernel Dynamic Debug settings - persist across a reset

With Dynamic Debugging enabled in the Linux Kernel, I am able to control which prints show up by writing to /sys/kernel/debug/dynamic_debug/control. However, It seems that a reboot resets this file to its default settings (all prints disabled).
Is there a way to make the settings persist across a reset? I have a print which is emitted early in the boot process, and I am not able to get it to print, because the reboot disables this print in /sys/kernel/debug/dynamic_debug/control.

You should be able to add dyndbg='your query here' to the kernel command line using the bootloader configuration or manual options entry feature. This will vary with the bootloader although grub is the most common one
If you are using grub as a bootloader you would have to add it to the kernel command line in /boot/grub/grub.conf for the particular kernel you are launching at bootup.
A blog article about this can be found here. In particular it gives this example:
dyndbg='module xhci_hcd +p'
The article also discusses modifying grub as well.
This kernel howto about dynamic debugging has useful information about dyndbg. This section applies
To activate debug messages for core code and built-in modules during
the boot process, even before userspace and debugfs exists, use
dyndbg="QUERY", module.dyndbg="QUERY", or ddebug_query="QUERY"
(ddebug_query is obsoleted by dyndbg, and deprecated). QUERY follows
the syntax described above, but must not exceed 1023 characters. Your
bootloader may impose lower limits.
These dyndbg params are processed just after the ddebug tables are
processed, as part of the arch_initcall. Thus you can enable debug
messages in all code run after this arch_initcall via this boot
parameter.
On an x86 system for example ACPI enablement is a subsys_initcall and
dyndbg="file ec.c +p"
will show early Embedded Controller transactions during ACPI setup if
your machine (typically a laptop) has an Embedded Controller.
PCI (or other devices) initialization also is a hot candidate for using
this boot parameter for debugging purposes.
If foo module is not built-in, foo.dyndbg will still be processed at
boot time, without effect, but will be reprocessed when module is
loaded later. dyndbg_query= and bare dyndbg= are only processed at
boot.

You can do it as a part of post boot script. Say after Android boots(since i see Android tag added here), it runs certain sh scripts as a part of init procedure. Modify the sh files with the dynamic debug commands added and push it in and reboot .
Refer here for post boot script files info.
https://android.stackexchange.com/questions/6558/how-can-i-run-a-script-on-boot

You can have dynamic_debug for some kernel module foo activated automatically during boot using the /etc/modprobe.d/ directory.
### BEGIN prerequisite
# in case module "foo" is not yet automatically loaded during boot,
# then make it load during boot:
# create a file /etc/modules-load.d/foo.conf with contents "foo"
echo "foo" | sudo tee /etc/modules-load.d/foo.conf
### END prerequisite
# create a configuration file to activate dynamic debug for module "foo"
# at its "module initialization time"
echo "options foo dyndbg=+p" | sudo tee /etc/modprobe.d/foo.conf
Reference: Debug Messages at Module Initialization Time from kernel.org documentation.

Where to I place the OBB file to test Android Expansion Pack Files (OBB) on my Nexus 4?

I'm trying to test the Expansion Pack Files (OBB) In Android following the guide here:
http://developer.android.com/google/play/expansion-files.html
I'm in the step where I need to test my app on my Nexus 4.
I generated my .obb file with jobb and adb-pushed it in the device in this location:
/mnt/shell/emulated/0/Android/obb/my.package/main.1.my.package.obb
When the app run it doesn't find the file.
Method:
Helpers.doesFileExist(context, fileName, xf.mFileSize, false)
return false for my file.
I debugged and found out it is looking for the file in:
/storage/emulated/0/Android/obb/my.package/main.1.my.package.obb
Specifically this is the path returned by:
Helpers.generateSaveFileName(c, fileName)
The /storage/emulated/0, returned by Environment.getExternalStorageDirectory() doesn't exist browsing the device with adb shell.
But it DOES at runtime, inside the app, I also checked what it contains: it contains almost the same things I found in /mnt/shell/emulated/0, it contains the Android/obb dir, which is empty.
How I found out the path /mnt/shell/emulated/0/Android/obb/my.package/main.1.my.package.obb where I placed my obb file:
$ adb shell
$ ls -ld sdcard
lrwxrwxrwx root root 2013-10-16 17:34 sdcard -> /storage/emulated/legacy
$ ls -ld /storage/emulated/legacy
lrwxrwxrwx root root 2013-10-16 17:34 legacy -> /mnt/shell/emulated/0
And inside that I already found the Android/obb directory, empty.
So the question is: where should I put my obb file for it to be in the right position at runtime?
I did everything said there:
created a draft application in the Market to get the public key
generated a random array of 20 byte (salt)
integrated play_licensing/library and play_apk_expansion/download_library
wrote my Service / Receiver
did the check using the Helpers etc.. exactly like the documentation say.
I suppose everything works but I can't just yet release on Play Store! I need to test locally and I'll have the need to change my obb file pretty often in this initial phase of development.
I can't test on the Emulator because I use 3D and device camera.

Since Android 4.2 multi users support have been added.
To support that Android mount an emulated disk for each users acting as a sandbox layer around the actual filesystem: this let Android handle gracefully either sharing of files between users either personal files.
Long story short:
/storage/emulated
is the emulated filesystem.
if you enter that directory from adb shell you may see a
/storage/emulated/obb
directory. Sometimes it doesn't show up, for some reason (see below for what to do if this happen)
It's not in /Android/obb but that's the right directory where to place your app package / obb file!
If you don't see that directory try looking in:
/mnt/shell/emulated/obb
You should be able to put your file there.
It will be correctly picked up at runtime ending at the
/storage/emulated/0/Android/obb/my.package/main.1.my.package.obb
path.
I think the Android documentation should explain this.
(I answer my own question because I found out how to solve it while writing it.)

For me the correct location is : mnt/sdcard/Android/obb/nameofyourpackage/
NOT "/mnt/shell"

How to build CM system app without odex?

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.

How can I copy the contentsof data/ to sdcard/ without using adb?

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