OK, let's reconstruct the full raw packet contents.
The driver supplied an ARPHRD_ value that got mapped to DLT_EN10MB (probably an inappropriate ARPHRD_ value; this is a known botch in some Android mobile phone interfaces, probably done to cope with inadequacies in the DHCP implementation, and later versions of libpcap work around it), so the packet was interpreted as if it were an Ethernet packet, when it probably was, in fact, not an Ethernet packet.
So tcpdump printed the packet as if the first 6 bytes were a destination MAC address, the next 6 bytes were a source MAC address, and the next 2 bytes were the type/length field.
Thus, the packet began with:
45 00 00 a8 35 49 00 00 32 06 af 56 d8 3a
and that really looks like an IPv4 packet with no link-layer header - which is exactly what the mobile phone interfaces in question provide as packets.
libpcap 1.6.2 and later have the libpcap workaround; if you use a version of tcpdump that uses a later libpcap, that will probably show the packets correctly. (If they don't, perhaps the hack libpcap uses to detect the bad ARPHRD_ values need to check for more interface names; please report this to tcpdump-workers@lists.tcpdump.org or on the GitHub issues list for libpcap. (Report this as a libpcap issue, not a tcpdump issue, as that's what it is.))