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.
Linaro Automated Validation Architecture popularly called LAVA is composed of different components. One of the core components in the LAVA framework is the lava-server component. LAVA developers in the recent past made sure that lava-server's unit tests are working properly and relevant to current code base. As a developer of LAVA I hit this issue everytime I want to run unit tests for lava-server (when I switch environments), mainly due to postgresql dependency. Following are stuff you need to setup in order to run unit tests in LAVA. (Do not do this production deployment, only recommended for dev mode deployments)
lava-master is the default postgresql user created for administering LAVA related databases. In order to run unit tests, the default postgresql user of LAVA should have permissions to create and drop databases. The test database created by LAVA unit test is called 'test_lava-master'. The 'lava-master' user creates and destroys this 'test_lava-master' database each time the unit tests are run. You must be 'root' user in order to perform the following operations: