I surmise the OP wants to know why games designed for classical consoles and computers are so much smaller than modern games. Hopefully some of this is useful; I have just an interest in retro systems.
If you look at two main elements that make up an image we see code and data.
For the data portion if we examine graphics, one methodology may be to have a 16 colour image where the palette is stored separately to the image itself. In order to represent 16 unique values we require 4 bits per pixel, and then a palette (depends on number of colours the VDP can display) loaded onto the display processor which declares what each of those 16 colours represent (with one being transparent).
The Mega Drive for example has 4 palettes and all the pixels on screen are taken from these palettes. If on a modern system you chose to use a 24bit bitmap for your Mario sprite each pixel will need nearly 17 million bits. By changing the palette many games would reuse the same images and simply change the colour to give the impression of new enemies and environments. Games were typically also built from tile maps (e.g. 8x8 tiles) so the same levels were created from a selection of small images; this is more space efficient than creating larger images and only using them a handful of times. Systems like the Super Nintendo had scaling, rotation; etc built into the hardware which helped reduce code size as this didn’t need to be done in software, but was more useful for computational efficiency. The same sort of argument applies for the music and sound effects in games.
Games were usually written by hand in assembly which even now amongst homebrew is popular due to the small code size/efficiency that can be achieved compared to a compiler, though modern compilers are much better than some of the older ones. Object oriented languages are often not used for embedded processors due to the small overhead involved, which is not really an issue on smartphones and modern PCs. Many games are also created using interpreted languages with huge libraries (compared to the memory size of old consoles), often including a lot of code which is never even executed. I first started programming with older versions of Game Maker and even a game with just a single empty room would be well over 1MB in size, before I added anything to the game.
Hopefully the examples I’ve shown illustrate that in order to create a game for the 8/16 bit era you would have to know a great deal about the hardware you are running on (at least at the time) whereas modern frameworks or game engines abstract the hardware detail away from the user. You don’t need to know exactly how the hardware works or concern yourself with the vast amount of hardware variations that exist in Android devices; each layer of abstraction introduces inefficiency but can potentially help developers (this is especially important for large complex projects not possible on less powerful hardware).
I’m not sure on modern devices; they may need to be rooted. If you could write your own drivers to interface directly with the hardware instead of using a high level framework which in turn talks to the OS which then controls the hardware, you may be able to natively control the device using a very small end-to-end footprint. If you are only interested in reducing the size of your games using this framework you should probably start by examining the size of your image and music files, perhaps create a barebones room and check the size of the image produced and check the size difference to the Mario level you produced to see if it’s the framework you are using or your work that is introduced the bloat.
