The Makefile for ashmem and binder have this line:
KERNEL_SRC ?= /lib/modules/$(shell uname -r)/build
so dkms will always build those modules against running kernel,
even for other kernel version headers. With this commit dkms will
always provide the necessary kernel version.
Signed-off-by: Tomasz Maciej Nowak <tomek_n@o2.pl>
From the Porting to GCC 7[1] page:
> Several C++ Standard Library headers have been changed to no longer include
> the `<functional>` header. As such, C++ programs that used components defined
> in `<functional>` without explicitly including that header will no longer
> compile.
> Previously components such as std::bind and std::function were
> implicitly defined after including unrelated headers such as `<memory>`,
> `<future>`, `<mutex>`, and `<regex>`.
> Correct code should `#include <functional>` to define them.
[1]: https://gcc.gnu.org/gcc-7/porting_to.html
Signed-off-by: Eddie Ringle <eddie@ringle.io>
If we don't assign the unprivileged user as owner the container
will fail to start as the Android services wont be able to write
anything into the created directory hierarchy.
Fixes building anbox with clang 4.0 -- removes unused declarations,
makes sure a template is visible at first instantiation, makes sure
exception declarations match between headers and implementations
Signed-off-by: Bernhard Rosenkränzer <bero@lindev.ch>
We can now start the Session Manager in Stand Alone Mode. This means
that the Container Manager is not required, since the assumption is
that the user will provide their own container. The issue is that
the container related calls are spread throughout the Session
Manager's code base. So if we attempt to take an instance of the
Container Client class in one if-ed out area, by the time we reach
the next, it will be out of scope.
One solution is to take the instance of the Container Client class
globally, then only make use of it if it's required. This works
great if the Container Manager is running in the background.
However, since a connection is made to the Container Manager
during the constructor, if the Container Manager is not running,
the side-effect is the following error:
Failed to connect to socket /run/anbox-container.socket: Connection refused
To solve this problem we will use a global (actually private to
the Session Manager) pointer which will always be in scope. It
will only be initialised and used when required though.
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Some features which Anbox offer may be useful to users, but can not
be officially supported. For example, the recently added Stand-Alone
Mode can be utilised to make use of different types of independent
containers where Anbox does not control the complete life cycle, but
since these types of setups can be widely varying and complex, it
would not be impossible to provide support. Thus, when running in
these modes, it's important for the user to show knowledge that they
are operating in an experimental way. This functionality provided
by issuing the --experimental flag when starting the Session Manager.
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Normally Anbox will use the default container provided by the
Anbox Container Manager, but some users may wish to run their
own container. Here we're adding a --standalone flag which
tells the Session Manager not to interact (configure/start)
the Container Manager. This allows the user to utilise any
other bespoke container of their choosing. For instance,
this new feature was tested using a Docker container running
the android.img provided by Anbox.
Signed-off-by: Lee Jones <lee.jones@linaro.org>
