Following up on my own post, the test I ran was not thorough enough,
and the following rules are the ones actually required to make WebView
callbacks work properly:
--------------------------
-keep public class com.trans_code.android.JavascriptCallback
-keep public class * implements com.trans_code.android.JavascriptCallback
-keepclassmembers class * implements com.trans_code.android.JavascriptCallback {
<methods>;
}
--------------------------
On Sun, Nov 7, 2010 at 7:17 PM, Stephen Jungels <sjung...@gmail.com> wrote:
> Thanks, I followed up on that idea by creating a placeholder
> interface; I am limiting this to the problem of WebView callbacks so I
> call it "JavascriptCallback".
>
> If I follow the convention of implementing this interface wherever
> appropriate, the following Proguard rules work:
>
> ---------------------
> -keep public class * implements com.trans_code.android.JavascriptCallback
> -keepclassmembers class * implements JavascriptCallback {
> void on*(***)
> }
> ---------------------
>
> My Proguard knowledge is basic but this seems to be enough for the use
> cases I can think of, where a convention is assumed that callback
> methods will start with "on".
>
> I wonder if this placeholder interface or something similar should be
> in the framework as a general purpose tag for RPC-type callbacks to
> Java that should not be renamed by an obfuscator.
>
> --SJ
>
> On Sun, Nov 7, 2010 at 6:35 PM, Daniel Drozdzewski
> <daniel.drozdzew...@gmail.com> wrote:
>> On Sun, Nov 7, 2010 at 10:41 PM, Stephen Jungels <sjung...@gmail.com> wrote:
>>> I've recently started using the WebView Android / Javascript interface
>>> in my projects (and I think it's pretty cool; article here:
>>> http://developer.android.com/resources/articles/using-webviews.html).
>>>
>>> The problem is that when obfuscation is turned on, the callbacks from
>>> Javascript to my Android code no longer complete, because the language
>>> binding is unaware of the renaming performed by Proguard.
>>>
>>> I can fix this on a case-by case basis; for example in the very simple
>>> code I am using now, the following additional Proguard rules are
>>> enough:
>>>
>>> -----------------------
>>> -keep public class com.trans_code.android.JsCallback
>>> -keepclassmembers class * {
>>> public void doneClicked();
>>> }
>>> ----------------------
>>>
>>> However the second rule seems too broad, and both rules are unique to
>>> each project that uses the Javascript callback.
>>>
>>> Any guidance on how a better rule can be written that catches every
>>> use of Android - Javascript bindings, and nothing else?
>>>
>>> Thanks,
>>>
>>> SJ
>>>
>>
>> Stephen,
>>
>> I am not sure, whether you would be more selective with not
>> obfuscating some classes, but you could do the following:
>>
>> - define a placeholder interface called say NonObfuscateable (I know
>> it sounds dreadful, but you get the gist)
>> - make all classes that you want to keep implement this interface
>> - tell Proguard to keep the classes that implemented your interface
>>
>> Daniel
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Android Developers" group.
>> To post to this group, send email to android-developers@googlegroups.com
>> To unsubscribe from this group, send email to
>> android-developers+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/android-developers?hl=en
>
--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
