Closed GoogleCodeExporter closed 9 years ago
Yep confirmed. First bug report here about that
http://forum.xda-developers.com/google-nexus-5/help/apktool-android-l-preview-t2
796555
My response:
http://forum.xda-developers.com/showpost.php?p=53824583&postcount=2375
Original comment by connor.tumbleson
on 7 Jul 2014 at 1:59
Issue 659 has been merged into this issue.
Original comment by connor.tumbleson
on 24 Jul 2014 at 6:40
Changes to 9patch:
https://github.com/android/platform_frameworks_base/commit/6381dd4ff212a95be30d2
b445d40ff419ab076b4
Open source L Google apk:
https://github.com/google/iosched/tree/master/android/src/lpreview
Original comment by connor.tumbleson
on 3 Aug 2014 at 3:46
Issue 668 has been merged into this issue.
Original comment by connor.tumbleson
on 12 Aug 2014 at 12:15
Issue 676 has been merged into this issue.
Original comment by connor.tumbleson
on 1 Sep 2014 at 11:30
Original comment by connor.tumbleson
on 2 Oct 2014 at 7:14
Just as an experimental hack, I commented the exception in ResConfig.java(line
number 63) and ResResSpec.java (Line number 112) and now it works for me.
Built the apktool.jar file.
Command used: java -jar apktool.jar d -f framework-res.apk
Output:
I: Using Apktool 2.0.0-dirty on framework-res.apk
I: Loading resource table...
I: Loading resource table...
I: Decoding AndroidManifest.xml with resources...
I: Regular manifest package...
I: Decoding file-resources...
I: Decoding values XMLs...
I: Copying assets and libs...
I: Copying unknown files...
I: Copying original files...
I used framework-res.apk from Android L project. Also tried few other APKs from
L, they all seem to work fine now.
Obviously this is not the right fix, but just wanted to share this update.
Original comment by so...@malhotraz.com
on 7 Oct 2014 at 11:36
[deleted comment]
Original comment by connor.tumbleson
on 10 Oct 2014 at 2:43
The duplicate wrongly identified resource is as follows
config uiModeType=0-v8:
resource 0x01030128 android:style/Theme.DeviceDefault: <bag> (PUBLIC)
uiModeType=0 is an actual qualifier, which I've never seen before. However aapt
d configurations confirms it.
ibotpeaches@raganok:~/Downloads/Apktool/Bug653$ aapt d configurations android-l.jar
large-v4
television-v8
uiModeType=0-v8
... etc
There is also another strange qualifier "450mccko". You can pull 450mcc out
which is a known qualifier, but this random "ko" at end makes no sense. These
qualifiers are then ignored and fall into the [DEFAULT] config, which obviously
already has that ResSpec thus duplicate error occurs.
I'm hoping the release of Android Lollipop source tomorrow explains this. We
can get a patch out quickly then. I will be pulling down the source as soon as
possible and building new aapt binaries for all platforms.
Basically, hold tight. I think we can solve this easy tomorrow.
Original comment by connor.tumbleson
on 16 Oct 2014 at 1:21
Okay the source dropped help. This has been fixed.
I need to make new aapt binaries to enable recompiling of these apks. However,
I'm not yet seeing a tag or branch for Lollipop.
The instant this comes out, I will bundle those platform aapts (mac, linux,
win) into Apktool and release a build.
I will close this bug and others when this is completed.
Original comment by connor.tumbleson
on 17 Oct 2014 at 7:07
can you put up the apktool.jar file for those of us who are waiting for that
file only?
Original comment by flex...@gmail.com
on 17 Oct 2014 at 8:35
[deleted comment]
Aapt binaries are part of apktool.jar
Original comment by dankoma...@gmail.com
on 17 Oct 2014 at 9:09
I've tried decompiling Settings.apk, SystemUI.apk and Calculator.apk from the
Android L project and apktool did it. But when I tried the GoogleDialer.apk,
GoolgeContacts.apk and framework-res.apk, the same issue appears. What to do?
Original comment by ryanreyc...@gmail.com
on 19 Oct 2014 at 4:52
well did you do the needed setups
apktool if framework-res.apk
apktool if SystemUI.apk
HTC FILES
apktool if com.htc.resources.apk
apktool if com.htc.resources.apk
and depending on the system you might need to install others
Original comment by raziel...@gmail.com
on 19 Oct 2014 at 1:28
instructions from following here
https://code.google.com/p/android-apktool/wiki/FrameworkFiles
Original comment by raziel...@gmail.com
on 19 Oct 2014 at 1:30
Looks like work has been done and everything works fine? Could we expect rc3 or
something in the coming days?
Original comment by Milosz.Lewandowski
on 27 Oct 2014 at 11:01
Not till AOSP Lollipop is released. I need the changes in aapt so I can fix
rebuilding for it and also implement #688.
Original comment by connor.tumbleson
on 27 Oct 2014 at 11:36
[deleted comment]
I'm deleting all comments asking for a "hacked" version. This a bug tracker not
a support forum for collecting unofficial builds. You can safely decode Android
Lollipop apks with the current codebase. If you wish to do that, you can pull
down the source and build it.
These two commits added that support
https://github.com/iBotPeaches/Apktool/commit/99c1ab96da39d7c145552167423d4ca2a1
d85291
https://github.com/iBotPeaches/Apktool/commit/5bc76f197f9f5d93caede056e12ee6814c
39efff
(Note there was an internal framework update so deleting the framework at
$HOME/apktool/framework/1.apk is required)
You however cannot recompile Lollipop apks after decode as AAPT source is not
yet available. This bug report will be closed when decode / build works again
on Lollipop. Shortly after an official release of RC3 will come with those
changes.
Original comment by connor.tumbleson
on 27 Oct 2014 at 7:20
[deleted comment]
You don't like to read don't you? He clearly said she ull have to wait and you
can't recompile for now, only decompile.
Original comment by flex...@gmail.com
on 29 Oct 2014 at 12:13
[deleted comment]
Can all of you please read Connor's comment #19 on this issue? He specifically
states that aapt source is needed to fix apktool for recompiling. This will
come when the full source for lollipop is released. It would be awesome if
people could read through the issue's comments before asking redundant
questions. Everybody who starred this issue gets notifications every time
someone comments, and it's getting to the point I'm about to unstar this issue
because it's getting annoying.
Original comment by dankoma...@gmail.com
on 29 Oct 2014 at 2:16
[deleted comment]
[deleted comment]
[deleted comment]
[deleted comment]
Now with AOSP Lollipop, lets get to work. A lot more than I expected, and I
mean a lot.
anydpi qualifier -
https://github.com/android/platform_frameworks_base/commit/31245b4f06003f1c8cd44
c31b387c96ab4e282f9
of interest (aapt is versioned now) -
https://github.com/android/platform_frameworks_base/commit/71809ee7f63229d0ea4f6
169922ddfbfee330fd2
language / country moved to BCP-47 format -
https://github.com/android/platform_frameworks_base/commit/788fa41482b9d398591b7
db8b0b01839029611ad
-> reading mcc - https://github.com/android/platform_frameworks_base/blob/lollipop-release/tools/aapt/AaptConfig.cpp#L267
-> reading mnc - https://github.com/android/platform_frameworks_base/blob/lollipop-release/tools/aapt/AaptConfig.cpp#L297
The minimum compatibility level has a new entry. If the density has the anydpi
attribute it is bumped to 21 -
https://github.com/android/platform_frameworks_base/blob/lollipop-release/tools/
aapt/AaptConfig.cpp#L237
the watch aapt qualifier -
https://github.com/android/platform_frameworks_base/commit/6c191299a73388cd59380
9c0b66bafbd08fd2982
addition of --replace-version to allow replacing versionName & versionCode in
manifest, instead of us removing them -
https://github.com/android/platform_frameworks_base/commit/df08d1c24dbbc242978ee
33416d1e54998f88915
Also interesting is split apks, changes to outline of 9patch generation,
supporting multiple resource tables that have same package, and much more.
To answer the questions that most of you are wondering.
Q) but but it already works with some Lollipop apps, what is all of this?
A) Applications haven't utilized this newer stuff yet.
Q) Whats next?
A) aapt source won't change anytime soon now that its pushed. I will get the
newer aapts into apktool asap, then begin work on the other changes
Q) When will RC3 come?
A) After I handle this change to BCP-47 format for locale/language, add support
for anydpi qualifier, update the min compat section for API 21, rebuild all
internal aapts and test for regression.
Q) When? WHEN?? WHEN????!?!
A) Give me a week / two. Nothing looks terribly difficult. I'm typing this from
class, so I might have missed a commit or two that are relevant to Apktool.
Please don't spam this bug report as lots are following and receive an email
for every response. I will post status updates as things are completed.
Original comment by connor.tumbleson
on 4 Nov 2014 at 4:56
Status Update
We encountered a problem with AOSP builds of aapt not working in our specific
use case. After a few days of examining the source, I tracked it back to the
AssetManager. My knowledge of that area of AOSP is next to none.
For that reason, I reported a bug. Within 4 hours it was assigned to someone
which is amazing compared to the success of other bug reports to AOSP:
https://code.google.com/p/android/issues/detail?id=79068
In the meantime, I'm trying to patch AssetManager myself, but it's a learning
game right now.
Most of the apktool changes are already fixed locally. So once the blocker of
aapt is solved, we should theoretically be good to go.
As usual, please do not comment as everyone gets notified. I will update again
when the aapt situation is resolved.
Original comment by connor.tumbleson
on 11 Nov 2014 at 5:42
Issue 703 has been merged into this issue.
Original comment by connor.tumbleson
on 14 Nov 2014 at 7:37
Issue 705 has been merged into this issue.
Original comment by connor.tumbleson
on 17 Nov 2014 at 1:01
https://github.com/iBotPeaches/Apktool/pull/97
I'd say this is very close to being fixed. All the current Lollipop APKs I've
thrown at it have been handled without error. aapt has become very restrictive
however. This means apks that compiled before hand might not compile
immediately this time. Manual intervention might be required.
I've thought about this and I don't think its Apktool's job to fix up APKs to
make them in a suitable format for recompilation. In an IDE w/ linting support
like Android Studio and the source at hand, it would make sense to guide the
user for the changes required with a new build engine. Note not all apks are
affected by this. This is only when apks utilized methods that weren't official
like
- utilizing private resources
- improper manifest order of certain elements
- more than I can't remember
Please don't post asking for a binary. If you can't build a version yourself
from this pull request, then await for the official binary. (Hoping for this
weekend)
If you do build the version and test it out. Make sure to remove all frameworks
in $HOME/apktool/framework/*.apk. A change was made which requires those to be
rebuild. You WILL receive errors if you don't do this.
Original comment by connor.tumbleson
on 21 Nov 2014 at 5:56
Thanks, connor.
I'm trying to build it myself from your pull request on Windows, however when I
run "gradlew.bat build fatJar", I get the error message:
Exception in thread "main" java.lang.RuntimeException: Could not determine
wrapper version.
at org.gradle.wrapper.GradleWrapperMain.wrapperVersion(GradleWrapperMain.java:106)
at org.gradle.wrapper.GradleWrapperMain.main(GradleWrapperMain.java:48)
Caused by: java.lang.RuntimeException: No build receipt resource found.
at org.gradle.wrapper.GradleWrapperMain.wrapperVersion(GradleWrapperMain.java:92)
... 1 more
Am I missing anything?
Otherwise - if anyone was successful at building this, care to upload your jar?
Thanks :)
Original comment by purpl...@gmail.com
on 23 Nov 2014 at 7:34
Never mind, successfully built.
For those curious, the problem was that I had a special character (exclamation
mark) in the path.
Original comment by purpl...@gmail.com
on 23 Nov 2014 at 1:38
This has been merged:
https://github.com/iBotPeaches/Apktool/commit/02b5c7c57bece45ef4c512289b30d3728e
8f0a29
Binaries to follow tonight. Lots of prep work in writing docs to do a release.
Original comment by connor.tumbleson
on 26 Nov 2014 at 5:59
Original issue reported on code.google.com by
derp.ind...@gmail.com
on 7 Jul 2014 at 4:59