Bug: library doesn't seem to obfuscate anymore, as the strings can be found, hard-coded...

[AndroidDeveloperLB]

classpath 'io.michaelrocks:paranoid-gradle-plugin:0.3.7'

I've noticed that the strings I was sure that this library obfuscate actually appear as they are, not obfuscated at all.

Steps:

1. Either import the attached project, or use this:

@Obfuscate
object Keys {
    //
    const val SECRET_KEY = "HelloParanoid"
}

class MainActivity : AppCompatActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)
        Toast.makeText(this, Keys.SECRET_KEY, Toast.LENGTH_LONG).show()
    }
}

2. Create a release-version. You can use the keystore I've added here. Password and everything there is just "keystore".
3. De-obfuscate using some tool. I used:

http://www.javadecompilers.com/apk

4. Download the result (there is a button there of "Save"), and extract it.
5. Search inside the extracted folder for the value of the obfuscated key. In this case search for "HelloParanoid".

The bug is that it's still there as it is, hard-coded:

...
Toast.makeText(this, "HelloParanoid", 1).show();
...

ParanoidTest.zip

For a moment I thought this is because I use Kotlin, but it happens on Java too....

How could it be? I remember it worked fine in the past, no?

[cesarsicas]

@AndroidDeveloperLB Just test in my project and is working fine. Did you apply the plugin on your gradle module ?

apply plugin: 'com.android.application'
apply plugin: 'io.michaelrocks.paranoid'

[MichaelRocks]

@AndroidDeveloperLB I think the string isn't obfuscated in your case because you apply @Obfuscate annotation to the Keys class. But the compiler inlines the string into the MainActivity class, which isn't obfuscated. I know about this issue but I don't have a good idea how to fix it because on the bytecode level the Keys class isn't used in MainActivity.

[AndroidDeveloperLB]

@cesarsicas The entire code is in the sample. It already uses the plugin

@MichaelRocks I don't understand. What did I do wrong? It doesn't work even on this basic case...
What should I do? Why was it closed if you confirm it's a real issue?

BTW, it doesn't matter where it's used. Wherever I use it, it becomes hard-coded values.

[MichaelRocks]

It's an unwanted but expected behavior. Obfuscation should work if the @Obfuscate annotation is applied to MainActivity. If it doesn't work reopen the issue please and I'll check why it can happen.

[AndroidDeveloperLB]

@MichaelRocks I can't reopen the issue. I can only comment once the owner of the repository has closed it.

See attached after the change you wanted (works fine this way) :

ParanoidTest.zip

Why only this way it works? Shouldn't it be used in the place that has the keys? After all, the keys can be used in more than one place...
What if inside the class of keys, I would have a function to return one of the keys?
Would you still say it won't work?
And why did it work in the past this way, just fine?

What if I have multiple keys?
Having each one spread on various files, it makes it quite annoying to use, and it's not managed well this way...

[MichaelRocks]

It will work if the key isn't a compile time constant which is inlined by the compiler. So you can fix it by removing const or by converting the variable to a function. And it always worked this way.

[AndroidDeveloperLB]

@MichaelRocks How come const will work in the example you showed though?
I suggest you to mention these restrictions on the main page of the repository, showing examples of the workarounds you've mentioned (in actual snippets).
I'm also sure it worked fine with constants in the past though.

[MichaelRocks]

I've tried to build your project and as far as I can see it's obfuscated properly.

[AndroidDeveloperLB]

@MichaelRocks Which one? I already wrote that for the new one it works fine, because that's what you told me to try...

[MichaelRocks]

The second one which I expected to work properly. OK, let's keep this issue open and I'll think what I can do with it.

[AndroidDeveloperLB]

@MichaelRocks Thank you!
Please for now write about this though. I didn't expect it to fail in this case, and I remember it worked fine in the past.

[AndroidDeveloperLB]

@MichaelRocks BTW the workaround of using just "val" instead of "const val" seems to work well.

[Monabr]

Not working even with val instead of const val