Android-Prozesse laufen nun mal in einer VM. Damit sind alle Pointer doppelt so gross, und alle Objekte werden ueber Pointer addressiert (wobei der Objectheader auch noch minimal um Faktor 1.5 waechst). Sprich: wenn man nur normale Apps und keine riesigen Spiele programmiert, ist auf low power SOCs unter 64bit Architektur deutlich früher Schluss.
Auf der anderen Seite: die meisten Java oder Kotlin Apps für Android muessen von der Programmierung gar nicht weiter geändert werden, ob sie nun für 32 oder 64 bit gebaut sind.
Nur Librelink hat hier einen Caveat, weil die Lib zum decoding der Sensordaten obfuskierter Maschinencode in einer ELF-Lib ist -- sprich da muss die Variante zum Chip passen.
LG
Martin -- der schon seit der Zeit programmiert, als die Chips noch 8bit Register hatten
Die benutzen ne kompilierte Library für die Sensordaten? Schon so richtig Pharmakonzern dieses Verhalten 
Stimmt aber schon dass Leute heute ineffizienter programmieren als früher und z. B. Java Referenzen wie nichts um sich herum schmeißen, auch wenn es in einer Situation Primitiven getan hätten (die damit ja auch keinen weiteren Pointer erzeugen). Vielleicht bin ich in meiner Art wie ich Programmiere einfach naiver zu glauben dass die Leute ja nicht sooo ineffizient programmieren dass das Erhöhen der Bittigkeit gleich den RAM-Verbrauch in die Luft gehen lässt.
Denn bei Software, die so programmiert wurde um viele Pointer und Referenzen zu vermeiden und möglichst vieles direkt im Stack zu machen, da gibts natürlich schon einen Mehrverbrauch, aber dieser würde den Speicherverbrauch doch nicht um 1.5 oder 2x erhöhen.
Ich selbst bin später dran aber hab auch Anfang der 2000er meine ersten Code-Abenteuer gehabt, ging halt erst mit 32 bit los
, danke