I spent all day trying to figure out what is wrong with my apk. Tried ALL solutions from web, aapt revealed nothing, tried different signatures, packages, versions, browsers, OS. Manifest underwent all possible changes, yet I was getting same problem.
So I though OK, lets start from scratch, maybe google servers are down for some reason (wouldn't be the first time).
created new android application project, new package, just one activity
built, signed, uploaded, voila, OK, fine, removed apk from console
did this few times, it succeeded every time
the size of apk was few hundreds KB
as my original apk was around 25MB, I thought, hey, lets try increasing size of this testing one
so copied ~25MB worth of photos to drawable-hdpi
built, signed, uploaded and familiar message popped out again - 'Server could not process your apk'
tried several times, still same outcome
deleted photos, built, signed, uploaded, ok
added photos, no luck
So obviously problem is not in manifest or anything else, for some reason size matters (in this case anyway :)).
And yeah, when I deleted just 50% of photos, so apk was ~ 13MB, it sometimes worked, sometimes didn't.
Any explanation for this? Can you replicate? Have tried different browsers, operating systems, same everywhere ... I know there is a limit for apk size, but that's 50MB
Go figure ...
UPDATE: if you ever encounter same problem and you're sure your apk is fine, keep trying to upload. It worked after couple of consequent failed uploads, suddenly server COULD process, without ANY change to apk.
I don't know what's going on with your app and Google Play. Our largest APK file is just under 11MB and we've never had a problem.
Perhaps you can side-step the problem by packaging up the resources in an APK expansion file, as described here. The size limit for APK expansion files is 2GB, so there shouldn't be any size issues at all. According to this thread it can be set up to work pretty smoothly (transparently for the user).
Related
I'm having a problem with my users (Android). They delete the app, and their data is gone. They expect it not to be.
Browsing my phone, I see a lot of apps put a folder right off of /internal shared storage. I.E. I click on internal shared storage and there's a bunch of folders for various apps with data in them that doesn't go away if I uninstall the app.
This is what my customers want. This is what will stop them from writing me and accusing me of destroying their data.
How do I get a path to that folder, and what permission do I need to write there?
First off, deleting when the app is gone is how Android works. Anything else is a bug that you should expect to see fixed.
Secondly, you can't put anything right in / anymore. There was a time you could, but that's long since gone.
Third, have you looked into Android Data Backup? https://developer.android.com/guide/topics/data/backup This will work even on a new device, so its a better path forward anyway
I've got an app created with Android Studio.
I'm using an SQLite database which gets downloaded and saved in phone's storage.
The problem is that in certain types of phones (Lenovo / Xiaomi to be exact) the sqlite file gets deleted after some time and the users have to re-download it.
The problem is appearing only on these 2 types of phones and also not all of them.
I can't replicate that on any of the phones I tried nor emulated ones within Android Studio.
There is no code that would delete the SQLite file and also I couldn't find anything in here or google about Lenovo/Xiaomi having similar problems like mine.
Any Ideas, would be appreciated.
I don't know about Lenovo, but Xiaomi phones have a "Clean up" feature that regularly (at least once a week, in my experience) asks the user to, well, let it clean up files. I don't know what it uses to decide if a file is obsolete or not, but it is a very aggressive cleaner (it wants to clean up cache files for apps that have just been used and are in constant use, for example). This is likely what is removing your downloaded files. You can check the location you're downloading them to, and see if changing that helps; or you could see if you can find any documentation on the file cleaner so you can find out how to stop it from flagging your DB as "rubbish".
I'm finishing my android first app and I'm wondering why does it take so much space. It just has few activities with WebView and TextView so it should take around 1MB (like the .apk does) but definitely not 12... I've looked around but haven't seen any good reason, compressing images doesn't help much either, please help.
I'm not sure this question is within the scope of Stack Overflow. I think your answer is over at Android Enthusiasts though!
https://android.stackexchange.com/a/107204
To paraphrase, the APK is compressed version of your app. So it may be 1MB, but once decompressed on the phone, it may take 12 MB of space. If you are worrying about your app's size because you want the download to be as small as possible, then it shouldn't be a problem. It downloads from the Play Store as 1 MB.
In Android Studio, go to File-Project Structure and verify the default Dependencies already included in your project. It seems you're not using support-appcompat-v7, for example. If you make your apk without this dependency you will get your apk compressed by hundreds of kbytes.
I am told that the Android OS (>=SDK14) is able in a real lean memory situation to start extinguishing tasks without sending onDistroy()-messages. It is very interesting (app quality issue) to stress test apps in such environments.
So this is a question about extreme cases, all memory is gone and the OS starts to extinguish stopped tasks to get more memory. Is it possible to provoke such a situation, to be able to test it? Shall I write a JNI program (making hello-jni looping a calloc or something)? This to chew up all the memory to provoke this situation of poverty?
How do I best memory choke my app/the Android OS environment? Any ideas? Any tried such stress tests?
Are there any total OS memory monitors available?
Can anyone explain if the Java and JNI parts of memory are from each other isolated heaps (chunks of memory) or allocated from the same common memory by the OS? Is it possible to choke the Java apps with JNI memory allocation?
So 7 years later, updated question:
Wh I know today it is not possible to provoke a JNI-memory shut down, just appears with no warning? It is not possible to test the topic in code?
This topic is a general design issue on how to design an editor the best way.
Still there are two main questions:
There is not yet a message to the Java app that the OS intends to shut down the JNI memory part, as far as I understand.
So the app can do the shut down itself instead and be aware the JNI part is shut down. It would be just as good if the app is notified that the entire app should be closed and all the mines will disappear, but that is not done either. The app may live but the JNI memory is gone and the app has no idea it happened.
Where the main problem is not knowing, not being able to test as it just crashes when the JNI memory is gone och det anropas.
Must be very tricky technically because there is such a given solution that is missing?
Given that users who are in the middle of app work jump between apps, the app can't close down the JNI part for each jump. The best solution is still to let the app crash if the JNI part is gone and let the user restart again by pressing a second time on the app icon? It's not a pretty situation?
Also, you can't assume that JNI is gone after a few days and just restart from scratch. Because then you fill the memory with unused JNI memory allocations if this is not the case. You can't test because then it crashes.
My app is a bookkeeping accounting browser and does not edit the files, but in 2023 I intend to come up with a complete accounting program based on the browser's functions with extensions. The situation is like an Office program, but works with inbdustry standard bookkeeping accounting documents/files. It requires that this question be thought through properly once more.
All views and suggestions are welcome
Data recovery and the new regulations/restrictions for saving files in the public folders
It means that you cannot use fopen() in JNI, but must use java byte streaming of the Picker. Where you can of course save the resolver and uri and reuse it for saving. See also NDK fopen() in the common storage of Android API 31
I have solved this situation for "open the last opened file on startup" by saving a copy of the last opened file in the app's local storage as well as the name of the last opened file.
To save, you must start the Picker at least once, but if the file is opened with the picker, you can reuse the resolver and uri for the file update. While it is the last opened file, you have to start the picker for an OK.
For the browser, this is a minimal problem. But for an accounting editor, it is a central question how to update documents that are worked on for a long time, and the user very likely jumps to other apps, during the work? If the JNI part disappears, it can be devastating.
I think it can save in a temp file during the work and then have a save button for the user. A temp file that can be restored after a JNI is gone crash and the app is restarted from scratch. One can probably find a way to save where the user was last and arrange a rollback?
It's so strange that there is so much trouble just because a "We intend to discard JNI stored memory for the app" message is missing, because then you have full control. Hope it still comes.
Also here all views and suggestions are welcome
We have application on android market, our users getting a lot from this error:
java.io.IOException: No space left on device
From what I found out so far, I know that they got enough space left on they external storage, and it's only happen on Android 2.x .
I had a small research in Linux file system, and I found out that beyond the space limitation there are limitation on number of files in each directory and the total number of files under root directory. But it looks like our app is not hitting any of those.
Have you ever run in two some thing like that?
Any ideas about what changed in Android (2.x) and how they fix it in Android (3+)?
Edit: this is not installation problem, but when trying to save downloaded files.
adding a loging-output of the absolute filepath, that caused the exception might help.
if the file beeing written was written to local memory file-system and not to sd-card-filesystem here is a possible solution:
java.io.IOException: No space left on device my mean that there is not enought memory left on the internal storage file system of the device.
You can try to install the app on the sd-card instead by setting an entry in the manifest-file:
<manifest ..... android:installLocation="preferExternal">
Edit
if an app is installed in internal memory it-s local files are stored in local memory, too.
if an app is installed on sd-cardit it-s local files are stored on sd-card, too.
so installing the app on sd-card might solve your problem.
I believe (if I'm not correct) that it could be having trouble opening a big file or any file that goes over the max of the eternal storage after all the space is used up. For example: My android didn't have any problems opening up until after I used all of the space on my device til the very last bit. Unless I upgrade or delete all of my fav songs and movies it won't work. Tested and tried it. But then again the error could be more flexible and mean something else as well... :D