However, I have tried turning to the 3D renderer and I have experienced glitches when on my Android phone (not on PC). 

I therefore try to avoid switching to the 3D rendering, which is AFAIK required for displaying quads and texture mapping. 

As for the rendering device, I am using Processing 2+, which I think implies that only a single rendering device for 2D is present ( see here ).

Generally I do not give any explicit specification, so I use what is default, which should be the android rendering system.

You are absolutely correct about the image - I have not realized that the image is loaded in the memory (and arguably decoded) when the PImage is created and therefore the argument about size (which was supposed to point out that the decoding should not be very complicated due to high compression) is irrelevant.

As for the performance, my main concern is really about the drawing. I will keep in mind your comment about drawing primitives, but to considerably constrain my framerate, the following is sufficient:

1. PImage img;  
2. void setup() {
3.   size(480, 320);
4.   orientation(LANDSCAPE);
5.   img = loadImage("480x320image.jpg");  
6. }
7. void draw() {
8.   background(img);
9.   println(frameRate);
10. }

I am sure OpenGL is not used since if I try to use it now (with all P2D, P3D or OPENGL constant), I get  this bug .

Here is  my screenshot relevant to the performance, but I am quite surprised by yours - I have previously released a tiny game that in the worst case would make 6 full-screen images per redraw (before I started to optimize) and the performance was so bad that it would crash immediately on Sony Xperia and Galaxy S2 (Galaxy Ace has the advantage of smaller screen in comparison with S2).

Just to sum up and maybe conclude:

I mainly needed a way to optimize my code so I do not redraw what I do not need - the get and set methods helped in this matter greatly.

Usually the software rendering device is in general several degrees slower than the video device accelerated method, so using OpenGL would provide enough of power even for the brute-force displaying, which I have confirmed as I also implemented the same code using the libGDX where even multiple images can be displayed at a time without slow-down, but I prefer processing due to it's user-friendliness and in processing I have encountered some glitches with image displaying using OpenGL even before the bug mentioned above.

So my conclusion is that I will stick to Processing software renderer and optimize the image display procedure, which is sufficient for my problem.

With my previous app, that is now somewhat more optimized (  https://play.google.com/store/apps/details?id=justaconcept.games.aprotester ) I also had some other problems, like that resize() method caused crash (filled as a bug in the repo) and that antialiasing can not be stopped, therefore there is much more computation for bigger screens where the image gets heavily up-scaled, which caused crashes on SII - at least I think so, I only know from a friend who has tried it. Now the game is somewhat enhanced and as far as I am concerned works anywhere, so there is also no need to improve it. But if you ever try it and encounter a problem, please get back to me on that :)

Lastly - the framerate without the picture is stable 60, so I am quite certain that there is no delay with using println, also because it is just an interface to an inherent Java function and during my previous pure-android development (no Processing involved) I have used it to push a lot of data without any impact.

But again, thanks for the suggestions, hope that you have also gain some knowledge from our conversation. :)