A plain text string like this will be visible by looking at the file in a hex editor (like
hte or a viewer like
od) or with the Sysinternals
strings command or with
strings(1) on a Linux/FreeBSD etc, for example. Most reverse engineering tools have a separate view for strings, because those are usually exceptionally useful to reverse engineers. Amirag already pointed that out for IDA.
In terms of Android that C++ file is likely going to end up as a shared object in ELF file format. These are binary files with a known structure. Simply by looking at the exported functions/symbols, it will be trivial to find the "secret". Even if you were to obfuscate this further, it would still not help. Obfuscation is security through obscurity. It's not actual security. So even writing that string as some xor-ed array of bytes or using the Caesar cipher will add no tangible protection if that's the goal.
Furthermore you should never ever include the private key in code that ends up with the user. The reason why it's called a secret is because it should be kept secret. Just "mangling" the representation of this secret with a compiler isn't going to help at all.
If it's a secret the user shouldn't see, this belongs on the server-side or into a HSM (hardware security module), but not on the user's machine in any form. There is no other way to reconcile mistrusting the user and at the same time placing "secrets" into the user's hands. It's the fundamental conundrum of software protection mechanisms also.