[Android-tools-devel] Apktool

[Hans-Christoph Steiner]

Markus Koschany:
> Am 15.02.2016 um 23:35 schrieb Hans-Christoph Steiner:
> [...]
>>>> I believe that you need to join the android-tools team to get git push
>>>> access.  I added you, I don't know if you need to accept that invite or not.
>>>
>>> I haven't got any invitation yet and I guess it shouldn't be necessary.
>>> Now I get the following error message:
>>>
>>> remote: error: insufficient permission for adding an object to
>>> repository database ./objects
>>> remote: fatal: failed to write object
>>>
>>> Perhaps some manual changes for user/group ownership might be required here?
>>>
>>> https://stackoverflow.com/questions/6448242/git-push-error-insufficient-permission-for-adding-an-object-to-repository-datab
>>
>> Everything is set up properly for the android-tools group:
>>
>> eighthave at moszumanska:/git/android-tools/apktool.git$ ls -ld apktool.git
>> drwxrwsr-x  7 deki-guest      scm_android-tools 4096 Nov 22 23:24
>> apktool.git
>> eighthave at moszumanska:/git/android-tools/apktool.git$ ls -l
>> drwxrwsr-x  2 deki-guest scm_android-tools 4096 Nov 22 19:20 branches
>> -rw-rw-r--  1 deki-guest scm_android-tools  369 Nov 22 23:24 config
>> -rw-rw-r--  1 deki-guest scm_android-tools   22 Nov 22 19:20 description
>> -rw-rw-r--  1 deki-guest scm_android-tools   23 Nov 22 19:20 HEAD
>> drwxrwsr-x  2 deki-guest scm_android-tools 4096 Nov 22 19:20 hooks
>> drwxrwsr-x  2 deki-guest scm_android-tools 4096 Dec  5 19:52 info
>> drwxrwsr-x 16 deki-guest scm_android-tools 4096 Dec  5 19:52 objects
>> drwxrwsr-x  4 deki-guest scm_android-tools 4096 Nov 22 19:20 refs
>>
> 
> Then I'm most likely not a member of the scm_android-tools group yet.

Yeah, probably takes a day or something for alioth to do it.


>>>>> Apktool has one licensing issue because
>>>>> com.mindprod.ledatastream.LEDataInputStream has a usage restriction
>>>>> (non-military) and thus is non-free. I don't expect a short term
>>>>> solution for that from upstream hence I repacked the tarball and patched
>>>>> the affected sources.
>>>>
>>>> Yeah, I remember discussing this with someone, perhaps you.  If it works
>>>> without that class, that's great.  Otherwise, there are free
>>>> replacements.  Let me know if we should handle that in the package, or
>>>> with upstream, or both.
>>>
>>> This is clearly an upstream bug. I intend to file a bug report for
>>> apktool. They should either replace the non-free class with a free one
>>> or find another solution. Is the free replacement a real drop-in
>>> replacement? Then I could try to use this class. Otherwise I have to
>>> disable the functionality for now.
>>
>> Of course, its an upstream bug.  :) I meant how to handle it now.  What
>> functionality will be disabled without that class?
> 
> Disable all relevant code in
> 
> src/main/java/brut/androlib/res/decoder/ARSCDecoder.java
> 
> and
> 
> brut.apktool/apktool-lib/src/main/java/brut/androlib/res/decoder/AXmlResourceParser.java
> 
> I'm not sure what this exactly means for apktool but it is surely not an
> improvement.
> 
> Another thing: Upstream removed smali from the latest 2.0.3. release. I
> don't know if this is intentional or an oversight. We would either have
> to package smali separately or repackage the upstream tarball, so that
> it resembles version 2.0.2. I also intend to file an bug report for this
> one because the 2.0.3 release won't compile without smali. However I
> think version 2.0.2 would do for now anyway.

Packaging smali separately sounds fine.  Whichever is less work, really.
 And yes, and 2.x version is good.

.hc