Re: RFS: smali-1/1.4.2-1 [ITP]
That makes sense, I'll rename it to libsmali-1-java and move it to
android-tools. Although I think it would also make sense if you had
put libsmali-java in pkg-java in the first place, since it's just a
Both WALA and Jack use APIs in dexlib that are removed in dexlib2.
When I was trying patching the code I got thousands of compilation
errors. I suppose dexlib2 must has lots of breaking changes, although
I'm not familiar with the library.
Even if I'm familiar with the library, I can't make sure that no bugs
Due to such vast changes between the 2 major versions, third-party
projects might not consider migrating to dexlib2 anytime soon.
2017-02-18 5:28 GMT+08:00 Markus Koschany <firstname.lastname@example.org>:
> On 16.02.2017 11:12, 殷啟聰 wrote:
>> Hi pkg-java team,
>> I have prepared for a new source package smali-1  which builds the following:
>> * libsmali-dexlib-1-java
>> It is the version 1.x of dexlib which is incompatible with dexlib2 in
>> the existing libsmali-java  but is need by both Jack (The Android
>> compiler) and WALA (Java bytecode analysis).
> I would move smali-1 to the android-tools repo as I did with
> libsmali-java. I also suggest to rename the source package to
> libsmali1-java or libsmali-1-java. I'm not sure if we really should
> package another version of smali though. How much work would it be to
> make the WALA and Jack code compatible with the most recent version of