Strings with new-line doesn't get restored correctly about androidlibrary HOT 11 CLOSED

Android converts enter keys to a simple white space.
The normalA and normalB string keys contain the same value for the Android system.

<resources>
    <string name="normalA">Hello there. 
        General Kenobi!
    </string>
    <string name="normalB">Hello there. General Kenobi!</string>
</resources>

There are some differences using StringCare:

<resources>
    <string name="obfuscated" hidden="true">Hello there. 
........General Kenobi!
....</string>
    <string name="normal">Hello there. 
        General Kenobi!
    </string>
</resources>

Dots represents the white spaces the plugin reads parsing XML resources

• After the reveal process, the obfuscated string key will return Hello there.[original tab space]General Kenobi![original tab space].

• The normal string key will return Hello there. General Kenobi!.

Solution

Since v2.2 you can use the new-line char; obfuscated and normal string keys return the same:

<resources>
    <string name="obfuscated" hidden="true">Hello there.\nGeneral Kenobi!</string>
    <string name="normal">Hello there.\nGeneral Kenobi!</string>
</resources>

Use \n char for adding new lines.

You can find this info on Resource Tips page

from androidlibrary.

That's incorrect to close it.
When the string is too long, and you format the XML via the IDE, it adds new-line (which is actually white space). It can even happen in the beginning of the string.

Using the normal getString (without the "hidden" attribute of course) will ignore it, while SC.reveal will assume it's a part of the string.

This is still a bug.
StringCare should handle the string exactly like getString.
It used to work fine with it on version 0.9. All versions after 0.9, including 2.2, have this bug.

In addition, it's wrong to set new rules about the strings, that work fine on getString . Everything that works with getString should work with SC.reveal

from androidlibrary.

I'll try to fix that case on the next update. Meanwhile, use v0.9.

With the Android logic, your final value (I suppose) should be like this:

asdf asdf asdf asdf asdf asdf asdf asdf asdf asdf asdf asdf asdf asdf asdf asdf asdf asdf asdf asdf asdf asdf asdf asdf asdf asdf asdf asdf asdf asdf asdf asdf asdf asdf asdf asdf asdf asdf asdf asdf asdf asdf asdf asdf asdf asdf asdf

From this:

<resources>
    <string name="normal">asdf 
        asdf
        asdf
        asdf
        asdf
        asdf
        asdf
        ....
        asdf
        asdf
        asdf
        asdf
        asdf
        asdf
        asdf
        asdf</string>
<resources/>

from androidlibrary.

Thank you.

from androidlibrary.

Is this fixed? I've noticed there is a new version...

from androidlibrary.

Not yet

from androidlibrary.

Oh ok.
Thank you.
Please update me when it gets fixed.

from androidlibrary.

@AndroidDeveloperLB check out v3.0.
Related to this issue: Now by default the plugin process strings like the Android system, so the password you use should be the same as the original.

from androidlibrary.

Seems to work on the sample test project I've made, but what is this:

• Obfuscation fails when there are comments on XML files
• Compiled published libraries (i.e. jcenter()) with obfuscated strings won't work properly; the original fingerprint is needed.

The first I can't confirm. It still works fine. See attached file:

StringCareTest.zip

I don't understand the second one, but I get this issue instead, even before making a release version:
#52 (comment)

from androidlibrary.

• Obfuscation fails when there are comments on XML files
  This was an error caused by the old XML reader method. It has been fixed.
• Compiled published libraries (i.e. jcenter()) with obfuscated strings won't work properly; the original fingerprint is needed.
  Libraries uses the main module's fingerprint. If you publish and use a library, it won't use the same fingerprint as used when was compiled.

from androidlibrary.

So if it's fixed, I think you should remove it.

About the fingerprint, I don't understand. You mean that if I use this repository in a different Android-library that I want to publish as a repository that others will use? You mean that in this case, it might not work? Or that it will just work differently?

from androidlibrary.