Today I found out, that I could write a libaudio.so and put it in my Android's folder /system/lib/ for custom audio-handling.
My device, a Galaxy Nexus with Android 4.2 is using tinyAlsa and has a libtinyalsa.so.
So I think I could use this project (from the father of tinyAlsa) to build a custom libaudio.so: https://github.com/broonie/tinyhardware
But: Does anyone know, if the tinyAlsa is a samsung or omap special thing, or has any newer android-version that type of audio-handling? So, would my custom libaudio.so be portable on other phones?
If not, does anyone know where I can find a libaudio.so which works with default ALSA?
I know that "AlsaMixer" from Android-market uses it but I will compile it on my own.
With kind regards & thanks in advance.
Android devices do not always use tinyalsa and there's no requirement or recommendation for them to do so. However, all Nexus devices use tinyalsa and there are no plans to change this.
from the tinyalsa author
Related
I have implemented the Picture-in-Picture feature in my project, but I need support for Android 6. Google says it's not supported in Android 6, but I have seen it supported in other applications. Can you help me fix this issue?
PiP did not exist until Android 8. So it is literally impossible to support on Android 6. It's possible that some OEM made a special library that enabled it on a small set of devices, but if so you'd need to find that library and figure out what models it works on. There is no way to do it generally in Android 6. Even the primitives that PiP_ uses didn't exist until Android 7. See https://developer.android.com/develop/ui/views/picture-in-picture
I would like to understand how an application like AlsaMixer or MixGet, mixer widget with alsa is working.
Specially, I would like to develop an application which makes use of the "/etc/asound.conf" which would be available with ALSA.
Has anyone more knowledge on this? How can I "build" ALSA for every Android-device?
I personally have tested those applications on my own Samsung Galaxy Nexus which natively uses "tinyalsa" and on an "HTC Desire" which uses something with "/dev/msm_audio_out" (don't know what this is exactly).
It seems that those apps require root, ok no problem, but they work without larger modifications and on a large range of devices).
Thanks in advance for your help, I've read hundreds over hundreds of docs and found no real informations.
If an Android device
actually uses ALSA drivers; and
is rooted (so that your app can access the device files),
then you could the NDK to access the ALSA libraries.
In that case, ALSA works just like on any other machine.
as it states in the title I am unable to find Samsung Galaxy option for installation in Android SDK Manager (Revision 20.0.3).
Could anyone help on the matter?
PS: Where ever I looked it is said that there should be third party option or should be under Android 2.3 but it isn't there.
Thanks for helping.
You can (and will probably have to) create an emulator image with the specifications of the device you are trying to duplicate. If you are looking for prebuilt ones you'll have to check with the respective manufacturer. If you are expected to see TouchWiz or HTC Sense on the emulator build, you won't as those are proprietary skins.
But, Android != Android and Samsung use their own modified webkit amongst other things.
Just making a best guess from the hardware specs is going to as effective as using chrome.
I can't find a clear list of what files needs developer's attention when i'm building a new Android image.
All the guides that i have found until now are way too generic or really old.
I'm supposing that i'm not interested on customize the platform, i just want a vanilla flavour but for my device only.
The answer is a bit complicated. You probably cannot build a vanilla Android for your device, unless your device is one of the google developer phones. Here is a list of the devices you can build Android for. The reason being that the manufactures usually does not publish all the parts needed to actually build Android for their devices.
But do have a look at the cyanogenmod project, and see if they support your device. They are kind of trying to make a "vanilla" android source for the devices which the manufactures themselves does not support. And they are doing quite a nice job, in my opinion. I have a custom build of Android 4.0 for my Galaxy SII running for months now, and it is working perfectly fine.
If you update your questions with the devices your are using, I can probably provide specifics on how you can build cyanogenmod for your specific device.
What are you trying to do ?
Declare some images or layout specific to only one device ?
You can't do it with a selector on a folder (-large, -fr, ...), but with some code. Check this out : http://developer.android.com/reference/android/os/Build.html#MODEL,
I own a Samsung Galaxy 3 and want to port kernels available for other Android Devices. I have all building environment ready. I have C knowledge also. What exactly I dont understand is how and what all things porting involves, which codes should be modified in what way?
If someone could help me. It would be great.
Thanks in advance.
Ok I got it. But the real problem is I dont understand one thing.
What needs to be changed in the source code so that to make it compatible in other device? Can someone explain me that?
Idolon gives a good suggestion. In theory what is written there is true. In practice, it's a little more involving. I've been porting Android Kernel for months now. My goal was to have a custom S5PV210 processor module on my custom board with my custom I/O. I have the source code for Samsung's galaxy tab and several Samsung's android smartphone as well as a few versions (Froyo, Gingerbread) for the Samsung's Evaluation board (SMDKV210 for S5PV210 CPU). FYI, S5PC110 is a close derivative. Here is what I found out.
Eventhough all the device drivers are supposed to be built in a very modular way and independent from each other and you should be able to replace them with similar devices, the way Samsung did it is not exactly that. To give you one example is about power management. In many low level drivers dealing with hardware devices, it calls some specific routine for other hardware devices like power management chip. So, When you change the choice of drivers in the "make xconfig" or "make menuconfig" it will remove the source code of what you don't want and add the one you want but, there are still other modules that are calling the low level function you removed. When building, you will get tons of unresolved external because you removed a power management chip that your hardware doesn't have but is used in the source you started with. I looked through several Samsung's device source code and they have branched very early on. They have been adapted by different teams and it would be a major amount of work to go from one device to the other from one source kit.
Here is how I succeeded: I bought an S5PV210 evaluation board with an already ported Android Kernel (Gingerbread). All the power management and inter dependant issues where already cleaned-up. Then, form a working kit, I could change the device I needed (the one you can't buy without a 100K unit/yr commitment) without getting stuck with the interdependancy. Then I could even change LCD resolution (from 800x480 to 1024x768), touchscreen, Cell modem etc etc. The whole thing takes about a month worth of work with only one guy (me).
Starting with a Galaxytab or other commercial device made me waste months of headakes with no useful results but the thing I've learned.
There is one requirement to succeed on my approach. You have to know the hardware you are working on. As an example, you need to know what touch screen your hardware has (chipset) to select the driver and were is it connected to hook it up to the right device (USB, Serial etc). That the same thing for all other devices (power managemnt chip, keypad, backlight, LCD etc etc)
Hope that is useful to give you an idea of the work involved and how you can do it.
You should take a look at the cached copy of Android Platform Developer's Guide and at android-porting google group.
There is also an old but useful article about porting Android to Nokia N810, which will give you some hints about Android Linux kernel porting.
I am also into android porting stuff for quite some time I suggest the following route :
Read
You need to have basic knowledge of android porting and AOSP source code, directory stucture hierarchy.
I suggest you to start reading https://books.google.co.in/books/about/Embedded_Android.html?id=plHsngEACAAJ&hl=en
and also refer https://source.android.com/devices/index.html as good guys pointed out you can also google android porting related groups and become a member there, if you are stuck on a issue there are chances similar issue might have been faced by someone else previously.
Observe
AOSP code :
Parallely you need to dive in to the android source e.g from links like https://android.googlesource.com/ observe which components are placed where in the source code, what are the updates from previous android release (like ART replaced dalvik in LL), at top level there would be generic code, code specific to your hardware called HAL in hardware/ and device/ folder.
Kernel code :
In the kernel also you need to observe the directory structure and know which things lie where like SoC specific code will be in arch/ directory defconfigs (used for selecting kernel configuration) will be arch//configs/ directory.
Also there are good books available for linux kernel, you can google them and start reading them also.
While porting kernel you need to take care of following
1.If in the new kernel there is already support of SoC which is used in hardware to be ported then you need to add only device specific changes like suppose you want to port new kernel version to samsung galaxy s3, you can take a reference android kernel having exynos support and then you need to make changes only for adding support for samsung galaxy s3.
For that you need to have reference of some old kernel having support of s3, from there you can study patches which have been added to add support for s3 and port those patches to newer kernel.
Experiment
First you can only port the bare minimum changes required to up the platform, compile and flash it on your platform, then observe the output, if everything looks fine than go on for next changes otherwise try to solve the issue.
Thanks,
Devarsh