[Nexus 4 Q&A, Help & Troubleshooting] MerynGoesAndroid:
Made me think you were new to Android development and coding in general. Normally people like this with these questions do not want/need a specific and technical answer which is why I told you to not worry about it.

Again, made me think you were new here.

This sounded to me as if you just wanted it to be removed.

My post was not intended to sound the way you describe it, and reading it again I wonder how you came to the conclusion I was 'teaching you a lesson'. Just because I did not overflood my post with happy smileys and kind words does not mean I'm hostile and/or trying to be arrogant.

To me, your post sounds the exact same was as how you described mine.

That aside, here are my technical thoughs.

The app stores quite a lot of data on your phone, close to 7MByte on my phone, to an app-size of 2,86MByte, so I assume it makes use of some kind of caching.

It probably uses some other techniques for different element optimizations, meaning not all improvements are via caching.

My guess is it takes the animations it knows, and "replays" them, capturing the animation and storing it in its data for quick access. When you start the app and set it up, it needs time and says "building fast event for x action", which is why I think it works this way.

From the app:

The animation is probably "scaled" down in size, which makes it less computing-heavy. This also explains why the higher the setting, the longer it takes. (more compression = more computing power needed. Since a better CPU can do more instructions per second, it will be faster at rendering its own "database" of the animations, which is logical.

Not sure what the author meant with "better the GPU performance is, the smoother the operation will be". Operation could either refer to the process Super Touch does, or the process of animating the animation when using the phone. Personally I think this refers to using the GPU for rendering animations normally (without Super Touch), which can cause frame drops as he explains. GPU's with lower performance will have a harder time rendering an animation than a GPU with high preformance. Pre-rendering takes this load off of the GPU, making it more "smooth" in real performance.

With this method its can just 'grab' an animation from its memory and 'play' it instead of calculating it on-the-fly.

Looking at the permissions the apps needs, the app uses "draw over other apps". This is probably used to "show" the animations it stored instead of the animations of the app that is being used. How it is actually able to replace this animation is something Im not sure of.

The app has permission to run at startup, this is probably needed to "load" the core service that does this replacement.

I do not exactly know why it needs permission to read phone status & identity and change audio settings, but my guess would be that it is related to the power saving mode.

Unless he does, we can probably only assume how his app works. Decompiling the app and looking at the source might give you an answer, but this is not something I can help you with, mainly because my last decompiling experience is 3 or 4 years back.