[Android Head-Units] Tuatara:
What Zaphod said is exactly right ... at the time of the init.d script execution, the mounts are not yet available from the kernel. Only the emmc block devices and the mounted kernel partitions for boot are available. The init.d scripting is (more or less) in place to execute functionality PRIOR to (before) the full boot of the system (i.e. that's how SuperSU ensures it can hook itself in). However, it seems that for our devices, it could be useful to have the init.d scripting execute POST (after) the system is fully booted and everything is available.

POLL: What do you, as the device users want in the way of scripting support at boot time?

We presently have "/etc/init.d" support which executes before boot ...

Should I add in a similar function, call it "/etc/boot.d" support which would execute after boot???

Let me know your thoughts, and I'll build something into the next ROM. :cool:

Zanix --- I don't really have a solution I'd recommend (yet) for you ... but ... there is always an answer! If you're willing to "hack" one of the features I added to the ROM (for now) you can hijack the method by which I install ClockworkMod, and pre-install the ViPER4Android impulses if you wish to ... but just be aware that this script will be in all likelihood be reset on the next (and on each?) ROM update.

/system/bin/install-once.sh

#!/system/bin/sh
#
# Tuatara ROM Initialization
#
# This code is effectively run once on first boot of the ROM
# It then performs all of the post-boot feature installation required
#

# Check if Viper4Android Impulses are installed
if [ ! -d /mnt/internal_sd/ViPER4Android ]; then
mkdir /mnt/internal_sd/ViPER4Android
chown system.sdcard_rw /mnt/internal_sd/ViPER4Android
chmod 775 /mnt/internal_sd/ViPER4Android
fi

# Check if Viper4Android Impulses are installed
if [ ! -d /mnt/internal_sd/ViPER4Android/Kernel ]; then
echo "Installing Viper4Android Impulses ..."
mkdir /mnt/internal_sd/ViPER4Android/Kernel
chown system.sdcard_rw /mnt/internal_sd/ViPER4Android/Kernel
chmod 775 /mnt/internal_sd/ViPER4Android/Kernel
busybox unzip -o -qq /system/media/install/ViPER4AndroidPresets.zip -d /mnt/internal_sd/ViPER4Android/Kernel
else
echo "Viper4Android Impulses already installed"
fi

# Check if ClockworkMod Recovery has already been installed
if [ ! -f /mnt/internal_sd/.clockwork_recovery ]; then
echo "Flashing ClockworkMod to Recovery"
dd if=/system/media/install/recovery.img of=/dev/block/platform/emmc/by-name/recovery bs=4096
touch /mnt/internal_sd/.clockwork_recovery
else
echo "ClockworkMod already flashed to Recovery"
fi

# Zanix - Add in your code here to mount your drive mappings
echo "==started mount script==" > /data/local/tmp/init.d_log.txt
mount -o bind /mnt/external_sd/Android/data/ /mnt/internal_sd/Android/data 2>&1 >> /data/local/tmp/init.d_log.txt
echo "==done mount script==" >> /data/local/tmp/init.d_log.txt

I think you'll have some success with this method. ;)

BUT I would like to instead make this an "approved" method in our ROMs ... so, let me know about the "/etc/boot.d" idea. :cowboy:

P.S> Yes, I'm going to be making the ClockworkMod install detection work in a better way (check a temporary mount for flash success), and probably output the "echo" testing into a logfile in the /tmp directory ... so this script WILL be changing in my next ROM.

---------- Post added at 12:16 PM ---------- Previous post was at 12:13 PM ----------

"Danger" is my middle name. :cool:

Oh, and if you want the previous PMs, just let me know - I have a habit of not deleting anything.

---------- Post added at 12:19 PM ---------- Previous post was at 12:16 PM ----------

The easiest way is definitely using the FactoryTool. I'm not sure why this would be happening. I'm fairly certain that the ROMs should unpack fine using FactoryToolv4.4 ... I'm positive I tested that before upload. I (somehow?) had built one previous ROM, which would unpack fine with rktools, but not with FactoryTool. Is anyone else having this problem again with the latest ROM from my Google Drive???

Ah ... I see that this issue has been resolved. I'll continue to check my ROMs when I upload them, that FactoryTool can always successfuly unpack the ROM

---------- Post added at 12:28 PM ---------- Previous post was at 12:19 PM ----------

"Just keep that brown recluse out of my turf!", said the Kiwi.

There is an option in the MCU configuration "Whether astern mute". Translating this into English means ... "Mute when reversing". Just uncheck this option and you're good to go.

I'm sorry to inform you - that this will be entirely impossible. The video signal DOES NOT come into the Android Box at all. The Video switching is done in the Head Unit, and the video signal is not available. This is the case for ALL video and audio inputs on the head unit.

If you think about it - it only makes sense. Bringing in the video (and audio) would necessitate digitizing all video and audio (hadware overhead?), putting it through the Android Box (CPU overhead?), and then outputting it to the display (GPU overhead?). None of that makes sense from a hardware or software design perspective. This is also the case for the Bluetooth Headset (PHONE) Connection. The BT Microphone (3.5mm jack input) is SPECIFICALLY for the BT Headset hardware, and does not go into the Android Box. The other BT Audio connection however DOES go into the Android Box, and this can be processed accordingly (i.e. by ViPER4Android).

Hope that helps!

---------- Post added at 12:50 PM ---------- Previous post was at 12:28 PM ----------

RDS is unfortunately difficult to get working right in the firmware for the Silicon Labs FM chipsets. The example code provided by Silicon Labs to do this decoding is (in my opinion) far too "cumbersome" to use for embedded devices. It's far too involved for what needs to be done. Basically, this code was written by a software engineer who treated the interface as an API, and not as a piece of hardware. Too much effort is spent in manipulation, and not enough on "just getting the results".

As for why the support isn't in there yet - it's easy enough to define the interface specification for RDS communications, and I'm certain that the kernel developers have already implemented this according to spec, but my feeling is that the MCU code is presently lacking functionality and/or is presently a STUB callback for testing only.

---------- Post added at 01:16 PM ---------- Previous post was at 12:50 PM ----------

A few others have experienced a Bluetooth "lockup" of sorts, in which the Bluetooth Headset has 'locked' the audio. In simple terms the audio has been left on "BT Headset" output, and does not switch back to the Android.

Solutions which have worked for others have been reflashing the MCU, and checking/unchecking all Bluetooth options and powering off the unit completely (i.e. battery disconnected from the Head Unit). The issue is not in the Android Box, but in the Head Unit, which retains power when in the car.

---------- Post added at 01:32 PM ---------- Previous post was at 01:16 PM ----------

Very nice (if very expensive!). I got one of these for "mouse and keyboard" input purposes. http://www.dx.com/p/mini-handheld-wireless-94-key-keyboard-with-mouse-touchpad-black-148878. It has a mini-touchpad, mini-keyboard with backlight ... standard HID profile, and it has an IR remote on the back - works well. My 8" unit does not (yet) have an IR remote, but I wonder if this remote would work out of the box with the NU3001 which I think has IR support on the front panel.

For stereo control, I'm finding I need to have a volume control (dial), and would like to have a MUTE, along with basic app selection and maybe some camera buttons. To this end I'm going to build something myself (AVR - probably an ATTINY861, or an ATMEGA88), and interface it as a standard USB HID device for control purposes. I'll document this build and provide a (rough) schematic and source code for anyone else who might want to build something like this themselves. Let me know if there's any interest in a DIY HID USB device for stereo controls which you can build yourself.