Replies: 5 comments
-
I'm not following how this is possible. We invoke completely different tools for assembling smali files and building resources (aapt2) back to the binary arsc. So I don't see a situation how we'd detect a string reference in smali and adjust the related resource files.
We (Apktool) have to use that public.xml at present as its a way to keep resourceIds consistent at the cost of making them public. The alternative is rewriting the resourceIds during assembly time. How are you adding new entries to public.xml? Some folks make a mistake and just increment the last entry. With sparse tables and more - you have to properly find the value available in the respective type.
Please I struggle to follow this. |
Beta Was this translation helpful? Give feedback.
-
I forgot to say that when I compile with apktool, I am using aapt2. And yes, I don't think there is a way to detect a string reference in smali and adjust the related resource files. Could this be why it compiles ignoring these strings and not adding them to the strings.xml file? The weird thing is, as I said, it does add their names to the public.xml list and assigns new ids to them, why doesn't it add them to the strings.xml resource file?
Yes, I imagine that to add new entries, it is not enough to add 1 to the identifiers, you have to put the type of resource in the correct section, and for that you would have to move all the positions of the IDs, therefore I don't do it. I use apktool to compile and it does it automatically, but what I mentioned above happens.
I mean, I could create a small application in which I don't do anything, decompile it with apktool, and add some strings to the strings.xml file without naming them in any layout or other resource, and share the project with you, so you can compile it yourself, and check that those strings are added to public.xml, but not kept in strings.xml, although you could also try it with any application, decompile with the latest version of apktool, add some strings, and then compile. When you decompile the application again, those strings will not appear in strings.xml but their names will appear in public.xml and the new IDs that apktool generated in the compilation. This is why I consider it a problem, I don't know right now if it will be the fault of apktool or aapt2, since by not detecting their use in the resources it deletes them, when perhaps if you are using them in calls from smali (java ), as I explained at the beginning, and that I understand that there is no way to detect these methods, which load the resources by name instead of by ID. But maybe there is a way to ignore not adding these resources (strings) in the strings.xml file if its use has not been detected. I understand that maybe it's not apktool's fault, and it could be aapt2's, but as I told you in the first message, in versions prior to 2.7.0 of apktool this didn't happen. I want to apologize for my English, and in case I don't explain myself clearly about something. |
Beta Was this translation helpful? Give feedback.
-
|
Okay, so it seems you use Apktool in a build/disassemble loop to auto-generate ids and fulfill the the static resourceIds as a by-product of that. I assume at that point since it did the hardwork you know the id to use in sources. Though you mention this process did work on 2.7.0. So just would love to get a sample and a guide of what you are doing. Some form of steps that you can say - "follow this and it works in 2.7.0, but fails in 2.8.1" |
Beta Was this translation helpful? Give feedback.
-
|
Sorry for not replying sooner, I'm pretty busy. I know and understand how the generation of identifiers for the resources in Apktool works, and I know that when compiling and decompiling the identifiers of the new added resources appear, but I don't use identifiers at least with Apktool, because in each update of the application , it would have to be looking for their new IDs, and for me it is more practical to use the names of the resources and that the code itself looks for the identifier. Sorry, I didn't express myself well, it didn't work in 2.7.0, in the last version that worked from what a friend told me, it was in 2.6.1, I didn't notice the problem until these latest versions. Regarding the steps to follow, it is what I explained to you in previous messages, what the problem is and what to do to reproduce it. In version 2.6.1 this should not happen, that is, the strings should appear and be read from the smalis. |
Beta Was this translation helpful? Give feedback.
-
|
I just saw the new Apktool publication, and I have seen the list of changes and I hope that what you did has solved the resource problem, when I have time, I will check if it is solved specifically for the Strings problem. Thank you very much for your work and your effort. 😊 |
Beta Was this translation helpful? Give feedback.
-
Information
From version 2.7.0 to current version
Windows
PlayStore and Apkmirror
Java 17.0
Steps to Reproduce
java -Xmx1024m -jar apktool.jar b D:\Apktool\file.apk -f -o "D:\Apktool\Dmp\File.apk" -p 1.apk
Questions to ask before submission
apktool d,apktool bwithout changing anything? YesThe problem I have, is approximately since apktool version 2.7.0, when Strings are added, which are not called from resources, but from Java code (smali), but a call is made to the name of the resource, instead of by its ID, of the type R.id.resourcename, some of the times, when the app is compiled again, these Strings, which are called in this way, and not from layouts for example, are not added to the list of Strings, it's as if the compiler ignores them and does not add them to strings.xml as the compiler believes that they are not being used. Although there have also been cases, in which I have used these Strings in Layouts, and then when I want to load them by name in Java, it does not detect them as if they were not in the list of strings.xml either, the truth is that it is a somewhat random behavior , and it doesn't usually happen in many strings. The funny thing is that if you add the name of the strings to the public.xml and give it an id, but the Strings doesn't appear in the strings.xml file.
I've been having this problem for a long time, but I couldn't identify what was happening exactly, but yesterday after compiling my project again, and seeing the strings fail, showing random strings instead of the corresponding ones, I decompiled my project once compiled, and I realized that the strings that were failing and that I got random names instead of what they should, were not in strings.xml, but their name and ID were in public.xml
This is happening to a few other people as well, and they end up resorting to using strings that are detected correctly, or an apktool version equal to or lower than 2.7.0. I even tried changing one of the strings that wasn't displaying correctly, to one that was displaying correctly, just in case it was a Method problem, but no, when I put the "good" string its value was displayed correctly, instead when I went back to the other one, same problem, it gave me a random string (I want to clarify that with a random string, it's a random one specific to the string used, it's not that every time it's shown, it's a different one every time).
I'm also not sure if the problem is directly related to not storing the string correctly in strings.xml because as I said I did one last test using one of the failed strings in the layouts, and it displayed correctly, but then when displaying it through from a Toast, calling the string by its name instead of its id, returned a different one. And this is not happening on all strings, just some.
If you could catch the error I'd appreciate it, as I now fall back to using a Java assignment to call strings that have these issues.
If necessary, I would deliberately create a small project to try to reproduce the compile error in the latest versions, and share it with you.
Beta Was this translation helpful? Give feedback.
All reactions