Develop Reference

Change bootanimation in aosp code for custom rom

I have successfully compiled the aosp code for android 11, I tried to change the bootAnimation, but still I am seeing the legacy android bootAnimation on emulator after successfull build. Below are the changes I have done:
Created boot.zip file with store method as per all standards followed.
Kept that boot.zip in /system/media/boot.zip and /device/generic/x86_64
Change aosp_x86_64.mk file with below code: (As I choosen aosp_x86_64 target in lunch)
#Boot Animation
PRODUCT_COPY_FILES +=
device/generic/x86_64/boot.zip:system/media/boot.zip
PRODUCT_ARTIFACT_PATH_REQUIREMENT_ALLOWED_LIST += \
system/media/boot.zip \
After these changes when emulator boots legacy android boot animation shown, with fluctuation of white screen after that instead of mine boot.zip contents.
Please suggest me any solution regarding the same, Thanks in advance.

Can't get malloc debug to turn on?

I'm trying to enable malloc debug for my android application, and for the life of me i can't get it working.
My wrap.sh scripts each contain this:
#!/system/bin/sh
LIBC_DEBUG_MALLOC_OPTIONS="free-track verbose"
logwrapper "$#"
and I've set up the following directory structure:
When I grep logcat for "malloc debug enabled", I get nothing.
If i change my wrap.sh scripts contents to this
#!/system/bin/sh
LIBC_DEBUG_MALLOC_OPTIONS=free-track logwrapper "$#"
which is exactly what the documentation for the wrap shell script says to add (although to me that seems like invalid shell script syntax), i can see the "malloc debug enabled" log message, but my application freezes at the splash screen and never actually launches.
I'm not sure what's going on and would love any type of input.
Other notes:
My project is using CMake.
My debug device is running Android P.

That is for running an executable binary on Android. I think you are running a Java app with JNI calls, and that trick does not apply to you. You will have to set those environment variables from JAVA as the app starts.
Try looking at OS.setenv() - https://developer.android.com/reference/android/system/Os.html. I hope that those environment variables can be set from Java before the JNI library is loaded, or that the library reads those environment variables on every call, and not just init.

If the accepted answer doesn't work for you then my solution might work:
#!/system/bin/sh
LIBC_DEBUG_MALLOC_OPTIONS=free-track logwrapper
exec "$#"
Make sure line endings are LF and not CRLF.
Then my issue was that malloc debug wasn't able to write the dump:
E/malloc_debug: Unable to create file: /data/local/tmp/backtrace_heap.16934.exit.txt
I thought this might be due missing permissions. By changing the output folder to the one of your app, this is circumvented:
LIBC_DEBUG_MALLOC_OPTIONS='backtrace backtrace_dump_on_exit backtrace_dump_prefix=data/data/com.your.app/files/dump' logwrapper
And dumping now works:
E/malloc_debug: Dumping to file: data/data/com.your.app/files/dump.17599.exit.txt
Also make sure you set
buildTypes{
debug {
debuggable true
}
}
in build.gradle and
android:extractNativeLibs="true"
android:debuggable="true"
in the AndroidManifest.xml file

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.

Android NDK app not able to hit any breakpoint

I am using https://www.youtube.com/watch?v=kjsC-lKUgM8 tutorial to try to debug a simple NDK app. I have done everything as it is in the video except:
I am on OS X 10.9.3 instead of Windows.
I don't use android:debuggable=true(cause eclipse considers it as error) in AndroidManifest.xml instead I have set the NDK path from Preferences->Android->NDK and in Project Properties -> C/C++ Build unchecked Use default build command and set there ndk-build NDK_DEBUG=1 APP_OPTIM=debug.
I don't use x86 emulator but Samsung Duos S device with Android 4.0.4
But the breakpoiin that is used in the video in not being hit in my case. I am trying to debug a simple NDK test project already the 4th day. Have investigated lots of material:
Android Native Development Kit Cookbook
Bunch of forums and tutorials
Videos
But can not hit a single damn breakpoint. Please help if you could do this ever.

