But at the end moment in linking, the build failed saying.

target SharedLib: libcameraservice (out/target/product/sholes/obj/SHARED_LIBRARIES/lib*_intermediates/LINKED/
y.so)
prebuilt/linux-x86/toolchain/arm-eabi-4.4.3/bin/../lib/gcc/arm-eabi/4.4.3/../../../../arm-eabi/bin/ld: out/target/product/sholes/obj/SHARED_LIBRARIES/lib*_intermediates/z.o: in function w.cpp:109: error: undefined reference to

We can easily know that the symbols are not found in the respective linked library, but hey wait a second, we said the library is properly copied and it’s in LINKED library path. What is the problem?

The difficult the question, but the simple was the answer. The library I was linking was a c .so file, but where I was linking it was a cpp .so file. Umm .. extern “C” { } saved me

In your introduction you imply that in an implementation for reference counting the object always holds the reference counter (in your example by inheritance). This is but one possible implementation of a reference counting concept however.

A reference counter does not need to be part of an object (or a base class), and the object doesn’t even need to know about it for all it cares. The solution you provide does that. This is an approach called ‘intrusive reference counting’ because you need to ‘intrude’ on each type of object definition that you want reference counting implemented for. It is sensible to do this for an OO design when the object itself ‘knows’ that the added storage and function call levels implied cost less than the off-chance of someone accidentally forgetting to release memory, or if you don’t simply care about performance cost. If you build an application from scratch, it is perfectly reasonable to do this.

Other implementations of reference counting create specialized types of pointers (‘smart pointers’) that collectively own the reference counter object (usually just a standalone int), and destroy that object upon decrementation to 0. This is preferable in old code that you do not want to touch or when you are referencing third-party objects whose class declarations you cannot change to inherit from some base class. boost:shared_ptr implements this concept, and you can also find an almost complete example in Bjarne Stroustrup’s “The C++ Programming Language”. The disadvantage of this concept is that each smart pointer needs to hold two pointers – one to the object they point to and one to the collectively shared reference counter. It is also neccessary for the application that use these smart pointers to be aware of that fact, since they explicitely need to use the appropriate smart pointer types and may never call delete on them (which is about the only thing that ultimately distinguishes them from ‘normal’ pointers). Note that the auto_ptr type is a rather incomplete implementation of smart pointers.

Yet another approach is that you implement a memory manager that holds reference counters. I consider this the ‘most object-oriented’ approach because reference counting is really the job of a memory manager. It does afford having your own memory manager though, and most applications don’t bother with that.

I did implement this last concept in my own Pool memory manager: in this implementation the memory block object also holds a corresponding block of ‘use counters’ (which are in fact reference counters), so there is no need to individually destroy reference counter objects as they’re being destroyed along with the blocks that hold the memory for the objects being managed by the pool. The memory manager also returns it’s own specialized smart pointers.

Just wanting to give you some insight on various possible solutions. There are more, and the boost library offers quite a few variants if you’re interested.
~Stefan63/www.codeproject.com

There is a really good tool out there in the market called GoldWave. It helps to play raw PCM, ISDN, ASCI data with respective bits and bit order of little and big endian.

Audio/Surface flingers, media server, service manager are the common place for such a nasty issue. dmesg and strace are really good tools to debug such an issue.

dmesg prints the message buffer of the kernel. It has the list of diagnostic messages about what’s going on in the kernel if the user process does something wrong or something happens to the device drivers. It also contains the exception and faults of the system.

I first run the dmesg and check the last timed message before executing the problematic process. This is just to make it easy to look at the right place after the process is crashed.

strace is an awesome tool to have a detailed information about what a process is doing in the execution. What are the files being accessed, the system calls, forked processes and so on.

I usually run the following command to trace the process from the adb shell
1. strace -ff -F -tt -s 200 -o /tmp/strace process-bin-path(/system/bin/mediaserver)
-ff > follow fork
-F > follow vfork
-tt > print time in micro seconds
-s > buffer size of printing the message
-o > file to generate the strace output
Last is bin process full path, or you can use -p with process id. -p option can be used for Java application. (Use ps command to show running processes)

Analyze the strace and dmesg output to solve an issue in a snap ^^

It’s not only related to APIs, but also gives a basic audio mechanism.

Linux Kernel 2.6 introduced us the unified driver model. In PC based environment, the devices are connected to different kind of buses like PCI, ISA etc. When a device is connected to a bus, it receives a unique identification which will be used for further communication with the CPU. The driver for the related device can be initialized/removed using the probe/remove method normally.

What about the embedded system? Mobile phones?

Mobile phones usually don’t have a sophisticated bus mechanism found in PC systems. So there must be a way to attach a device to the embedded system like Memory, input MIC, accelerometer etc.

The answer is Platform Drivers. They are similar to normal drivers, but the major difference is their working mechanism. They help the devices directly connect to CPU. The driver can be identified using the unique name within the system and it can be configured for interrupt.

A platform driver should be register and unregister using platform_driver_register() and platform_driver_unregister(). The machine file for a particular board can maintain an array of devices connected to CPU and add them using platform_add_devices().

When platform_add_devices() is called, it internally calls probe() function of each of the driver which helps the driver to initialize.

Most of the people mentioned to compile with ENABLE_PV_LOGGING=1 option compilation for Android platform with /sdcard/pvlogger.txt. It was also mentioned to write [Log Level] [Node to log] in the pvlogger.txt. Under the heaven, I was still clueless to see a single log.

The most important part of source exists in external\opencore\android\thread_init.cpp, where it checks PVLOGGER_INST_LEVEL and then includes android_logger_config.h which has the logger class. Therefore, add “#define PVLOGGER_INST_LEVEL 5″ in this file and create pvlogger.txt file with 8 in it. You can see the log. Enjoy!!

It happens that in the phone these images are not directly downloaded directly, but the phone flash memories are formatted in different kind of file system i.e YAFFFS, RFS, XSR. It seems RFS, XSR are proprietary file systems, but there is TinyBML which is open source and present in Boot loader as well in the Kernel.

So these .img images must be converted to the compatible file system format and then it should be downloaded.

Get more info on
RFS
TFS4
XSR

Android build system is quite clean and easy to understand, but there is an obvious dependency to compile platform source and Kernel source.

The OEM usually keeps their code including init.rc in the vendor directory. So when we compile the platform source, the product specific directory is created with root and system directory.

The root directory has init.rc which must be used in the ramdisk image in order to execute it when the root file system is mounted.

Because of this obvious dependency, we usually compile platform, kernel and boot in that order.

There have been many events happened and the things have been changed. The most big transition has been to go into the Android field. There was a sudden deep into the Android last year because of the global demand for smart phones and people’s openness to accept the Google’s new platform. I would like to blog additionally for “the android” about the knowledge, opinions, tips etc. And, of course, the photography!!!

So see you soon~~