Декомпиляция обычно не идеальна даже при переходе от .class файлов к .java файлам.
С одной стороны, это объясняется тем фактом, что компиляция не представляет всю информацию из исходного файла в файле .class. Пробелы и комментарии являются наиболее очевидными примерами информации, которая не представлена в .class файлах. Имена локальных переменных также часто пропускаются, и в зависимости от ваших флагов компиляции даже имена аргументов могут быть потеряны.
С другой стороны, рынок декомпиляторов кажется довольно ограниченным, а отсутствие конкуренции приводит к тому, что декомпиляторы работают не так хорошо, как, вероятно, может . Например, каждый новый выпуск компилятора Java может создавать новый код, который будет нуждаться в эквивалентном обновлении декомпилятора для обнаружения новых шаблонов и создания из них соответствующего источника Java. В отсутствие такого обновления декомпилятор обречен на либо сбой, и вместо этого выводит дизассемблирование байт-кода или создает странные конструкции, которые делают то же самое, но никогда не будут написаны человеком .
А когда вы добавите другой уровень компиляции (Java Byte Code -> Dalvik Byte Code), тогда это может только ухудшиться.
Если вы не можете привести конкретный пример какого рода несоответствий вы имеете в виду, трудно дать лучший ответ.