The following is an excerpt from an tutorial I wrote for our internal Android development team. The bulk of which was derived from this blog: http://mhandroid.wordpress.com/
Important notes:
I use a Linux (Ubuntu 12.04) environment for my Android work.
I used the ADT Bundle for Linux, Build: v22.2.1-833290 (Eclipse IDE + Extras)
These steps are for debugging from a Java Activity into a JNI shared object.
I created test projects for this tutorial which won't be posted here, though references to those projects are present in the instructions that follow. You'll need an existing Android Application Project as well as a JNI shared object that is being called by your Java code.
Project Setup
Enable Debugging.
Open AndroidManifest.xml, select the Application tab, and set Debuggable=true. This will make the application debuggable even when it's running on a device that's running in user mode.
4. Build the Native Sources. From the Terminal, enter the project directory and enter:
ndk-build -B
You should see the following output:
Gdbserver : [arm-linux-androideabi-4.4.3] libs/armeabi/gdbserver
Gdbsetup : libs/armeabi/gdb.setup
Compile++ thumb : DebuggingTestJNI <= com_sample_test_DebuggingTestActivity.cpp
StaticLibrary : libstdc++.a
SharedLibrary : libDebuggingTestJNI.so
Install : libDebuggingTestJNI.so => libs/armeabi/libDebuggingTestJNI.so
Clean the Project. In the Eclipse menu strip, select Project→Clean. It is good to perform this step anytime you change/build your native sources. This step ensures that Eclipse will rebuild your .apk.
Native Debug Setup
Create Java Debug Configuration. We need to create a debug configuration for stepping into Java source code.
In the Eclipse toolbar, you'll see a green bug. Click the little arrow next to the bug and select "Debug Configurations…".
Double-click "Android Application" in the tree structure on the left. This will create a template for a new Android Application Debug Configuration.
In the "Name:" field, name it "DebuggingTest Java Debug" to make sure you know this Configuration applies specifically to the DebuggingTest project, and targets your Java source.
Under "Project:", click the "Browse…" button and select DebuggingTest.
Click "Apply" to save your changes.
Click "Close".
In the Eclipse toolbar, click the little arrow next to the bug and select "Organize Favorites…".
Click "Add…"
Select "DebuggingTest Java Debug" and click "OK".
Your new debug configuration has now been created and added to your favorites. You can access your favorites by clicking the little arrow next to the bug in the toolbar. "DebuggingTest Java Debug" should be at the top of the list.
Run ndk-gdb.
In the Eclipse toolbar, click the little arrow next to the bug and select "DebuggingTest Java Debug". This will deploy and install the DebuggingTest.apk to your connected Android device and start the debugger.
Navigate to the DebuggingTest project directory in your Terminal and type the following:
ndk-gdb
If the command succeeds, you should see the following:
GNU gdb 6.6
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "--host=x86_64-linux-gnu --target=arm-elf-linux".
(no debugging symbols found)
…
If you forgot to start debugging the application before this step, you get the following:
ERROR: Could not extract PID of application on device/emulator.
Are you sure the application is already started?
Consider using --start or --launch= if not.
If your Android.mk file is malformed or contains $(info) blocks, you get the following:
cp: target ./obj/local/armeabi/gdb.setup' is not a directory /home/Dev/NDK/ndk-gdb: 639: cannot create start DebuggingTest/jni/Android.mk end DebuggingTest/jni/Android.mk ./obj/local/armeabi/gdb.setup: Directory nonexistent /home/Dev/NDK/ndk-gdb: 640: cannot create start DebuggingTest/jni/Android.mk end DebuggingTest/jni/Android.mk ./obj/local/armeabi/gdb.setup: Directory nonexistent start: invalid option: -x Try start --help' for more information.
If ndk-gdb is already running, you get the following:
ERROR: Another debug session running, Use --force to kill it.
Resolve your ERRORs before continuing. ndk-gdb MUST run successfully.
Running ndk-gdb does not only ensure us that we are doing everything right so far, but also creates app_process, gdb.setup and libc.so files in the obj/local/armeabi/ sub-directory of our project. Those files will be needed in later steps.
Stop Debugging.
In your Terminal, type CTRL+Z to stop ndk-gdb.
In Eclipse, select Run → Terminate.
4. Create C/C++ Debug Configuration. We need to create a debug configuration for stepping into C/C++ source code.
In Eclipse, click the little arrow next to the bug and select "Debug Configurations…".
Double-click "C/C++ Application" in the tree structure on the left. This will create a template for a new C/C++ Application Debug Configuration.
In the "Name:" field, name it "DebuggingTest C and CPP Debug" to make sure you know this Configuration applies specifically to the DebuggingTest project, and targets your C/C++ source.
In the "Main" tab:
Click "Browse…" on the "C/C++ Application:" field.
Navigate to "/home/Test/testing/DebuggingTest/obj/local/armeabi/app_process" and click "OK".
Click "Browse…" on the "Project:" field.
Select "DebuggingTest" and click "OK".
Check the "Disable auto build" box.
At the bottom of the form, you'll see "Using GDB (DSF) … - Select other…". Press the "Select other…" button.
In the pop-up, check the "Use configuration specific settings" box.
Select "Standard Create Process Launcher" in the list and press "OK".
In the "Debugger" tab:
Click the combo-box on the "Debugger:" field and select "gdbserver".
Uncheck the "Stop on startup at:" box.
In the "Main" sub-tab:
Click "Browse…" on the "GDB debugger:" field.
Navigate to "/home/Dev/ndk/toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86/bin/arm-linux-androideabi-gdb" and click "OK". This debugger is distributed with the Android NDK.
In the "GDB command file:" field, type "/home/Test/testing/DebuggingTest/obj/local/armeabi/gdb2.setup". The gdb2.setup file does not exist yet, but we'll create it shortly.
Check the "Use full file path to set breakpoints" box.
In the "Connection" sub-tab:
Set "Type:" to TCP
Set "Port number:" to 5039
Click "Apply" to save your changes.
Click "Close"
In the Eclipse toolbar, click the little arrow next to the bug and select "Organize Favorites…".
Click "Add…"
Select "DebuggingTest C and CPP Debug" and click "OK".
Your new debug configuration has now been created and added to your favorites. You can access your favorites by clicking the little arrow next to the bug in the toolbar. "DebuggingTest C and CPP Debug" should be at the top of the list.
Create gdb2.setup. Eclipse doesn't like the "target remote :5039" line in gdb setup file because it wants to enter this command internally (that is why you configured port 5039 in the previous step). Because the gdb.setup file is recreated by the NDK scripts, you have to copy it to the gdb2.setup and point Eclipse to the gdb2.setup file (which we did in the previous step).
In your File Explorer, navigate to "/home/Test/testing/DebuggingTest/obj/local/armeabi/".
Copy the "gdb.setup" file and then paste it into the same folder. The result should be a file named "gdb (copy).setup".
Rename "gdb (copy).setup" to "gdb2.setup".
Open gdb2.setup by double-clicking the file.
Replace "set solib-search-path ./obj/local/armeabi" with "set solib-search-path /home/Test/testing/DebuggingTest/obj/local/armeabi".
Replace "file ./obj/local/armeabi/app_process" with "file /home/Test/testing/DebuggingTest/obj/local/armeabi/app_process".
Remove the line that reads "target remote :5039".
Save and Close the file.
5. Create ndk-gdb-eclipse. One last Eclipse housekeeping item. Eclipse will run the gdb binary itself, so we have to remove the execution of gdb from ndk-gdb. We'll save the original content by doing another Copy-Paste-Rename.
In your File Explorer, navigate to "/home/Dev/NDK".
Copy the "ndk-gdb" file and then paste it into the same folder. The result should be a file named "ndk-gdb (copy)".
Rename "ndk-gdb (copy)" to "ndk-gdb-eclipse".
Open ndk-gdb-eclipse by doing a right-click → Open With Other Application …
Select Text Editor from the list of applications
In the file, locate the line that reads "$GDBCLIENT -x native_path $GDBSETUP" (probably at the very bottom) and comment it out by prefixing it with a "#" character.
Save and Close the file.
When Debugging native sources within the Eclipse IDE, we'll use ndk-gdb-eclipse instead of ndk-gdb.
Debugging/Stepping into Code
Step Into the Java Code!
Put a breakpoint in the DebuggingTestActivity.java file at line 20 (System.out.println("hello world!")).
Insert a breakpoint in your main Activity BEFORE any calls into native code are made. onCreate() is generally the best place for this.
Start the DebuggingTest application in Debug mode by clicking on the little arrow next to the bug and selecting "DebuggingTest Java Debug".
You'll see a pop-up on the screen labeled "Confirm Perspective Switch". Press "Yes" if you'd like it to switch to your Debug Perspective. I would recommend doing so.
At this point, you should have hit the breakpoint you set.
Warning: The breakpoint we just hit sits inside of the onCreate function. This function will be called AFTER all static loadLibrary calls have been made. Notice that outside of the onCreate function there is a System.loadLibrary("DebuggingTestJNI") inside of a static block. This loadLibrary call will execute before we enter our onCreate function, ensuring that our native symbols are loaded by the time we hit our initial breakpoint. It is imperative that we are stopped at a breakpoint before proceeding!
Step Into the C/C++ Code!
In your Terminal, navigate to the DebuggingTest directory and type the following command:
ndk-gdb-eclipse ← Remember that we created this file back in step 6
If successful, the command should complete without any response.
Go back to Eclipse and run your C/C++ debugger by clicking the little arrow next to the bug and selecting "DebuggingTest C and CPP Debug"
Note: When I do this, I see dozens of errors in my Eclipse console, but things still seem to be working…
Switch back to your Java Perspective.
Click the double arrows at the top right of right of your Eclipse window and select Java.
Open DebuggingTest/jni/com_sample_test_DebuggingTestActivity.cpp
Set a breakpoint in the first JNI function that will be called by your main Activity.
Click Run → Resume (F8)
You'll get the Perspective Switch message again, so feel free to switch back to the Debug Perspective.
You should have just hit the breakpoint we just set in the native code!
Congratulations!!!
At this point you should be able to take what you've learned and adapt it to existing projects you may have.

Froyoporting, vendor & device folder, and build for a device with tapas

i try to build Froyo for a given dev board, but i don't know how to configure the source tree, especially where should put the board specific code and the board configuration mkf ile, either in vendor or device ?
I first put my board specific code and config file in the vendor folder as:
vendor\cpyname\the_product_1\, with BoardConfig.mk that describe my board configuration.
I then have vendor\cpyname\product\ with the_product_1.mk to start the source tree build.
can't build with tapas, when giving product name (the_product_1), i get an error
build/core/product_configuration.mk
the_product_1 not found.
I also try with the device folder, like:
device\the_product_1\ with BoardConfig.mk,
and device\the_product_1\product\ with the_product_1.mk
tapas give the same result.
Note that first configuration can build and generate image with make PRODUCT-the_product_1-eng
I also personally find the build process quite obscure and missing documentation. Please help :)
Lionel

Froyo and the after use devices instead of vendor directory ,you will find sample there.