Wo genau muss man die Zeile einfügen? Egal wo oder irgendwo in eine bestimmte stelle?
Man braucht sich überhaupt keinen Kopf machen, wenn man dafür einen
Build Prop Editor einsetzt (Click)
Das dieser aber eine Auswirkung auf GPS Test haben soll, ist kurios.
@
guesa hat das noch nicht ganz verstanden, dass das für GPS Apps ziemlich egal ist und keine Auswirkungen hat.
Es gibt meines Wissens
drei Interpreter in der Dalvik VM:
fast (Plattform-abhängige Assembler Routinen)
portable (Interpreter in C geschrieben)
debug (extrem langsam, für die Entwicklung)
(JIT heißt Just In Time. - Java Byte Code wird hier zur Runtime in Maschinen-Code übersetzt, nicht bereits irgendwann vorher.)
Wenn jetzt dieser Switch benutzt wird (int:fast), dann wird JIT ausgeschaltet und es werden die "nativen" Assembler-Routinen der MTK-Plattform eingesetzt.
Ich rate einfach mal, warum das jetzt Einfluss auf die Strecken und Geschwindigkeiten in Navigations- und Tracking-Apps hat:
(Der C Interpreter führt evtl. ein falsches Type-Casting durch.)
Bei der Optimierung (mit JIT, portable C?) wird bei den betroffenen (MTK-)ROMs eine falsche Variablen-Typisierung benutzt, bei int:fast (native Assembler der Plattform) ein korrekte Variablen-Typisierung.
=> korrekte Ergebnisse bei numerischen Berechnungen.
@Edith:
Für die, die es ganz genau wissen wollen (hab's wieder gefunden).
Es ist kein Type-Casting-Problem, sondern ein Fehler in der Optmierungsroutine des Interpreters.
Double precision value computation errors on MediaTek processors
https://code.google.com/p/android/issues/detail?id=65750&can=1&q=jit&colspec=ID Type Status Owner Summary Stars
JIT bug related to immediate doubles
https://android-review.googlesource.com/#/c/57602/
Fix JIT bug related to immediate doubles Change 256211 (JIT: Performance Fix for const doubles) introduced a defect that can cause the JIT to use the wrong floating point double constant in traces in which the following conditions hold:
o Two (or more) different 64-bit floating point constants are used.
o The physical register holding the first constant is still live at the time the second constant is used.
o The low 32 bits of the two constants are identical. In this situation, the load/copy optimization pass will incorrectly determine that the two constants are the same, delete the load of the second constant and re-use the first constant value. Note: this problem only occurs with 64-bit floating point literals. 64-bit long literals are unaffected.
http://stackoverflow.com/questions/21430096/double-precision-value-computation-errors-on-mediatek-processors
muss sparen... die Nebenkostenabrechnung kam gestern 
