"Total memory" is pretty pointless (for example, G1 has 192 MB of physical memory, of which between 90-100 MB is available to the kernel and applications of different versions, but this does not include the memory used for the buffer window and other things, and every Java application has a limit of 16 MB for its heap, so the available RAM for the system depends more on how many processes can work simultaneously).
The "amount of free memory" is really really pointless. As a rule, we try to keep so many applications running as there is available memory, so there is generally little free memory between these and regular Linux caches. If you look at the raw free memory in the kernel, you will see that over time, when applications start up and use some kind of memory, they repel, and then other applications fail, which leads them to jump back. while caches and other things have a chance to gobble it up.
The best way that I came at this point to look at the state of the system’s memory is with the "Running services" interface, which was introduced in 2.0. Yes, the memory information below is very subtle and meaningless for most people; we should try to figure out how to improve it. :)
You can find out the CPU architecture for the NDK code using android.os.Build.CPU_ABI. This gives you a basic foundation for the CPU architecture, but information, for example, on whether the processor supports NEON instructions or something similar. For such information, you could use the NDK to run your own code to query the CPU.