Development for Android, a big rake and not very

Below I will try to describe a number of unpleasant features that a developer for the Android platform may encounter. Not all of them are a feature of the Android operating system, but somehow there are chances to meet with them.

Large rake

How it happens: You upload your 10 megabyte application in the Android Market, and you get an angry email from the user - “How can you make such terrible programs, she doesn’t even want to install on my phone, she is deceiving me. I had 15 megabytes free on the phone, I tried to install your application in the description of which it is written that it occupies 10 megabytes - she told me that there is not enough space, I deleted unnecessary programs and I have 25 megabytes freely - it still doesn’t say enough space I deleted the programs I needed and it became 35 megabytes of free space - it still does not want to be installed. WTF! Why do you write the wrong size of your program! ”(My free translation from English is a real letter).
Cause: To install an application of X megabytes in size, you need from 2X to 4X free space.
Why: First, the application file is downloaded to the device and it takes up X megabytes of space, then it will be unpacked for verification — from X to 2X megabytes on average, then it will be moved to X applications in the file system for another X megabytes.
What to do: If you are making an application larger than 5 megabytes in size, then be prepared to write functionality for downloading and placing some resources on a flash drive, as well as checking for the possible absence of a flash drive or deleting parts of your files, and during the operation of the application.

Flash Rake

How it happens: You make an application intensively working with files. Measure the time of work and get quite acceptable numbers - the overhead of file operation of about 5 milliseconds. The application is fast, you are satisfied. After installing a number of applications, you notice that the running time of your program has increased 5 times.
Reason: Features of the file system implementation - the less free space on the flash drive, the more time it takes to file operations. The access time rises from 5 ms to 300 ms, in theory the access time can grow up to 200 times.
Why: The file system tries to save the life of your flash drive, therefore it keeps track of intensive file operations and often tries to move files from place to place. The more files and the less free space, the more time it needs for it.
What to do: Instead of many small files, one large file with indexes. And let's hope that no one will use your application for months and will not kill your flash drive.
')

Limited rake

How it happens: You receive a prototype of a new tablet on Android with a screen size of 1280 by 800 with a whole gigabyte of memory on board. You start to port your quest in joyful anticipation - load the first full-screen backdrop, the second, sixth - and get OOME (OutOfMemoryError).

Reason: 16MB of memory per process (24MB on N1 / Desire), this includes the “native heap” where Bitmap (and OpenGL textures) are stored
Why: In the best traditions of the dictatorship of democracy - it is better to let all applications be available for a few memory, than to allow one application to use all the memory, which can cause problems for other applications. Well, many other nuances.

What to do: 640kb 24 MB of memory is enough for everyone

Sensitive rake

How it happens: You created your application, added cool music there, added accelerometer control to it. Users complain that the management is terrible.
Cause: When playing a music track at maximum volume, especially where there is a lot of bass, while the phone is stationary, the rotation values ​​taken from the sensors change from -10 to +10 degrees.
Why: The speaker is too close to the sensors.
What to do: Do not let the music be set to maximum volume, do not use heavy metal tracks, take into account the sensor tremor

MultiTouch Rake

How it happens: You want to make a control, for example in the game iDracula

And you can not.
Reason: You get touch coordinates in pairs - two X coordinates, two Y coordinates. You cannot find out to which touch this or that coordinate belongs. As a result, if you run your fingers towards each other along some axis, and then after the coordinates coincide along this axis, you can no longer determine to which click to apply which coordinate. I understand that the description is rather vague - so you can watch this video here -
Or download the MultiTouch Visualizer application on your phone.
Why: Features of the implementation of the sensor on some phone models - Nexus One, Desire.
What to do: Abandon such management, or distribute it along the Y coordinate.

Magic rake

How it happens: You write the following code.

while(true) {
Task task = queue.getTaskBlocking();
task.execute();
}


Where Task is a fairly “fat object” that allocates a lot of memory. And you find that the memory is used more than planned. Looking at the resulting byte code, you find that it doesn’t compile at all in the code you want, and it’s in the code

Task task;
while(true) {
task = queue.getTaskBlocking();
task.execute();
}


As a result, you have two Task instances in memory. Do not worry, you think, we are now clearly indicate that one copy can be removed from memory.

while(true) {
Task task = queue.getTaskBlocking();
task.execute();
task = null;
}


But looking at the resulting byte code, you see that the optimizer decided that since the variable out of scope, threw out your explicit object vanishing, and you still have two instances in memory. And then magic is born.

class Magic {
static private int n = 0;
static public void doMagic(Object obj) {
if (obj != null) n++;
}
static public int getMagic() { return n; }
}
while(true) {
Task task = queue.getTaskBlocking();
task.execute();
task = null;
Magic.doMagic(task);
}


Reason: Bug :)
Why: // TODO: Find a developer responsible for this, try and find out why.
What to do: Magic