Vyline DOCS

Android Kernel

Kernel capabilities to verify before running Docker Engine, containerd, and runc on Android. Vendor kernels differ significantly, so a CONFIG name alone is not enough to declare a device supported.

Kernel features Docker uses

Docker Engine, containerd, and runc directly use namespaces, cgroups, mounts, veth, netfilter, and related kernel facilities. Installing a Docker CLI into Android userland is not sufficient.

Important categories

1. namespaces
2. cgroups
3. seccomp
4. OverlayFS
5. bridge / veth
6. netfilter / conntrack / NAT
7. ext4
8. loop device
9. proc / sysfs / tmpfs / devpts
10. mount propagation
CategoryTypical symptom when missingCheck
PID/NET/UTS/IPC namespacerunc fails to create namespaces; network namespaces cannot be createdunshare, kernel config
cgroup / memory / pidsdockerd warnings or resource-controller creation failures/proc/cgroups, cgroup mounts
seccompDefault seccomp profile cannot be used; runtime warningsCONFIG_SECCOMP*
OverlayFSoverlay2 fails to initializeCONFIG_OVERLAY_FS, real mount test
veth / bridgedocker0 or container veth cannot be createdip link, kernel config
netfilter / NAT / conntrackInternet access or published ports failiptables, nft, config
ext4 / loopCannot create an alternate Docker data-root for F2FS-related failureslosetup, mount -t ext4

Example CONFIG checks

The following are the main options checked in the verified reference setup. The exact combination changes with kernel version and Docker features in use.

CONFIG_NAMESPACES=y
CONFIG_UTS_NS=y
CONFIG_IPC_NS=y
CONFIG_PID_NS=y
CONFIG_NET_NS=y
CONFIG_USER_NS=y
CONFIG_CGROUPS=y
CONFIG_CGROUP_CPUACCT=y
CONFIG_CGROUP_SCHED=y
CONFIG_CPUSETS=y
CONFIG_MEMCG=y
CONFIG_MEMCG_SWAP=y
CONFIG_CGROUP_PIDS=y
CONFIG_CGROUP_BPF=y
CONFIG_SECCOMP=y
CONFIG_SECCOMP_FILTER=y
CONFIG_OVERLAY_FS=y
CONFIG_VETH=y
CONFIG_BRIDGE=y
CONFIG_BRIDGE_NETFILTER=y
CONFIG_NETFILTER=y
CONFIG_NF_CONNTRACK=y
CONFIG_NETFILTER_XTABLES=y
CONFIG_NETFILTER_XT_MATCH_CONNTRACK=y
CONFIG_NETFILTER_XT_MATCH_ADDRTYPE=y
CONFIG_IP_NF_IPTABLES=y
CONFIG_IP_NF_FILTER=y
CONFIG_IP_NF_NAT=y
CONFIG_IP_NF_TARGET_MASQUERADE=y
CONFIG_EXT4_FS=y
CONFIG_BLK_DEV_LOOP=y
CONFIG_PROC_FS=y
CONFIG_SYSFS=y
CONFIG_TMPFS=y
CONFIG_DEVPTS_FS=y

=m can also work, but Android boot/module layouts require verifying that the module can actually be loaded. A symbol present in the build config does not guarantee that the feature is usable at runtime.

Check the actual device

zcat /proc/config.gz | grep -E 'CONFIG_(NAMESPACES|UTS_NS|IPC_NS|PID_NS|NET_NS|USER_NS|CGROUPS|MEMCG|CGROUP_PIDS|SECCOMP|SECCOMP_FILTER|OVERLAY_FS|VETH|BRIDGE|NETFILTER|NF_CONNTRACK|IP_NF_NAT|EXT4_FS|BLK_DEV_LOOP)='
cat /proc/cgroups
findmnt -t cgroup,cgroup2

If /proc/config.gz is unavailable, inspect the device kernel's build config or IKCONFIG from the kernel image. When building your own kernel, enabling CONFIG_IKCONFIG=y and CONFIG_IKCONFIG_PROC=y makes later diagnosis much easier.

Test runtime behavior, not only CONFIG

unshare -m true
unshare -p --fork true
unshare -n true
ip link add veth-test type veth peer name veth-peer && ip link del veth-test
mkdir -p /data/local/tmp/ovl/{lower,upper,work,merged}
mount -t overlay overlay -o lowerdir=/data/local/tmp/ovl/lower,upperdir=/data/local/tmp/ovl/upper,workdir=/data/local/tmp/ovl/work /data/local/tmp/ovl/merged
umount /data/local/tmp/ovl/merged

Run these diagnostics from a root shell. The overlay test also depends on the underlying filesystem, so a failure must be separated into kernel-feature and filesystem-compatibility causes.

cgroup driver

Android does not run systemd as PID 1, and some devices expose a mixture of Android-specific cgroup v1 hierarchies and cgroup v2. Do not assume the systemd driver. Inspect the real mounts first; cgroupfs is often easier to operate in such environments.

cat /proc/cgroups
cat /proc/self/cgroup
findmnt -t cgroup,cgroup2
find /sys/fs/cgroup -maxdepth 2 -type d | head -n 80

After Docker starts, check Cgroup Driver and Cgroup Version in docker info. If controllers are missing, first investigate what Android mounts and exposes instead of only changing daemon settings.

Storage-related capabilities

These are Docker storage-driver requirements, not Vyline-specific requirements. On devices where Android userdata uses F2FS/casefold or another setup that does not work with overlay2, an ext4 loop-backed data-root requires EXT4_FS, BLK_DEV_LOOP, and OVERLAY_FS.

stat -f -c '%T' /data
ls -l /dev/block/loop* 2>/dev/null
losetup -f 2>/dev/null || true
grep -w overlay /proc/filesystems
grep -w ext4 /proc/filesystems

Network-related capabilities

A Docker bridge can exist while NAT or conntrack is still missing. At minimum, check NET namespaces, veth, bridge, netfilter, conntrack, IPv4 filtering/NAT, and MASQUERADE.

grep -E 'veth|bridge' /proc/modules 2>/dev/null || true
ip link show type bridge
cat /proc/sys/net/ipv4/ip_forward
iptables -t nat -S 2>/dev/null | head
nft list ruleset 2>/dev/null | head

BRIDGE_NETFILTER and xtables matches may be required depending on the Docker/iptables setup. The Android legacy/nft split is diagnosed by packet path in Networking.

SELinux

Android vendor policy can deny loop mounts, mount namespaces, dockerd actions, or iptables changes. If everything works while enforcing, leave it enforcing. When SELinux is suspected, check getenforce and audit/AVC logs; treat permissive mode as the last diagnostic step.

Permissive reduces protection

Do not enable it unconditionally on a daily-use phone. Adding the required sepolicy is preferable; permissive mode should be treated as an experimental workaround on a dedicated server device.

When modifying a vendor kernel

Do not copy a generic “Docker Linux config” wholesale into an Android vendor kernel. Qualcomm and other vendor kernels may have vendor scheduler, power-management, GKI/QGKI, and cgroup implementations; unrelated config changes can prevent boot or cause performance regressions.

Add only the missing container features you have actually confirmed, and validate in small stages: boot → root → namespaces → Docker. In particular, do not change scheduler-related CONFIGs merely because they commonly appear in generic Docker guides.

Features Vyline itself does not require

Running Vyline as a Docker container does not use KVM or /dev/kvm. TUN is also not required by Vyline itself; it becomes a requirement only when a VPN such as Tailscale/WireGuard or another container needs it.

Search by page, setting, or command