The tile-based architectures of most mobile GPUs have a different set of optimal use cases compared to more traditional GPUs. Check the advice in Performance Tuning for Tile-Based Architectures from the OpenGL Insights book to make sure you're not doing anything that triggers poor performance.
I don't think it's a case of making it less easy for them to do as less desirable. If you allow the player to save whenever and wherever they like they'll always be tempted to save just before a difficult bit and reload if they fail. Instead you could have a limited number of save locations that are sufficiently far apart that going back to a saved game would lose a significant amount of progress. This would at least discourage them from going back to a saved game even if it didn't prevent it.
Many many years ago I was asked to alter a program written in BASIC by someone who had been learning to program as they went along. It was obvious that they only discovered subroutines part way through when I found the equivalent of the following in several places throughout the code:
10 REM early bit of code
20 GOSUB 40
30 GOTO 60
40 REM stuff they later decided they wanted to use in several places
60 REM some more program
70 GOSUB 40
80 REM rest of program
As others have said, forget 3D games for the moment. There are a number of projects that are designed to help teach Java programming by getting you to customise a game. Robocode is one example - you write code to control a robot tank that battles against others. This will not only help you learn programming in Java but also introduce you to some of the concepts of game programming. It doesn't cover that much of Java though so you'll still need to look at other tutorials.
I think the problem you might have with using SVG directly is rendering speed for use in games. Many mobile GPUs support OpenVG in hardware and Nvidia have an OpenGL extension that can render it which will both help but I don't know how quick they are. For other GPUs there are some libraries that attempt to render SVG or OpenVG using OpenGL (See Sugar and ShivaVG).
The big problem you might face is different rendering speeds for more complex objects. With rasters, everything is just a rectangle so rendering speed is based on size. With vector shapes, more detail, particularly if your shapes have many complex curved paths, clip paths, etc. will take longer to render. You might want artists to avoid using particularly slow to render features.
it also helps to use a language that forces you to stay in OOP land such as Java and C#.
I found this. When I first started learning OOP I was trying to do it in C++ having been a very competent C programmer for years. I could never stop automatically thinking of solutions in C. I switched to Smalltalk and all soon became clear. You're probably better off with something like Java today - it wasn't around when I first tried OOP.
There are other boards that are suitable but both the above have large communities and many resources aimed at those learning.
Embedded implies connecting to hardware, which is the fun bit, so you'll need to know the basics of digital electronics. There are lots of tutorials for both the above boards that explain how to use them to interact with particular sensors/controllers/etc. and will explain the relevant bits of electronics.
That won't solve the problem if the library is dynamically linked, though, as soon as you'll roll out a version of the library which actually uses those reserved bits the crappy application will still be using the bits incorrectly and you're back to square one.
Surely the crappy application would never have worked when they tried to use the reserved bits with an earlier version of the dynamic library so they'd have changed it to use another method for their flags.
Many APIs have flags words to contain a various options. Frequently not all the bits are used. Despite the fact that the documentation mentioned that all unused bits in flag words were reserved and should be set to zero, a GUI project that sat on top of OS/2's Presentation Manager (think Windows GUI - they are almost identical) used the reserved bits for it's own purposes. A few years later IBM changed OS/2 to use some of those bits. Not only did the framework need changing to not use those bits, 600 screens needed updating as well (think changing 600 Windows .RC files).
If you are documenting an API that has flag words, define every single unused bit in every flag word as "must be zero". If you define a standard for unused bits once at the begining of your documentation some idiot will not notice/ignore it.
The golden rule for programmers producing their own encryption algorithms is "DON'T". Anything you produce is likely to provide very poor security. Just pick one of the established algorithms designed by cryptography experts that's easy to implement (like XTEA).
Unless of course you're interested in cryptography. In which case you're better off studying the existing algorithms and what makes them effective rather than trying to come up with something new from scratch.
It's worth noting that not all ARM processors have FP hardware. e.g. Android's native development kit only supports hardware FP on ARMv7 and above processors. Many low end Android phones use earlier architectures and the NDK will emulate FP on those systems.
From the CPU-ARCH-ABIS.html file in the NDK:
This is the name of an ABI for ARM-based CPUs that support *at* *least*
the ARMv5TE instruction set. Please refer to following documentation for
- ARM Architecture Reference manual (a.k.a ARMARM)
This ABI does *not* support hardware-assisted floating point computations.
Instead, all FP operations are performed through software helper functions
that come from the compiler's libgcc.a static library.