Develop Reference

I think my Android Game Size will be too big? (Using LibGDX & Android Studio)

I'm a 17 year old trying to start developing some android games. I've used LibGDX once before and found it a pretty effective tool, so I'm using it again now.
The game I'm making is a choice based, interactive game where you make a choice and then the next scenario happens based on your choice, and it goes on and on until your character dies or you win. I'm expected to have around 200 scenarios by the time I'm done, and currently have around 160.
The problem I'm having is that each of these scenarios is basically a "card," with a picture, scenario description and 2 options below it. Each of these images is pretty big, and if I scale the card images down they start looking pixelated on the phone screen. I'm worried that in just images, my game will reach 100mb, and then with sound effects and everything else it might be like 200mb. This seems pretty inefficient and I don't want potential players to shy away from the game just because of it's size, if they don't have enough room on their phone...
Am I doing something wrong? I apologize for this inexperienced question, I'm really new to Android development.

That isn't too big for modern games but you will need to not include the assets in the apk and either download that when needed or use what Google already thought of for this problem.
https://developer.android.com/google/play/expansion-files.html

These are some steps that can help you reduce your apk size:
Use only specific drawable
Add only specific image size for each drawable directory for drawable-mdpi, drawable-xhdpi, drawable-xxhdpi, etc. You can try removing a drawable directory that could potentially unused by the user, like drawable-mdpi and drawable-xhdpi, and use only the hi-res one like drawable-xxhdpi. Or, you can try using only drawable directory for all the images, so your app will only use one image for all devices type.
Resize your images
Compress your images
If your images are PNG files, You can compress the images without a noticeable change using pngquant. In fact, it can reduce your images sizes significantly (often as much as 70%) and preserves full alpha transparency. Or you can try using pngcrush (I'm rarely using this)

Using pictures in the project

I have a question. The project on the main screen I use 7 images in .png format size for 50 - 60 kb. At the same time when the application runs on the phone Monitor shows that the device uses 20 mb memory. How to upload pictures to use as little memory? Thanks for the answer.
I used the standard installation in the layout, the installation program
main_image.setImageDrawable(getResources(getDrawable(R.drawable.main).);
and glide
library(Glide.with(getApplicationContext()).load(R.drawable.main).placeholder(R.color.white).diskCacheStrategy(DiskCacheStrategy.NONE).skipMemoryCache(true).into(main_image);),
it is not bad but quite long loads images.

This question is similar to the post Images taking too much memory. The reason why for a small sized image you are getting large memory consumption is most likely due to usage of high pixelled images that use up more of your space when stored in Bitmaps. Infact I realised the answer for the high memory usage for small images just today when Dimezis pointed out my folly in just considering size and not looking into resolution of the image (link).
Now for the solution, I would recommend using Universal Image Loader, a image loading library that is pretty widely used. In it, there is an option to load the images in RGB_565 which can decrease your memory consumption by about half (have seen the results practically) and many more. Link to a more detailed answer.
And ofcourse I recommend you too to look into the

Is it possible to provoke an Android OS memory crisis?

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

Android best practice - download pictures

How would you approach this problem:
My app should download different packages of pictures (containing up to 300 pngs, each about 20 kb) and store the pictures on the phone, so i can display them.
I want to upload the pictures somewhere online, so I can change them every time and the user can enjoy the newest pictures. (I upload the pictures not with the app)
I read that storing them in a sqlite db isn't the best option.
At the moment I am storing the pictures in the app, but then I don't know how I can upload and replace pictures on all apps immediately without the need of updating the whole app.
I don't need code or stuff, so don't waste your precious time on that, just some general hints where and how you would store the pictures online, and how android can download the pictures easily.

Take a look at the Glide or Picasso libraries. Those are super easy to use for thread-safe downloading of images.
Personally, I just fetch/store the images on imgur.
If you want to upload a dedicated databse, you'll have to set one up. Some common ones are Amazon, Google, etc. There are tons.

Have a look at this answer. In this answer Picasso library is used to handle image download. Picasso gets rid of a lot of coding and testing to handle image download.
In a project that I am working on, we use Amazon S3 to store our pictures, it's very reliable and is one of the goto solutions right now.
From what I heard Snapchat and some other big firms use S3 to store their picture!
It's also very cheap, plus I believe they have free hosting to a certain degree.
This is their API guide for android.
We use a service called File Picker to handle upload and download from amazonS3, it reduces a lot of work, but I don't think it's a free service.

You can use Picasso for downloading images from network in Android. For storing images Amazon S3 or Google cloud storage can be your options.

Not sure if downloading packages is better than downloading individual pictures (archiving won't save you much space).
As for your question, you can make some kind of API you will query from your app, even a flat file hosted somewhere with changing content would work. Your app could check it periodically for the new address to download pictures from (assuming it will change).
another way is using push messages - sending out a push through GCM that your apps will receive that will notify them about new content available. It would even work when the app is closed.

Android animating a button using PNGs and OOM

So I've tried going about animating a button through the example given in this example: Android Developers
and have made a huge (95 pictures) anim-list with Pngs. When trying to run the app and pressing the button, I promptly receive an error about memory not being sufficient. The file sizes are about 170k (12mb in total) . Is this too much for an animation? I realize the serious lack of regard for eventual users' storage space with this approach, but it's mostly for my own use anyway and won't matter.
The images are pretty big and need to be downscaled by the graphics engine however, and this might have to do with it?
Or is 95 pictures too much ? I can make the pictures smaller, right now they're at a whopping 4K resolution, which in hindsight is pretty dumb.
However, I can compress the pictures and make them smaller from the beginning anyway so that's not a problem. I just need to know how to fix this issue, if there's a treshold for how much can be loaded into RAM at a specific time so i can match the image sizes or if there's a way to override the default RAM settings or overcome this?

Don't look at the file size. Image has to be uncompressed so Android can use it. The image size is more or less equal to width*height*4. 4K image takes ~35MB of memory.
Modern devices can allocate 64MB of memory per app. It means that you can load only one such image. Maybe more if your phone has higher heap limit.
AnimationDrawable is for small animations (like 100x100px). If you wish to play such a large animation, you should encode it to mp4. If you can make the images smaller or make the animation procedural - go for it.
To override the memory limit use 'largeHeap' flag or change the setting in the ROM configuration (you have to flash your device with a custom ROM).