[android-porting] Re: vold vs. mountd
for the record, the file lives in /system/etc/vold.conf On Fri, May 1, 2009 at 5:18 PM, twebb taliaferr...@gmail.com wrote: I'm using the new sdk-1.5 and see that vold is now used instead of mountd. It appears that volmgr_bootstrap() uses vold.conf, but I don't see that file in the rootdir. Is the format/syntax of vold.conf just like it was for mountd.conf? Can someone add some details as to how to get vold basically working as mountd did? Thanks, twebb --~--~-~--~~~---~--~~ unsubscribe: android-porting+unsubscr...@googlegroups.com website: http://groups.google.com/group/android-porting -~--~~~~--~~--~--~---
[android-porting] Re: why in emulator, /dev/eac is connected with the audio?
On Sat, Apr 18, 2009 at 9:02 AM, max max.xi...@gmail.com wrote: Hi David, Thanks for your reply. When I study the code in frameworks\base\libs\audioflinger \AudioHardwareGeneric.cpp, I saw it does open the device node dev/ eac to get a File descriptor. Therefore , the question is how /dev/ eac is connected with the host linux's sound system. I have read the code in external/qemu/hw/goldfish_audio.c, but I still can not figure out how the device node /dev/eac in emulator's linux system is connected with host linux's sound system. the /dev/eac device node is supported by the emulator-specific kernel code located here: http://android.git.kernel.org/?p=kernel/common.git;a=blob;f=arch/arm/mach-goldfish/audio.c;h=c7973e70a114a08dcc57af954223acdfaec3b49e;hb=android-goldfish-2.6.29 it is used to send/receive sound samples by reading/writing various i/o memory registers. this is emulated/supported by the emulator source file goldfish_audio.c, see: http://android.git.kernel.org/?p=platform/external/qemu.git;a=blob;f=hw/goldfish_audio.c;h=d0a44b564c29364a884ffd091088a25933ea2da4;hb=2b8ea29e2bd12f876a4d06647e6077bf72de567e which itselfs uses the QEMU audio sound-system (located in external/qemu/audio) which is actually rather complex, but described by the light documentation I wrote for it here: http://android.git.kernel.org/?p=platform/external/qemu.git;a=blob;f=docs/AUDIO.TXT;h=71ec288ef950aee341e3469f3a5520fd83b4a8a2;hb=2b8ea29e2bd12f876a4d06647e6077bf72de567e external/qemu/audio contains several audio backends that communicate with the host sound system, for example: coreaudio.c for OS X windaudio.c for Win32 esdaudio.c for EsounD on Linux alsaaudio.c for ALSA on Linux etc... so what happens when generating sound output is: AudioFlinger - /dev/eac - kernel (mach-goldfish/audio.c) - emulator (external/qemu/goldfish_audio.c - QEMU audio sub-system - system-specific audio backend) - system sound API Hope this helps Thanks On Apr 17, 5:48 pm, David Turner di...@android.com wrote: On Fri, Apr 17, 2009 at 10:51 AM, max max.xi...@gmail.com wrote: Hi Buddies, I wanna get understood that why in emulator dev/eac is the device of audio, historical reason, but mostly because that's what the emulator-specific kernel supports as I know, in external/qemu/audio, there is all kinds audio drivers, such as oss, alsa, these are only used to send audio output to the host sound system, this has nothing to do with what is supported in the emulated system. These are not 'drivers' by the way, just usual call to sound libraries / system interfaces you can have a look at external/qemu/hw/goldfish_audio.c to see the code used to support sound hardware emulation in Android but I am very curious why in the android linux system, the dev/eac is connected with those drivers. Anybody can give me some light on that? Max- Hide quoted text - - Show quoted text - --~--~-~--~~~---~--~~ unsubscribe: android-porting+unsubscr...@googlegroups.com website: http://groups.google.com/group/android-porting -~--~~~~--~~--~--~---
[android-porting] Re: Hardware profiles / requirements
We have tried to design things to be able to address a relatively wide range of devices, but we are perfectly happy to accept constraints on the hardware we run to avoid compromising other important things like usabilityand consistence. Understood. However, the temptation to design a device that is all glass and no buttons far exceeds the need for usability. :) One option would be to persistently display HOME/BACK/MENU on the TFT screen. Basically reserve a portion of the display, let's say, 20 x 320 pixels for these 3 virtual buttons. Am I the only person that has these kind of requirements or is this somethig that has been brought up before? Thank you, Andrei On Apr 2, 6:07 pm, Dianne Hackborn hack...@android.com wrote: This really depends on whether you are talking about Android as a generic system, or Android and the current applications that run on it. If the latter: - Some kind of 5-way is currently required, though it would be feasible to drop this in the future (with an ability to know if a particular app requires 5-way nav). - Home is completely handled by the system, so it isn't required so long as you can provide some other way for a user to navigate through the system. - The back key is required, insofar as there must be some way for the user to case a back key event to the current application in order to navigate through its UI. - The menu key is likewise required by applications, again only to the point of there being some way for the user to deliver a menu event to the application. - Given that we won't require a physical keyboard at all in cupcake, there isn't really much requirement for it. :) Fwiw, Android is not at all designed to be as flexible as possible. We have tried to design things to be able to address a relatively wide range of devices, but we are perfectly happy to accept constraints on the hardware we run to avoid compromising other important things like usability and consistency. On Thu, Apr 2, 2009 at 3:32 PM, RugBat rug...@gmail.com wrote: Hi all, I'm looking for info on what kinds of hardware features are required by Android. I realize Android is designed to be as flexible as possible, and that's great, but: * Can it live (and be usable) without some kind of 5-way navigation device? * Can it live without home and back? * Can it live without the menu key? * What keys are required (if any) on the keyboard for it to be functional? (e.g. sym, search, alt, ) Thanks! -- Dianne Hackborn Android framework engineer hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them.- Hide quoted text - - Show quoted text - --~--~-~--~~~---~--~~ unsubscribe: android-porting+unsubscr...@googlegroups.com website: http://groups.google.com/group/android-porting -~--~~~~--~~--~--~---
