Android apktool error - android

Hi my customer tried to add the apk to their market application and an error occured like below.
*18.Ağu.2011 12:23:14 brut.androlib.res.AndrolibResources loadMainPkg INFO: Loading resource table... Exception in thread "main" java.lang.Error: Androlib Error: Multiple resources: spec=0x7f02004c drawable/top_bar_large, config=-ldpi*
it seems the tool thinks that the drawable resource named top_bar_large has been used more than once. That's right but in different drawable directories.
I mean the image is located in the directories;
drawable-ldpi
drawable-xlarge-ldpi
As I know android handles this automatically. And I also have installed that failing (actually the tool thinks it is failing) apk to my phones and other phones ( different brand ) without any issue !
What do I need to do ? can you help me ?

I hope this is still relevant.
I would suggest one of two things. First, try the latest version of apktool. As far as I know, xlarge was added rather late to apktool. The latest version should work fine.
If not, you can try zzos (full disclosure: zzos was written by me). It is much less known, but may occasionally be able to handle APKs that apktool fails to decompile. In particular, I happen to know that xscale is supported by zzos, and has been for some time.
I hope this helps,
Shachar

Related

Android Studio Duplicate Files

I am getting duplicate files in my source code:
This happens quite often with Android Studio and it happens will all types of files, not just gradle files. It typically happens when I checkout a new branch or swith branches.
What is causing this and how can I prevent it?
As a note, this question was originally posted with image files, thus the image answers. However, this is not limited to image files and I understand why there are multiple image files for different screen densities. I have updated to reflect that there are other files being duplicated.
Do you have a Mac, and is your project stored in your "Documents" directory?
Filenames that include " 2" are generated by iCloud when it can't reconcile two versions of a file. E.g. if you have two computers, and both of them share their "Documents" directories via iCloud, and a file were to be changed simultaneously on both computers, iCloud would wind up creating e.g. a build 2.gradle file.
I found this was happening to me, even though I'm only using one computer to do my work. I suspect that Android Studio may be interacting with iCloud directly, not realizing that it's working on files that are already backed up on iCloud. (See Android Studio generating hundreds of duplicate " 2" files).
I seem to have fixed it by moving my project directory out of Documents. At any rate, I haven't had a problem since I did that.
(Credit to Mike M. for noticing the similarity between our problems.)
Since different devices support different screen densities, all non-vector image drawables should have an image asset for each type of density. So, from a development standpoint, you're using the same Drawable but the app will use the correct image size based on the screen density of the device the app is installed in. I suggest you take a look at this article for more information.
It's ok. Follow the every folder. Folder name is different according to possible phone size Different phone size is different, that’s why they support different size images.

Reducing Unity Android build size

I'm trying to get the Unity mobile Android APK build size to below 150mb, but it's currently at 170mb. I'm reading through many online docs, but can't find anything that so far reduced my build size. (For reference, I'm creating a "Virtual OS" where many virtual apps are bundled into one, and can be experienced in many different environments, so that increases size.)
My main question is, how can I find the biggest file size "offenders" in my project? Unity's doc tells me to look into the Editor Log's Build Report list, but the files mentioned in the top there (as "uncompressed", e.g. my 20k something PNG becomes a 1+mb file in that list), mainly textures, do not actually help when I next time remove them in another test build. Neither does it relevantly help when I change the Android texture setting to something more highly compressed (e.g. 1024 max Mitchell, which I had for most of my files anyway).
I've tried both APK building, as well as ABB, but both results are quite big. (Switching the API Compatibility Level from .NET 4x to 2 doesn't help either.) I'm compiling to 64bit architecture.
Edit: A first big improvement became removing an (unneeded for Android) Oculus directory (and accompanying Package Manager packages). But this wasn't shown in any charts.
Thanks for any pointers!

APKTool error ricompiling apk

