AndroidOS/MalLocker.B has employed both name mangling and meaningless variable names in source. AndroidOS/MalLocker.B has stored encrypted payload code in the Assets directory, coupled with a custom decryption routine that assembles a .dex file by passing data through Android Intent objects. 
Charger encodes strings into binary arrays to make it difficult to inspect them. It also loads code from encrypted resources dynamically and includes meaningless commands that mask the actual commands passing through.
|S0539||Red Alert 2.0|
Windshift has encrypted application strings using AES in ECB mode and Blowfish, and stored strings encoded in hex during Operation BULL. Further, in Operation BULL, encryption keys were stored within the application’s launcher icon file.
|S0318||XLoader for Android|
Application vetting techniques may be able to alert to the presence of obfuscated or encrypted code in applications, and such applications could have extra scrutiny applied. Unfortunately, this mitigation is likely impractical, as many legitimate applications apply code obfuscation or encryption to resist adversary techniques such as Repackaged Application. Dynamic analysis when used in application vetting may in some cases be able to identify malicious code in obfuscated or encrypted form by detecting the code at execution time (after it is deobfuscated or decrypted). Some application vetting techniques apply reputation analysis of the application developer and can alert to potentially suspicious applications without actual examination of application code.
Malicious obfuscation of files or information can be difficult to detect, and therefore enterprises may be better served focusing on detection at other stages of adversary behavior.