Mythen und Sagen - Fakten und Wahrheit über Android Phones

[LaBro83]

Guten Tag

Ich habe gestern Abend was interessantes über unsere Android Phones gefunden und denke, dass diese sehr ausschlussreich sind.
Und besonders für Android Neulinge ist dieses hier sehr hilfreich

Ab hier ist alles vom original Post übernommen:

Da es ja immer noch hartnäckige Mythen gibt die sich in den letzen 12-15 Monaten bei uns Andro'iden eingeschlichen haben, möchte ich (mit eurer Hilfe) ein wenig Klarheit schaffen, damit sich diese Mythen bei Newcomern in der Android community nicht weiter fortsetzen. Ich werde es in Gebots-Form schreiben, damit es euch ein wenig amüsant zum lesen ist. Und versuche es einfach und verständlich zu halten, also keine wikipedia abhandlungen oder seitenlage Vorträge ueber das schaffen und wesen von Android.

Daher rufe ich die "Gurus" des Android Community auf, mir dabei zu helfen.

Übersicht:

Gebot 1: DU SOLLST NICHT WIPEN DEN DALVIK-CACHE. Nutze diese Zeit lieber, um mir (Android) zu huldigen und erliege nicht diesem Plazebo!
https://www.android-hilfe.de/forum/...ueber-android-phones.198740.html#post-2645790

Gebot 2: DU SOLLST NICHT ALLES LADEN AUS DEM MARKET WAS ES GIBT. Halte mich optimal, und ich werde es dir danken.
https://www.android-hilfe.de/forum/...ueber-android-phones.198740.html#post-2645797

Gebot 3: DU SOLLTE BEIM ROM WECHSEL KEINE BACKUP TOOLS VERWENDEN UND DEINE FEHLER DANN AUF DIE UNFÄHIGKEIT DER ROM_DEVELOPER SCHIEBEN. Wenn du nicht die Muse hast, die 20 Minuten zum Neueinrichten aufzubringen, so warte bis du Zeit dazu hast, und schiebe dein Paket nicht vor die Füsse der Community und sage "Mach".
https://www.android-hilfe.de/forum/...ueber-android-phones.198740.html#post-2645812

Gebot 4: DU SOLLST KEINE TASKKILLER VERWENDEN. Du kannst Autokiller verwenden, aber nur wenn es notwendig ist, was aber am 7ten Tag der Schöpfung der Android Welt kaum noch zutrifft. Den die Jünger des Google sahen ihre Fehler und verbesserten diese.
https://www.android-hilfe.de/forum/...ueber-android-phones.198740.html#post-2645820

 

[LaBro83]

Mythos 1: Das wipen vom Dalvik-Cache und Cache

Vielen habe in den letzen 12 Monaten, angeregt von vielen Foren, den Mythos des wipen des dalvik-caches erfunden und nutzen diesen noch nach jedem Flashen oder zur Fehlerbehebung.

Fakten:

Bei einem Boot des Android OS schaut sich der Dalvik (Virtual Machine) die installierten Applikationen (.apks.) und framework Files des jeweiligen ROMs an und erstellt daraus einen Baum der jeweiligen Abhängigkeiten zu den "framework" files. Auf dieser Basis optimiert dann der Dalvik den Code der applikationen und speichert diese im Dalvik-Cache. (.dex). Also 2 Schritte, erst Abhänigkeitsbaum, danach "entpacken" und optimieren der in Applikationen enthaltenen .dex files.

Bei odex-basierten ROMS (meist nur die original Google ROMS) sind diese Optimierungen teilweise bereits erledigt in ".odex" dateien, es wird die Applikation also gesplittet und das normalerweise in der Applikation enthaltene .dex file wird bereits optimiert neben der .apk selbst abgelegt (.odex). Da dies aber Änderungen wie Themes etc erschwert, sind die meisten FW/ROMS nicht "odex'et", sondern "de-odexted", also eigentlich wurde die Optimierung rückgängig gemacht. Dies wirkt sich nicht auf die Geschwindigkeit des ROMs an sich aus, nur beim ersten Reboot dauert dieser länger, da der dalvik-cache diese Arbeit wieder übernehmen muss.

