With virtual memory, every process runs inside a sandbox, which is the extent of its VAS. The key rule: it cannot look outside the box.

So, think about it, it's impossible for a process to peek or poke the memory of any other process's VAS. This helps in making the system secure and stable.

Example: we have two processes, A and B. Process A wants to write to the 0x10ea virtual address in process B. It cannot, even if it attempts to write to that address, all it's really doing is writing to its own virtual address, 0x10ea! The same goes for reading.

So we get process-isolation – each process is completely isolated from every other process.
Virtual address X for process A is not the same as virtual address X for process B; in all likelihood, they translate to different physical addresses (via their PTs).
Exploiting this property, the Android system is designed to very deliberately use the process model for Android apps: when an Android app is launched, it becomes a Linux process, which lives within its own VAS, isolated and thus protected from other Android apps (processes)!

• Again, don't make the mistake of assuming that every single (virtual) page within a given process is valid for that process itself. A page is only valid if it's mapped, that is, it's been allocated and the OS has a valid translation for it (or a way to get to it). In fact, and especially true for the enormous 64-bit VAS, the process virtual address space is considered to be sparse, that is, scanty.
• If process-isolation is as described, then what if process A needs to talk to process B? Indeed, this is a frequent design requirement for many, if not most, real Linux applications – we need some mechanism(s) to be able to read/write the VAS of another process. Modern OSes provide mechanisms to achieve this: Inter-Process Communication (IPC) mechanisms. (A little on IPC can be found in Chapter 15, Multithreading with Pthreads Part II - Synchronization.)