I asked that question myself before[1], and others, too [2].
But the answer is a clear no. Read this explanation [3] on oss-security where someone lays out in detail in which ways ASAN creates security problems.
It ultimately is just not built as a protection mechansim, but as a debugging tool. While you'd catch some bugs (UAFs, Buffer overreads), you introduce others.
Maybe there could be a "like asan but designed for production" tool. I think Softbound-CETS was trying to go in that direction, but never became production ready and is as far as I know no longer developed. But right now such a tool does not exist.
Though however what absolutely should be done: Every C/C++-written tool should be tested with ASAN. This doesn't happen (not a single Linux distro uses ASAN testing as a default practice before adding packages), and this is very sad. (I know this because I still find major packages that have ASAN-findable bugs exposed by their own test suite.)
Although having a Linux kernel is an implementation detail on Android, and they might as well replace it by something else tomorrow, it is probably the only use case where the Linux kernel gets deployed in the wild with most security knobs turned on.
SELinux, seccomp, CFI, libc with FORTIFY, forced initialization of kernel data structures, ASAN as required testing, ...
That could be read as : even the most secure Linux environment currently and what could be seen as security best practice ( which your post helpfully enumerates ) requires asan for testing only.
But the answer is a clear no. Read this explanation [3] on oss-security where someone lays out in detail in which ways ASAN creates security problems.
It ultimately is just not built as a protection mechansim, but as a debugging tool. While you'd catch some bugs (UAFs, Buffer overreads), you introduce others.
Maybe there could be a "like asan but designed for production" tool. I think Softbound-CETS was trying to go in that direction, but never became production ready and is as far as I know no longer developed. But right now such a tool does not exist.
Though however what absolutely should be done: Every C/C++-written tool should be tested with ASAN. This doesn't happen (not a single Linux distro uses ASAN testing as a default practice before adding packages), and this is very sad. (I know this because I still find major packages that have ASAN-findable bugs exposed by their own test suite.)
[1] https://blog.hboeck.de/archives/879-Safer-use-of-C-code-runn...
[2] https://scarybeastsecurity.blogspot.com/2014/09/using-asan-a...
[3] https://www.openwall.com/lists/oss-security/2016/02/17/9