There are many ways in which we can setup networking for LXC containers - simple to highly complex. In this blog post I will get the simple steps required in order to have networking work for LXC containers using libvirt. It is hard to create bridges on WiFi interfaces unless your network foo is high (YMMV), but libvirt makes things simple irrespective of the interface. When your dev box is a laptop and want to use LXC on it, then instead of spending hours to get the networking work with the WiFi or avoid getting stranded to cable when using LXC on the laptop, libvirt comes handy. The steps below are tested on Debian Stretch / Testing / Unstable / Sid - give it a shot on other distros with equivalent packages.
This is a continuation to "Access Android devices from LXC" which explains how to access an Android device from within an LXC container. Android Compatibility Test Suite (CTS) represents the "mechanism" of compatibility for Android devices. It is a suite of tests that are run on an Android device to check compatibility of the device under test. We shall see how we can run CTS within LXC so that we have an option of running CTS from different operating systems and different JAVA versions.
LXC aka Linux Containers are a convenient way to run a light weight Virtual Machine. LXC provides a complete operating system with access to devices attached to host machine. Let us see how we can access an Android device from a LXC instance via adb or fastboot. I assume you have a working LXC with networking setup properly. I am using a LXC named 'test-lxc' which is a Debian sid based container (root@test-lxc:/#) and a Google Nexus 4 as android device with debug mode enabled. My host machine (stylesen@harshu:~$) is a Debian sid based Thinkpad.
I was introduced to Debian Operating System back in my college days somewhere in the year 2003. After almost 12 years of using Debian, today I feel proud to say I ve also contributed back to the Debian Community. Yes, I became a Debian Maintainer this week. Introduced in Debian Project News as a New Contributor - https://www.debian.org/News/weekly/2015/06/ I successfully completed Debian New Maintainer process and officially became a Debian Maintainer this week with my GPG key included in the Debian Maintainer Keyring!
Iceweasel is my primary web browser in Debian Jessie and I use it for Google Hangouts too. Recently a month back one fine day when I was about to start with a meeting after an 'apt-get upgrade' on my Debian machine, Google Hangouts stopped working in Iceweasel. Google marked Iceweasel as an unsupported browser and I was left without an option. Enormous searching asked me to use a different user-agent string to act as a supported browser, which also failed in my case. Even with a changed user-agent string Google rejected my Hangout sessions. I haven't been so very comfortable with Google Chrome web browser (experienced from past usages) and didn't want to try it on my Debian Jessie machines, just for Google Hangouts.
With the advent of SSD's and mSATA we have a very less system boot time in the order of few seconds. That makes us impatient to click and open applications on our desktops! I recently switched to SSDs in the machines which I use, to make the systems responsive and end with impatience ;)
All my systems run Debian Jessie (8.0) and the systems on which GUI is enabled I have GNOME 3, specifically GNOME 3.14.x. There are some primary applications such as Terminal, Pidigin, Icedove and Iceweasel which I want to be ready as soon as I login to my machine enabled with GUI. This takes 4 clicks after login, but I wanted to have 2 steps only, ie., power on and login after which everything should be ready to get going. The way to go is some kind of session Application startup manager where I can instruct my machine to startup application as soon as I login. Looks like we had gnome-session-properties in the past for configuring the same in GNOME. It was recently removed.