2016-07-14 15 views
2

ich mit einer inneren Oberfläche wie diese eine Java-Klasse erstellt:Kein Zugriff auf innere Schnittstelle von einem ProGuard-ed JAR

public class TaskManager { 
    ..other codes.. 

    public interface TaskManagerListener { 
     void onLoad(); 
    } 

    ..other codes.. 
} 

Dann wickelte ich es in einem JAR ProGuard für Verschleierungs mit/schrumpft.
I verwendet, um die folgende ProGuard Konfiguration:

-keepattributes InnerClasses 
-keep public class package.name.of.TaskManager { *; } 
-keep public interface package.name.of.TaskManager$TaskManagerListener { *; } 

I aus der JAR verifiziert, dass die Klasse und die innere Schnittstelle gibt es: this image.

Mein Problem ist jetzt, wenn ich versuche, von dem Code, der die JAR verwendet, auf diese innere Schnittstelle zuzugreifen. Ich kann auf die Klasse TaskManager zugreifen, aber der Zugriff TaskManager.TaskManagerListener löst einen Kompilierungsfehler aus.

Diese Arbeit:

  1. public class MyTaskManager extends TaskManager {..}
  2. TaskManager tm = new TaskManager();

die aber nicht:

  1. public class MyTaskManagerListener implements TaskManager.TaskManagerListener

  2. new TaskManager.TaskManagerListener() { @Override public void onLoad() {..} });

A angehoben Fehler "Can not Symbol TaskManagerListener lösen".

Ich habe versucht, die TaskManager.TaskManagerListener aus dem ursprünglichen Code der JAR-Bibliothek zugreifen und es funktioniert OK. Ich denke, ich kann nur nicht darauf zugreifen, wenn es in einer JAR ist ..?

Gibt es eine Möglichkeit, dies zu erreichen?
Oder ist meine Erwartung falsch?
Ich bin mir nicht sicher, ob etwas in meiner ProGuard-Konfiguration oder mit meinem Verständnis von Java und inneren Schnittstellen fehlt.

Ich überprüfte bereits this Antwort und ich erwäge bereits die Problemumgehung, eine verschachtelte Schnittstelle nicht zu verwenden.

Antwort

0

Ich habe einen dummen Fehler gemacht.
Die ProGuard-Konfiguration, die ich verwendet habe, war eigentlich richtig, aber eine andere keepattributes !InnerClasses Option negiert die Konfiguration, die ich verwendet habe (anscheinend, ist die Reihenfolge der keepattributes Optionen nicht wirklich wichtig).

Dies ist immer noch richtig:

enter image description here

die jetzt diese Arbeit macht:

1. public class MyTaskManager extends TaskManager {..} 
2. TaskManager tm = new TaskManager(); 

-keepattributes InnerClasses 
-keep public class package.name.of.TaskManager { *; } 
-keep public interface package.name.of.TaskManager$TaskManagerListener { *; } 

, die die verschleierten JAR unten produzieren