JEDOCH! der dalvik an sich arbeitet auch im laufenden System (sonst wäre es ja nicht möglich, Applikationen zu installieren ohne reboot. Daher entstammt einer der Mythen: Davilk arbeitet NUR beim Start-Up. Das ist nicht korrekt. Somit: Sobald sich, entweder vor dem Boot, oder im laufenden System irgendetwas ändert (egal ob installieren, deinstallieren oder LÖSCHEN von Apps wird der Dalvik aktiv und optimiert/löscht die jeweiligen .dex files im Cache.

Der cache des dalvik wiederrum "sitzt" in der User-Partion des OS (/data). Eine Ausnahme ist der "Memhack" dieser verschiebt den Dalvik-Cache auf die SDKarte, um freien Platz bei ROM-speicher Mangel zu schaffen (wir aber nur bei einigen älteren Phones noch verwendet so weit ich weiss). Daher betrachte ich "memhack" hier nicht weiter.

Wenn man also ein neues Rom lädt (beispiel beim Milestone: durch flashen eines "full" releases) oder manuell die /data Partion gelöscht wird (wipen) (PS: Wipe data und factory reset sind 100% das gleiche), so wird dieser Cache komplett entfernt (da Bestandteil der /data partition). Sobald man dann das ROM booted, übernimmt der dalvik wieder seine Arbeit, macht seinen Tree of dependencies auf, optimiert den bytecode und sichert diesen unten einem neuen dalvik cache unter der vorher geloschten und nun neu angelegten /data partition.
Dieses optimieren passiert immer, nach jedem Reboot! Manuelle intervention ist eigentlich NIE notwendig, denn auch wenn Fehler vorliegen, so werden diese automatisch durch den dalvik bereinigt, falsche .dex dateien gelöscht etc etc.

Beispiele des Mythos:

- Ich wipe /data -> cache und alle daten weg
- Ich spiele ein neues ROM auf (full sbf) -> cache und alle daten NOCHMALs weg
- Ich warte bis das flashen abgeschlossen ist, dann starte ich neu und gehe in die recovery um den dalvik zu löschen (zum 3ten mal lösche ich einen nicht vorhandenden satensatz

Diese 3 Aktionen machen 3 mal das gleiche. Sinnfrei möchte man meinen als Neuling, oder?! Korrekt, absolut sinnfrei und sinnlos Nichtsdestotrotz hält sich dieser Mythos immer weiter

Daher...

- Bei jedem Reboot wird der Dalvik-Cache optimiert. Ist er nicht vorhanden (unsere 3 Beispiele), wird er komplett neu angelegt (Bootzeit ist sehr lang wenn der cache komplett neu erstellt wird)
- Auch im laufenden System arbeitet der dalvik und hält das OS im optimalen Zustand
- Selbst WENN es mal Fehler geben sollte (nehmen wir an, ich lösche eine APK innerhalb der recovery, oder via update.zip oder sonstiges (also alles wo der dalvik NICHT aktiv ist im System), der nächste reboot erfolgt, und der dalvik optimiert das system wieder ohne notwendigkeit des wipen des caches

Schadet das Wipen des caches? Nein schaden tut er nicht. Aber bringen tut er auch nichts (bis auf absolute Sonderfälle). Ich habe bestimmt 100 Flashes hinter mir auf dem Milestone, und sicherlich an die 100 Nighltlies und ROMS installiert auf dem Nexus. Nicht einmal habe ich den cache gelöscht oder löschen müssen, um Fehler zu korregieren. Das Android OS übernimmt das vollkommen ohne User-Intervention (bis auf absolute spezialfaelle, die es geben MAG, aber die ich nicht einmal gesehen habe)


Das GEBOT:

DU SOLLST NICHT WIPEN DEN DALVIK-CACHE. Nutze diese Zeit lieber, um mir (Android) zu huldigen und erliege nicht diesem Plazebo!

 

[LaBro83]

Mythos 2: Je mehr apps, umso besser

Wer kennt das nicht. Ich habe ein neues tolles Smartphone und ja, ich mag apps. Ich installiere mit also 107 apps. Danach wundere ich mich warum ich nicht so schnell bin wie am Anfang oder warum manche Sachen einfach nicht klappen oder ich Probleme habe. Ach ja, diese 107 apps installiere ich mir aufein älteres Smartphone, mit weniger RAM/ROM/CPU Specs als bei den neuen "Überphones"

Die Fakten:

Erinnert ihr euch an Mythos 1? Alle diese 107 Apps sind nun im dalvik-cache und der dalvik hat alle diese 107 apps optimiert und hält diese, auch wenn sie nicht "aktiv" laufen im System, immer auf dem optimalen Stand in Verbindung mit dem Dependancy-Tree und den framework Datein des Android OS. Das heisst also, der Dalvik hat viel mehr zu arbeiten als notwendig, und vor allem bei "low-tier" oder älteren Android Phones geht dies auf die Kosten der Systemleitstung, des internen Speichers (es wurde app2sd erfunden) und ich komme zu akkutel RAM Mangel (siehe Mythos 4)
Das es auf Kosten des Speichers, der Übersichtlichkeit und auch des Sinnes geht, mag offensichtlich erscheinen. Oder das der Market nun 107 Apps auf Neuigkeiten oder updates überprüft bei jedem boot.

Was kann ich also machen, wenn ich eben 107 apps haben möchte, weil ich die eine oder andere eben 1-2 mal im Jahr nutze?!
Mein Vorschlag. Legt die App irgendwo auf eure SDCARD. Oder ladet sie euch eben aus dem Market runter wenn ihr sie gerade benötigt. Aber ich,für meinen Teil, möchte aus den oben genannten Gründen diese nicht aktiv im System installiert haben. Natürlich kann dies jeder so halten wie er möchte. Und natürlich, man schaut sich diese oder jene App mal an und tested diese. Aber wenn sie nicht unbedingt notwendig ist, so würde ich sie immer nach dem Test deinstallieren (und ggls manuell sichern auf der SDCARD). Nur so halte ich mein System optimal und ohne unnötigen Balast.

Das GEBOT:

DU SOLLST NICHT ALLES LADEN WAS ES GIBT. Halte mich optimal, und ich werde es dir danken.

 

[LaBro83]

Mythos 3: Backup via Titanium etc bei ROM Wechsel

Viele von uns sind ja zum Hobby-Flasher mutiert. Wir flashen uns jeden Tag ein ROM und suchen nach dem heiligen Gral, dem optimalen ROM. Das ist vollkommen OK!! Daher ist es ja ein Hobby von uns geworden. Und auch der Sinn des freien OS (solange ich nicht restriktion wie Bootloader locken etc einbaue)

Das Problem:

Wir alle haben unsere Einstellungen, APPS und sonstiges, welche wir gerne nutzen und wie unser Android Phone eingestellt/eingerichtet sein soll. Und diesen Neu-Einrichten dauert seine Zeit. Daher sind viele User dazu übergegangen, Backup Programme aus dem Market zu nutzen, um diese Einrichtungszeit zu optimieren und zu verkürzen.

Die Fakten:

BACKUP Tools sind NICHT dazu konzipiert, Datensätze zwischen 2 verschiedenen Android ROMS, sei es ein anderes ROM auf gleicher Android OS Version oder eines Versions-Sprunges des Android OS (wie z.B. von 2.1 auf 2.2) wiederherzustellen. Backup tools funktionieren so wie sie entwickelt wurden, nämlich Datensätze zu sicher und auf der GLEICHE ROM/OS Version wieder herstellen zu können.

Warum?

Ganz einfach. Applikationen, seien es SystemApps (also datein in /system/app) oder User/Market apps (data/app) haben einstellungen, code-lines und sonstiges, die als Einstellungen/settings (/data/data) in der User-Partition gesichert werden. Dies können Datenbanken, XML files oder sonstiges sein. Wenn ich nun das ROM ändere, upgrade oder sonstiges, so sind auch die jeweiligen Applikationen in einer neuen Forum vorhanden. Die Datenbanken sind anders strukturiert, codes wurde optimiert oder sonstiges. Wenn ich nun Einstellungen, beispielsweise die Einstellungen einer System App auf 2.1 basis sichere und auf einem neuen ROM (2.2) wiederherstelle, so kann es sein, das das klappt, aber höchstwahrscheinlich mache ich damit die Optimierungen von Google oder anderen Entwicklern wieder rückgängig und schaffe mir Probleme, die dann fast unmöglich zu root-causen und beheben sind. Ich habe also 2 Variablen vertauscht - eine neues ROM und meine alten EInstellungen. Wenn nun etwas nicht klappt, woran liegt das. Ist es das neue ROM, die neue Applikation oder mein Bemühen, Zeit zu sparen? Ich persönlich versuche immer, nur eine Variable zu ändern.Somit weiss ich woran es liegt und kann ggfls diesen Fehler beheben oder wirklich sagen "Das ROM ist nicht gut".
Natürlich KANN es funktionieren. Das ist möglich, aber je nach App vollkommen unterschiedlich und im besten fall ist es "trial-and-error"

Jeder Entwickler, jeder erfahrene User und jeder ROM-oder APP developer warnt davor, die backup tools so "mis-zuverwenden". Nochmals: BACKUP tools haben einen Sinn. Innerhalb eines bekannten Zustands (gleiches ROM, gleiche OS Version) Einstellungen zu "backupen" und ggfls restoren zu können. Sobald man diese backup tools dazu verwendet, Einstellungen ausserhalb dieses bekannten Zustands wiederherzustellen, so ist man selbst für Fehler verantwortlich. Und das ist auch einer der Gründe, warum viele Developer bei Misachtung dieser Regel jeglichen Support einstellen, denn es ist den Entwicklern UNMÖGLICH auf dieser Basis Hilfestellung zu geben, da es zu viele Variablen gibt die nun verändert wurden um eine korrekt Root-cause analyse zu betreiben.

Ich möchte damit nicht sagen, ich dürft es nicht probieren. Was ich sagen möchte: Ihr könnt es versuchen. Es KANN gutgehen. Zu 10% geht es gut. Zu 90% nicht. Gibt es fehler bei euch, so bitte bitte bitte keinen Post dazu. Schon gar nicht so geschrieben, das die Developer, die das alles umsonst in ihrer Privatzeit fuer euch machen, gefrusted werden. Also - vor dem "Geht nicht, mach wieder ganz-posting" - zurueck zum start. Data Wipen, neu von Grund auf neu einstellen. Dann kann man euch, wenn es IMMER noch Fehler gibt, auch helfen von seiten der Developer und community. Und dann kann man gerne posten und die developer und die community nach rat fragen. Dann wird kein Developer euch den Support verwehren und auch die Community wird es euch danken.

Fausregel bei ROM oder FW Wechsel:

- Kann ich SMS backupen? JA kannst du, die sind unkritisch im Normalfall. Oder du synchronisierts diese über GMAIL, das ist noch besser. (tools dafuer im Market)
- Kann ich APPS backupen? KANNST du, ich mache es nicht, der Market übernimmt dies automatisch mit den richtigen Einstellungen. Wenn ich ein ROM teste, so wipe ich data, spiele das ROM ein, und stelle 1 Sache ein - mein Google account. Dort sind die wichtigsten Sachen wie Kontakte (GMAIL) und Applikationen hinterlegt, sobald ich mein google account einrichte, so restored der Market (in der Momentan vorhandenen Version beim schreiben dieses Textes) automatisch meine Installierten Applikationen (die installiert waren BEVOR ich das ROM gewechselt habe) und meine Kontakte werden über GMAIL ge-syncht. So ist Android konzipiert, und nur so kann ich sagen das es einwandfrei funktioniert.
- Kann ich einstellungen backupen und nachher wiederherstellen lassen auf dem neuen ROM? NEIN, du kannst es probieren. Aber die versuchte Zeitersparnis dadurch wird zu 90% der Fälle durch Frustration, Fehlersuche oder Probleme (und schreiben in Foren "hilfe das geht nicht, bitte helfen") wieder um ein Vielfaches kompensiert.

Mein Tipp:

Lasst die Finger von Backup programmen beim ROM wechsel. Nutzt die Android Tools (Market, GMAIL etc) für die Basis-Einstellungen . Den Rest (Ringtones, Einstellungen,Homescreens etc) von Hand wieder einstellen. Das kostet 10-20 Minuten Zeit für einen erfahrenen User aber schützt euch vor Frustration und anschliesender Fehlersuche. Und ein frisch eingestelltes System ist IMMER besser als ein rüberschaufeln von anderen Android oder ROM versionen.


Das GEBOT:

DU SOLLTE BEIM ROM WECHSEL KEINE BACKUP TOOLS VERWENDEN UND DEINE FEHLER DANN AUF DIE UNFÄHIGKEIT DER ROM_DEVELOPER SCHIEBEN. Wenn du nicht die Muse hast, die 20 Minuten zum Neueinrichten aufzubringen, so warte bis du Zeit dazu hast, und schiebe dein Paket nicht vor die Füsse der Community und sage "Mach".

 

[LaBro83]

Mythos 4: Taskkiller und autokiller

Viele von uns, vor allem wir Windows user, kommen zu Android und nehmen unser "Wissen mit". Leider übersehen wir alle dabei, das Android auf Linux basiert, und damit ein anderes Konzept verfolgt. Daher das alte Windows gesetz "Nur leerer Ram ist guter RAM" ist nicht 1:1 übertragbar.

Die Fakten: (noch mehr hier) http://developer.android.com/guide/t...damentals.html

Ein Android Phone besteht prinziell aus ROM und RAM. Das ROM, also der Flashspeicher oder Teile davon, sind für partitionen wie /data oder /system zuständig und reserviert (das macht das Betriebsystem bzw die Firmware). Also quasi die Festplatten im Windows Jargon, auf denen das Betriebssystem und Daten gespeichtert sind.

Das RAM ist dann der Speicher, der wie bei Windows dem Betriebsystem zur verfügung steht, um im ROM gespeicherte Applikationen, Prozesse oder aehnliches auszuführen.
Im Normalfall ist das RAM so ausgelegt, das es ausreicht, alle Prozesse im OS etc auszuführen.
Sollte es mal "eng" werden im RAM, so hat Linux und auch Android Schwellenwerte, an wann im RAM abgelegte oder ausgeführte Prozesse zu beenden sind. Diese werden so beendet, das die Appliation beendet wird, aber kontrolliert. Diese Schwellenwerte (Low Memory Killer) gibt es fuer verschiedene Typen von Applikationen:

Foreground App (mb):
Visible App (mb):
Secondary Server (mb):
Hidden App (mb):
Content Provider (mb):
Empty App (MB):

Wenn also Schwellenwerte in Megayte fuer diesen Typ der Applikation erreicht werden, werden die Applikationen suksessive geschlossen, und zwar im Rahmen ihrer Prioritaten von unten nach oben (also zuerst "leere Applikationen" danach Content Provider apps etc etc).

Im Prinzip ist das eine Art "failsafe" um das System nie soweit kommen zu lassen, das es akkuten RAM Mangel gibt und APPS nicht mehr ausgefuehrt werden (koennen.)


Der Autokiller:

Der Autokiller kann diese Schwellenwerte ändern, je nach Einstellung wird also früher vom System in die laufenen Apps und Prozesse eingegriffen (kontrolliert). Auch hier gilt: Solange ich nie an diese Schwellenwerte herankomme, bin ich absolut auf der sicheren Seite und es gibt keinen Grund den Autokiller zu verwenden. Damit schaffe ich nur Instabilitaeten im System, den Prozesse und Apps werden geschlossen um RAM freizugeben, der aber dann "sinnlos" nicht genutzt wird.

Nehmen wir 2 Beispiele:

Das NEXUS one: 512 MB RAM, 512 MB ROM
Das Droid/Milestone: 256 MB RAM, 512 MB ROM

Das Design des Nexus erlaubt also, ca 512 MB an Betriebsystem und Daten zu nutzen ROM (aufgeteilt auf /system/ und /data)
Da das RAM gleichfalls grosszügig dimensioniert ist mit 512 MB, werden die oben genannten Schwellenwerte fast (oder so gut wie nie) erreicht-> ergo die Schwellenwerte zu ändern hat keinerlei Einfluss
Aktives Beispiel Nexus One:

Foreground App (mb): 6
Visible App (mb): 8
Secondary Server (mb):16
Hidden App (mb): 20
Content Provider (mb):22
Empty App (MB): 24

In meinem Fall habe ich immer mehr als 200MB RAM frei, also massiv platz nach unten, und Autokiller Verwending macht keinerlei sinn! Ergo: Bei guten design (ROM SPEICHER UND RAM SPEICHER gleichgross oder aliquot konzipiert) bzw. wie bei noch neueren Smartphones in mehrere Partitionen unterteilt ist kein Autokiller notwendig.

Milestone1/Droid1:
Wie wir sehen ist das RAM nur halbsogross wie das ROM. Lade/Flashe ich nun ein anspruchsvolles Betriebsystem oder Mod eines Betriebsystems, bei dem viel Speicher fuer /system verwendet wird, so kann es der fall sein, das ich, wenn ich nun den restlichen Speicher des "ROMS", also /data mit massig Applikationen "vollstopfe", ich mehr RAM benötigen würde um alle diese Prozesse und Applikationen auszuführen. Ergo: Ich werde eventuell diese Schwellwerte erreichen. Hier KANN!! eine Nutzung von Autokiller, also der Veränderung der Schwellwerte zu leichtem Performancezuwachs führen. Dies ist im Einzelfall zu klären.

Als Faustregel fuer das MS/Droid:

-Wenn ich ein "schlankes" OS nutze wie die standard Motorola OS Versionen oder CM6 und NICHT den verbleibenden Teil des ROMs (/Data) für eine massive Anzahl von Apps nutze, so ist ein Anpassen der Schwellenwerte nicht notwendig oder sinvoll.
- oder anders gesagt (beispiel Android System Info) -> solange "freier Systemspeicher/internal Memory dem freien RAM speicher entspricht oder der freie RAM speicher groesser ist als der verbleibende "ROM" Speicher, ist alles tipptopp in Ordnung.
-Wenn das OS jedoch mir meldet "geringer Speicher (in der Datenpartition) und ich dann das freie RAM überprüfe und dies in der Nähe der Schwellenwerte liegt, so kann ich 2 Sachen machen:
a) Ich lösche Apps, um das ROM (und damit das RAM) zu enschlacken
b) Ich ändere die Schwellenwerte via Autokiller (in dem Fall das ich keine Apps deinstallieren kann/moechte)

Ich persönlich wuerde zu a raten, und erst dann b anwenden, wenn ich keine weiteren apps oder daten löschen möchte.
Jedoch ändert Autokiller NUR die Schwellenwerte, und erlaubt damit Android, die Applikationen und services im Grenzfall kontrolliert zu beenden.

Die Taskkiller:


Taskkiller sind die 2te Variante. Diese beenden Prozesse und Applikationen "unkontrolliert", also ohne speichern und beenden der apps -> sie werden einfach "abgeschossen". Es gibt eine Vielzahl und Mehrzahl von Taskkillern auf dem Market, alle mit unterschiedlichen Features.

Taskkiller sind ein überbleibsel der Windows-Denke "nur freier RAM ist guter RAM". Am Anfang haben viele von uns, ich inclusive, den Taskiller gerne genutzt und immer alles geschlossen was zu schliessen geht Ich haabe iselbt prozesse gekillt, die wichtig waren , und mich gewundert, warum ich nun, wo ich doch so toll freies RAM geschaffen habe, mein Android Phone immer instabilier wurde.
Irgendwann habe ich einfach damit aufgehört Taskkiller in IRGENDEINER FORUM zu nutzen, und siehe da: stabiles System.
Es gibt zwar einen!! verbleibenden Sinn eines Taskkillers, naemlich Apps die nicht mehr reagieren zu beenden. Aber nachdem die Developer und ROM Produzenten ja ihre Programme und Kenntnissse immer verbessern, und auch das ANDROID OS selbst diese Programme beenden kann (Force Close) gibt es eigentlich kaum noch solche Fehler und Applikationen. Damit gehört, für mich, der Taskkiller zum absoluten NO-GO inzwischen.

Das Gebot!

DU SOLLST KEINE TASKKILLER VERWENDEN. Du kannst Autokiller verwenden, aber nur wenn es notwendig ist, was aber am 7ten Tag der Schöpfung der Android Welt kaum noch zutrifft. Den die Jünger des Google sahen ihre Fehler und verbesserten diese.

 

[Thoddü]

Ich glaub den Thread kennt jeder der hier mehr als 100 Beiträge hat. Da kann man sich jetzt drüber streiten ob es sinnvoll ist, den nochmal anzupinnen. Aber vlt. wirds hier dann ja ein bisschen aufgeräumter, sofern die Leute die Stickies lesen...

 

[Tel]

Ich glaub den Thread kennt jeder der hier mehr als 100 Beiträge hat. Da kann man sich jetzt drüber streiten ob es sinnvoll ist, den nochmal anzupinnen.

Ganau.
Das sollte allerdings auch für unerfahrene Nutzer gelten, die noch keine 100 Beiträge haben und unsere Stikies lesen.
Link zum Original-Thread steht u.a. auch in Randalls Beitrag:
https://www.android-hilfe.de/forum/...begriffserklaerung-fuer-neue-user.171220.html

Und wenn man schon eine komplette Reihe von Postings 1 zu 1 kopiert, gehört zumindest der Link zu dem Original-Thread dazu. Der hätte hier meines Erachtens auch vollkommen genügt. Warum hier alles nochmal?

https://www.android-hilfe.de/forum/...-und-wahrheit-ueber-android-phones.49971.html