Background
I wanted to simplify the usage of DB in an Android app.
For this, I've compared some third party libraries that create a DAO layer.
I've come up with a nice library called "GreenDao" (presentation about it here) . The website shows that it's faster than other competitors (like ORMLite) and is optimized for Android.
The problem
For some reason, on some device (usually old devices, with GB) , I get the next console error when trying to install the app:
Installation error: INSTALL_FAILED_DEXOPT
Please check logcat output for more details.
Launch canceled!
I've searched for the reason of this error, but couldn't find out how to solve it. Many complain about this error, but I can't find out why it occurs, and what can be done.
The error is quite common and known, but it's never mentioned as the result of using this library, yet when I remove the usage of this library, everything works fine...
Also note that on newer devices (like nexus 4) it installs and works just fine, and that the sample itself also works fine no matter which device I test it on.
The question
Why does it occur?
Is it possible that the structure of the classes is just too much for old devices to load, since we use other libraries ?
Could it be that I've reached the limit of code that is supported by android apps?
The jar file itself takes just 87KB ...
How can I solve this?
Ok, I've found the problem and the solution:
It has nothing to do with GreenDao.
It's because the app uses too many jars, so maybe Android has a limitation of code.
The solution is to either delete un-needed jar files or delete a lot of code.
Related
Here is the error I'm getting when trying to archive my app for deployment.
This error doesn't show up at any other time. The project builds and runs on emulators and devices without issue. This error has zero context or direction as to where to look to fix it. It also just randomly showed up out of nowhere, last time I built/archived (with zero functional changes) this error did not happen.
Main difference between this archival and the previous one is a newer version of VS 2017. Don't remember exactly the version from before, but am currently on 15.9.4 (stable).
Looking around on the interwebs, I've found that this error seems to have something to do with ObservableCollection's, which there are probably 10-ish in my app. Not really sure what to do here, because this has never been an issue previously, and I'm coming up on a deadline and with the structure of the app, am not in a good position to start making functional changes.
EDIT
I have also cleaned and rebuilt my solution, as well as deleting all bin/obj folders in my xamarin projects. Even tried deleting the .vs folder which can sometimes help. But still no go.
Going to try updating VS to 15.9.5 and see if maybe it was fixed in a release.
EDIT 2
Updating VS 2017 to 15.9.5 made no difference.
EDIT 3
I had my coworker try archiving the exact same project on his machine (running VS 2017: 5.9.3, and it archived fine for him. So far that's the only difference we've been able to find between our environments.
I saw the same problem using VS2017 15.9.9. Even the same code that could be archived a week ago threw the above mentioned error. It seems related to local data in the solution. A "clear" build was not sufficient. However manual deletion of the local obj and bin folders followed by archiving (build is done implicitly) solved the problem for me.
For my part closing Visual studio and deleting the .vs hidden folder did it.
It's actually a fix for many issues using Xamarin.
I had this other issue where I couldn't archive because the build process would just hang and never end. Deleting the .vs folder did it too.
https://github.com/xamarin/xamarin-android/issues/1760
Just go to project property then go to Android options-> Select Advanced then increase the Java Max heap size to 2G/3G -> it's working for me.
Leon Lu's suggestion worked. I don't particularly like it, as it took forever and repairing basically restores you to a base install (no extensions or personalizations). Took about 1.2 hours to complete, but once done I was able to again archive my android application. I guess something went wrong in vs at some point, perhaps during an update. There's no way to tell.
I tried ALL of the ideas above, but had no consistent reliable luck with any of them.
I found that Microsoft has had the problem reported to them (see link below). After a ton of time burn on this, I posted at the link below one way that I've been able to get around this archive-build issue.
Like the other fixes, it's not exactly logical, and nothing that you would think would work, but I've found the process to be repeatable, which is golden for me with tight timelines and having no time for this.
MS Visual Studio Developer Community Problem 507708
Posted on a Saturday morning, a sign of really needing to get around this urgently. I hope it helps you too.
I'm having a problem where an app I'm developing is working on mobile devices (tested on 4 different devices), but crashing when I try to test it on my tablet. The tablet I'm using is a Tesco Hudl 2, which, although being a good quality low cost device, lacks adb drivers and so you can't debug apps through USB and get the Logcat data. The app was developed using Android Studio.
With other apps I have developed, I have just set up ACRA in the project so I can still get debug information from a crash. This time however, the app is crashing without any information from ACRA and so I'm not quite sure what is going wrong. I'm pretty sure I've set up ACRA correctly given that I've used it in several projects before and see nothing wrong this time. Can it be that whatever is going wrong is happening too early for ACRA to catch?
I have pulled out all the code from the activity so the only thing that happens in code is that ACRA gets initialized in the derived Application class (note that the crash exists without ACRA). The app also uses Google maps and a provider for search suggestions. If there is any code anyone wants to see just ask, but I'm unsure what exactly to post up since everything else was stripped out. So, does anyone have any idea on what I can do to solve this, or what tools I can use to catch whatever sort of errors happen so early in the apps lifecycle?
Thanks
Update with strange behaviour... Downloaded Crashlytics and it also did not catch the crash. I copied the project and removed every .java file except the Application, Activity and provider. The provider functions were empty (save for the return value of 0/false/null/whatever), the application class just initialized Crashlyitcs and the Activity class was empty. This then worked, I was even able to add in a lot of the code and get the google map to load.
Now if I do the same in my main project, except don't delete the .java files, the crash still happens. The classes in these files are not used so I have no idea how they can be causing the crash. Otherwise all the xml, gradle, resources are identical (except the package and app name). Very confusing...
Consider using one of the apps to view logcat on the device:
https://play.google.com/store/apps/details?id=com.nolanlawson.logcat
https://play.google.com/store/apps/details?id=org.jtb.alogcat
Also try using Crashlytics. Maybe it will catch your crash?
But yeah, it's possible to have a crash before any crash reporter (ACRA or Crashlytics) will have a chance to catch it.
And one more note, maybe there is a way to enabled ADB over WiFi.
Normally you would need to enable it via adb but maybe in case of this cheap and strange tablet, there is an option for that enabled in the ROM?
Ok! So it's 1am and I decided to have one final attempt to fix, which I think I did. In my manifest, I had things like
<activity
android:name=".MyActivity"
...
for example, and while this worked fine on the mobiles, for some reason the Hudl required the complete package name, i.e. com.mypackage.MyActivity. Not sure why this is the case but it appears to have fixed the problem.
I've been recently trying to make some very simple app in Qt, and yesterday it used to work correctly on both Desktop and Android (using android ndk, I know it's not good to make android apps in c++, but I just want to try).
Today, out of nowhere, application output says sth like this:
The only thing I've found was cleaning app's cache and data, restarting phone, rebuilding, none of these things worked
A Qt app has an array of used .so library names, somewhere in the resources.
On start-up, it loads all these .so libraries (via loadLibrary()).
The order in which the libraries are loaded is important: functions cannot
reference functions defined in libraries that have not yet been loaded. So implementing a circular dependency is tricky.
From the logs I see that
some function in libszachy_android_1.so (is it the right name? it's a bit strange) invokes srand() that has not yet been loaded; maybe, it is mentioned later in the load list, but loadLibrary() has no idea about the planned future.
Therefore, you get this.
If your code worked yesterday, you likely have made some changes. If you use version control, you likely can compare the today's and yesterday's versions and see the difference. Maybe, you have inserted a forward reference (in the load list sense). OTOH, sometimes both Eclipse and make cannot detect that the source has changed and make incorrect builds (I did observe this, but cannot reproduce). Did you try to uninstall the app from the phone? Did you try to remove all existing .so files in the build directories (rm *.so)?
Maybe, one of your .so modules is broken: sometimes an object is generated despite of errors and it may get used in subsequent builds (at least this is how I can explain the build glitches).
Maybe, you have no memory left on the device, and the .so could not be unpacked correctly.
I suggest examining the application directory with adb shell on a rooted device.
PS you posted a screenshot that is barely readable. Please replace it with the relevant portion of the adb logcat output (I hope you know how to use it; if not, the first thing to do is to learn adb logcat and adb shell).
I'm tired to see a lot of Stackoverflow questions about this, even in Google forums or Google official support site, publishing "solutions" that lead to uninstall package through ADB, to do something with the phone rooted, to delete cache of Google Play Services, etc ...
https://code.google.com/p/android/issues/detail?id=64514
https://support.google.com/googleplay/answer/3300875?hl=en
http://gizmostorm.com/how-to-fix-package-file-is-invalid-error-on-google-play-store/
https://www.google.com/search?sourceid=chrome-psyapi2&ion=1&espv=2&ie=UTF-8&q=android%20upgrade%20download%20invalid%20package ...
etc ...
Is there any solution from the package side ?
I mean, I have an app with hundreds of thousands of installs, and unfortunately many users are complaining about this error when upgrading from store my new version.
Obviously, I can not go one by one telling they have to do this or that, because they are not developers, they just want to upgrade and run an app !
Some users are telling me (complaining) this happened since the last "upgrade attempt" of my app, and they are not experiencing this "package file is invalid" with any other app in their phones.
So, I guess it's something I can fix with another upgrade.
Is there ANY SOLUTION that I can do in the next APK compilation, uploading to Google Play Store and fix this without "bothering" my users ?
Thank you in advance
I have also faced same issue in my project as well. I was adding many more features with new jar, git open source library code for Nice UI.
For searching for solution I found play store has issue in one of its updates
http://www.androidcentral.com/google-investigating-package-file-invalid-errors-google-play
But this is totally not relevant to my problem
Again searching I found this
http://birbit.com/how-to-solve-linearalloc-problem/
So the solution looks to be loading a few jar files dynamically using DexClassLoader.
http://android-developers.blogspot.in/2011/07/custom-class-loading-in-dalvik.html
Prepare Interface of the jar file (list of all classes and methods) and have the interface in the app - Need to see how to do this. - We can just have those classes which we need in our app and ignore the rest of the classes. This way we can implement for few existing jars and any new jars that we have to add to make sure we don’t run into this issue again.
Keep the jar in assets folder
Load every class from the jar (based on the list of jars we have in the interface). (The classes will be loaded just once on first launch)
But Based on this, this looks to be involving lot of coding changes and a time consuming things.
Moreover I found that facebook also faced same issue in their initial android app
https://www.facebook.com/notes/facebook-engineering/under-the-hood-dalvik-patch-for-facebook-for-android/10151345597798920
Final Approach I took was removing additional code from jar/git library project which is not require for my application. after that my app got install on 2.3.X with no error.
Background
It seems some old Android OSs (and maybe even the newest ones) have a limitation on the amount of code each app can hold.
As I've found, the limitation is on a buffer called "LinearAlloc" .
On 2.2 or 2.3 it's about 5-8 MB , and I think it's 16 or more on others.
The problem
If you have a too large code (and apps can reach this state), you won't be able to install the app at all on older devices, getting the next error (also reported here) :
Installation error: INSTALL_FAILED_DEXOPT
Please check logcat output for more details.
Launch canceled!
What I've found
One solution is to just remove as much code and libraries as possible, but on some huge projects such a thing is very hard to do.
I've found the next links talking about how Facebook solved this, by somehow increasing the limit:
http://www.slashgear.com/how-facebook-fixed-its-gingerbread-dalvik-problem-04272478/
http://arstechnica.com/business/2013/03/how-facebook-dug-deep-within-android-to-fix-its-mobile-app/
https://www.facebook.com/notes/facebook-engineering/under-the-hood-dalvik-patch-for-facebook-for-android/10151345597798920
Also, Google has posted how to solve it by loading code dynamically :
http://android-developers.blogspot.co.il/2011/07/custom-class-loading-in-dalvik.html
The question
How did Facebook do it?
Is it possible to overcome this in other ways too?
Is there any free library that increases/removes the limitation of this buffer?
What is the limitation on newer Android versions, if there is any?
How do other huge apps (and games) handle this issue? Do they put their code into C/C++?
Would loading the dex files dynamically solve this?
The limit is the total number of method references:
https://code.google.com/p/android/issues/detail?id=7147#c6
https://code.google.com/p/android/issues/detail?id=20814#c6
A middle ground between doing nothing and the multi-dex approach described in the FB/Google articles is to use a tool like ProGuard to remove references to unused code at the Java level. See:
http://proguard.sourceforge.net/
http://developer.android.com/tools/help/proguard.html
There is a new solution, made by Google:
https://plus.google.com/+IanLake/posts/JW9x4pcB1rj?utm_source=Android%20Weekly&utm_campaign=59f1f4bf4d-Android_Weekly_125&utm_medium=email&utm_term=0_4eb677ad19-59f1f4bf4d-337848877
http://developer.android.com/reference/android/support/multidex/MultiDexApplication.html
It seems all you have to do is any of the next things:
- extend from "MultiDexApplication" instead of from "Application"
- call MultiDex.install(context) in your application's attachBaseContext
But now I wonder:
Is that really it?
Does it have any issues ? Does it affect performance?
How does it work?
What should be done with ContentProvider, as it's getting called before Application gets initialized?
The post says "gives you MultiDex support on all API 4+ devices (well, until v21, where you get this natively)" . Does it mean that from v21 it will be the default behavior, or just that the class will be built in and you won't need to use the support library's class ?
Will this solution work on Eclipse too?