May I know how will the new ECDSA certificates that are going to be publicly available soon be made to handle Android Compatibility? From the chain of trust page, looks like the chain would be Subscriber Cert -> E1 -> ISRG Root X2 -> ISRG Root X1 -> DST Root CA X3.
The staging server is set up the same way that production will be (except that it uses fake/test certs for the whole chain, of course).
The chain being served by ACME, when signed by E1, is Leaf β E1 β ISRG Root X2 β ISRG Root X1, without the "android compatibility" cross-sign from DST Root CA X3.
Now if you want to finagle things in a way more complicated than your ACME client will do by default, you could configure your web server to instead serve the chain you mention, replacing the self-signed ISRG Root X1 with the version that's signed by DST Root CA X3, and it should work just fine (or at least will work as well as the RSA-signed route will).
However, I suspect that most people who are trying to stay compatible with older systems aren't yet switching to ECDSA certificates. That's a guess on my part, though.
While we're talking about ECDSA + Android compatibility, one should also note that there is one incompatibility that one might want to be aware of:
Android 7.0 has a bug, where the only supported elliptic curve is P-256, meaning that the P-384 curve used by Let's Encrypts E1/X2 certs cannot be handled by this Android version. The Android version advises ECC support though, so I presume that this scenario will simply break (handshakes usually fail with "illegal parameter" TLS alert from my tests). 7.1 is fixed though, this seems to only affect 7.0. Older than 7.0 (e.g 6.x and below) as well as 7.1 and newer works fine.
If you want strong Android compatibility, sending just RSA with the compatibility chain (the one Let's Encrypt will soon use by default) is the best way with Let's Encrypt certificates. Everything else will offer slightly less compatibility with Android, even if you would send a ECC chain up to DST Root CA X3.