-
"Aber"
Autor: picaschaf 05.08.17 - 18:29
"Stock" und "eigene Verbessungen" schließen sich schon sprachlich aus. Und solange das Image nicht gegen einen offiziellen Google Build verifizierbar ist (was er nie sein wird sofern deren Treiber nicht vollständig Mainline sind) ist das ganze "pseudostock" Gehabe wertlos.
-
Re: "Aber"
Autor: Apfelbrot 05.08.17 - 19:57
picaschaf schrieb:
--------------------------------------------------------------------------------
> "Stock" und "eigene Verbessungen" schließen sich schon sprachlich aus. Und
> solange das Image nicht gegen einen offiziellen Google Build verifizierbar
> ist (was er nie sein wird sofern deren Treiber nicht vollständig Mainline
> sind) ist das ganze "pseudostock" Gehabe wertlos.
mimimimi -
Re: "Aber"
Autor: quasides 06.08.17 - 02:24
stimmt,
welcher launcher, phonebook etc drauf sind ist unerheblich.
es läst sich stock in jedem fall nachinstallieren. das wirkliche problem ist der fragemntierte build.
damit gibts wieder keine updates.
und ich frag mich bis heute wieso der build nicht ident bei den herstellern it samt sys updates per paketmanager, ist ja nicht so das nicht fähige paketmanager verfügbar wären, opensource.
dann gäbs die möglichkeit auf updates bis die hardware die nimmer schafft...
und warum selbst unter android 7.1.2 kein vernüftiges backup zu haben ist.
die google lösung ist ein schlechter scherz -
Re: "Aber"
Autor: codeworkx 06.08.17 - 07:32
picaschaf schrieb:
--------------------------------------------------------------------------------
> "Stock" und "eigene Verbessungen" schließen sich schon sprachlich aus. Und
> solange das Image nicht gegen einen offiziellen Google Build verifizierbar
> ist (was er nie sein wird sofern deren Treiber nicht vollständig Mainline
> sind) ist das ganze "pseudostock" Gehabe wertlos.
Solange sie die Schnittstellen nicht anpassen, erweitern oder versauen ist es um einiges leichter AOSP zum laufen zu bekommen. Beste Voraussetzung bieten zudem Qualcomm SoCs wegen codeaurora. Bin gespannt.