It should not break userland. GNU/Linux (not necessarily Android though) has supported 64K pages pretty much from the start because that was the originally page size chosen for server-focus kernels and distributions. But there are some things that need to be worked around.

Certain build processes determine the page size at compile time and assume it's the same at run time, and fail if it is not: https://github.com/jemalloc/jemalloc/issues/467

Some memory-mapped files formats have assumptions about page granularity: https://bugzilla.redhat.com/show_bug.cgi?id=1979804

The file format issue applies to ELF as well. Some people patch their toolchains (or use suitable linker options) to produce slightly smaller binaries that can only be loaded if the page size is 4K, even though the ABI is pretty clear in that you should link for compatibility with up to 64K pages.

Assumptions in the software.

Jemalloc is infamous for this: https://github.com/sigp/lighthouse/issues/5244

Ossification.

If the page size has been 4k for decades for most OS' and architectures, people get sloppy and hard code that literal value, rather than query for it.

Replacing compile time constants with function calls will always bring some trouble, suddenly you need to rearrange your structures, optimizations get missed (in extreme cases you can accidentally introduce a DIV instruction), etc. So it is not surprising that code assumes 4k pages.

Any code that does divisions and modulos with non-constants that are known to be powers of 2 should do the optimization manually.

Even for non-powers-of-two there are also techniques to speed up divisions if the same divisor is used repeatedly.

Emulating a processor with 4K size pages becomes much higher performance if you can use real addresses directly.