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
| Category | Typical symptom when missing | Check |
|---|---|---|
| PID/NET/UTS/IPC namespace | runc fails to create namespaces; network namespaces cannot be created | unshare, kernel config |
| cgroup / memory / pids | dockerd warnings or resource-controller creation failures | /proc/cgroups, cgroup mounts |
| seccomp | Default seccomp profile cannot be used; runtime warnings | CONFIG_SECCOMP* |
| OverlayFS | overlay2 fails to initialize | CONFIG_OVERLAY_FS, real mount test |
| veth / bridge | docker0 or container veth cannot be created | ip link, kernel config |
| netfilter / NAT / conntrack | Internet access or published ports fail | iptables, nft, config |
| ext4 / loop | Cannot create an alternate Docker data-root for F2FS-related failures | losetup, 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,cgroup2If /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/mergedRun 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 80After 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 | headBRIDGE_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.
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.