Предположу, что поскольку вы не указали lxc.arch = armhf — ваш контейнер использует архитектуру хоста, что смущает андроид чуть более, чем полностью. Опишите хост-систему и процесс создания контейнера подробнее — глядишь, и сами найдете ошибки.
Имхо, для таких архитектурных изысков больше подходит KVM/QEMU в чистом виде.
Совершенно верно. Ошибка существует изначально и я её уже описал: отключен функционал SELinux. Андроиду это сильно не понравилось и он отказался работать, по-началу. Отключить оказалось легче, чем разобраться. Хотелось получить быстрый результат. А эмулятор — потеря производительности. У меня в планах разобраться настройками SELinux, но, так как эта тема — хобби, то только по мере появления свободного времени
Не думаю, что производительность критически отличается, т.к. для контейнеров с отличной от хоста архитектурой все равно используется эмуляция. Иначе CPU хоста не совсем понимает что происходит. Поэтому, ставят пакет qemu-user-static и, в вашем случае:
# lxc-create -t abox -n p3 — -a armhf, а в конфиге явно указывается lxc.arch = armhf
ИМХО — Андроид на STB — это пустая трата времени. У меня есть опыт портирования Андроида на СТБ, там дальше вылазят проблемы с тем, что сама система не адаптирована на работу с ДУ. К примеру, мы писали собственный обработчик на pintch zoom на уровне линукс дарйверов — нужно было зажать кнопку и дальше +\-. А в системе эмулировани нажатия 2мя пальцами. И так со многими вещами. Для решения изложенных в статье задач — есть смысл посмотреть в сторону GoogleTV и тд. — решений котороые изначально рассчитаны на RCU.
Пустая трата времени это просмотр шоу. Тут же интерес. Даже если я получу отрицательный результат, я его получу. Во-всяком случае, я использовал шанс, и мне не в чем себя будет упрекнуть. По сути: написать нормальное приложение, адаптированное под ПДУ — работа серьёзная. На эргономику времени уходит больше, чем на написание кода. В GoogleTV многое решено, так что я с вами частично согласен.
Set-Top-Box и опыты с Андроид в контейнере LXC