I' m trying to modify the application's graphic. So when I decompile the apk using apktool with apktool d myapp.apkeverything goes well. I can see the resources and the smali folders so it's perfect. So I can modify the colour code that I need to change.
When I try to build back the application using apktool b myapkfolder no errors are displayed from apktool. But when I try to install it on my phone it says "Parse error there has been a problem for analysing the packet". So I though it use my fault modifying something wrong in the application so I tried to decompile the apk and then recompile it without touching anything in the apk folder. What I can see is that the original apk size is 5.78MB and the recompiled one is 5.77MB (and I didn't touch anything literally) and when I try to install it, the phone gives me back the same error "Parse error there has been a problem for analysing the packet".
So I can't figure out what the problem is. I thought the problem was related to code obfuscation but I' m note sure. Is there a solution for that?
Well If you have lost you project and you want to import it to eclipse then you can use this link: click here
And Yes ill tell you your question is valid ( and by the way there's nothing to do legal or illegal here as this forum is to clear your doubts )
The link will have two parts on importing your decompiled files and yes if you are unsuccessful in decompiling then this link will help you out click here
And yes you try these things anywhere..( and personally you MUST KEEP A BACKUP ON CLOUD STORAGE , WHERE YOU CAN ACCESS IT FROM ANYWHERE )

Android Resource not found exception

So I am not such a newbie in Programming, Java or Android developing, but I got a strange issue: I have made an application, quite advanced, and have it on market.
For now I have over 1000 installs and I have around 4 or 5 crash reports for a ResourceNotFoundException. The strangest thing is that the line it crashes on is on
setContentView(R.layout.some_custom_layout)
In code I am always referring to resourced by
someTxtView.setText(R.string.some_string)
So I am wondering if I used
mContext.getResources().getDrawable(mContext.getResources().getIdentifier("some_string", "string", "my.example.package"));
would the crash go away?
I was facing the same issue and I fixed it by creating Layout Folder called "layout-small".
Based on resolutions I have created only 2 folders "layout-large" and "layout-medium". But few phones are having lower resolution it doesn't find proper resources as per the resolution. Android OS renders xml resources as per resolution. It goes and find the resources in required folders.
95+ % Android phones having resolution which matches "layout-normal" folder. But still there are Phones having lower resolution. Hence this issue occurred.
For more Details : http://developer.android.com/guide/practices/screens_support.html
Hope this helps your problem.
If you are calling setContentView(R.layout.some_custom_layout) from the Activity's onCreate method, you should be good as long as your app compiles (and I assume it does).
AFAIK accessing your string resources via:
someTxtView.setText(R.string.some_string)
is not the way to go. You should be doing this:
getContext().getResources().getString(R.string.some_string)
Except
setContentView(R.layout.some_custom_layout);
try using
setContentView(yourpackagename.R.layout.some_custom_layout);
that helped me a lot of times.
I have one suggestion. Do you use in your layouts android secific resources, such as drawables or something, for example
android:backgroud="#android:drawable/some_android_drawable"
Maybe some vendors don't provide some resources with their firmware, so your app crashs.
for example this issue
someTxtView.setText(R.string.some_string)
There you set integer value to text. Its not correctly becouse it search a resousre on this value. You must write
someTextView.setText(getResources().getText(R.string.blabla));

Getting error message "Resource is not public"

So I'm trying to use the built-in drawable timepicker_up_btn for api level 7. It is in the actual res folder in the sdk, and I can use other resources from that folder. But I get the error message "Resource is not public".
It seems like Google is trying to limit the use of this resource. I would think they don't care if I use it in an Android application and it makes the overall look of my application similar to stock Android.
Anyway, is this fixable? Can I somehow use a non-public resource without copying it to my project? And what is the deal with copying stock resources to own projects? Illegal? Frowned upon? Or go ahead we don't care?
The best thing to do is to copy the files to our application. I was told by some Google employees that you should not reference the resources, rather copy them to your application.
One of the reasons for this is that if you reference a whole bunch of icons for your application, you are not guaranteed that every one of these is updated at the same time when new versions of the SDK is released. You might end up with some up-to-date fancy icons and some old ones :)
Is there any way to use not public android resources in my application?
You can reference them like this
android:drawable="#*android:drawable/pressed_application_background_static"
but it is not recommended, because private resources are likely to be renamed or removed in the future.
Technically you can copy the resource from SDK folder to your own resource folder and then use it as your own. Though I am not sure whether it's a violation of the copyright.

Categories

Resources