[ROM] [JB 4.3.1 JLS36I] TREX v52 Final JOREX|HALO|PIE|Team T-REX

[WxK]

Android APN-Einstellungen: T-Mobile, Vodafone, E-Plus, o2, usw.

Krass, dass dieser Thread heute noch verwendet wird. Das waren meine alten G1 Zeiten

V35 läuft super!


Gesendet von meinem Galaxy Nexus mit der Android-Hilfe.de App

 

[klimo]

PS: Mal ne Grundsatzfrage: Da ich ja den Lock-Ring-REX bzw. Whatsup mit ZipThemer immer ändere. Flashen der zip`s.-Dateien mit Wipe cache & Dalvik cache oder einfach nur "drüberbügeln" ?

Kannst einfach drüberbügeln, aber den cache wipen schadet nicht, tut auch net weh ...

Na endlich, nun läuft es wieder.

Wie jetzt, @CHaindog hat nichts auszusetzten??? Wirklich nichts??? Na dann haben TREX & Jori wirklich alles richtig gemacht ( ist nicht böse gemeint, wirklich nicht )...

 

[Dirk64]

Das sind so Sachen, die gehen gar nicht. (Screenshot) Und wegen logcat: Irgendwas löscht dev/log/main!
Bei mir geht catlog jetzt, hab init.d ausgemistet.

Sent from GNex...

 

[justbig]

gibt es eigentlich eine aufstellung der vorinstallierten apps und den dazugehörigen apk, die man aus der rom entfernen kann, um sie nicht installiert zu bekommen .......so wie weiter oben die wallpapers oder den apex zb.

 

[qu4nd]

Und wegen logcat: Irgendwas löscht dev/log/main!
Bei mir geht catlog jetzt, hab init.d ausgemistet.

War mir auch aufgefallen. Würdest du "ausgemistet" mal etwas spezifizieren?

 

[klimo]

gibt es eigentlich eine aufstellung der vorinstallierten apps und den dazugehörigen apk, die man aus der rom entfernen kann, um sie nicht installiert zu bekommen .......so wie weiter oben die wallpapers oder den apex zb.

Nein, so eine Liste gibt es natürlich nicht. Man weiss doch ungefähr selber, welche apps man braucht und welche nicht. Die TREX ist 145 Mb groß, ist es nicht schlank genug?...

 

[owie]

Ich habe auch keine Schmerzen mit V35 und TapaTalk 4, WhatsApp und Skype. Läuft alles ohne Probleme und ist momentan quasi alles irgendwie im Dauereinsatz.

 

[Dirk64]

War mir auch aufgefallen. Würdest du "ausgemistet" mal etwas spezifizieren?

Bis auf sysctl, fixperm, tunacontrol und selinux alles raus. Genaue Ortung wäre aber noch fällig. Ich möchte aber T-Rex Tweaks hier nicht schlecht machen!! Werde mich auch in Zukunft diesbezüglich hier zurückhalten.

Sent from GNex...

 

[Don_Ron]

Hiho @ alls

Mal ne bescheidene Frage (nurmal als Info) , was genau ist bzw bewirkt eigentlich dieses "selinux" in Telefon-Info ganz unten , welches bei mir mit moderat festgelegt ist.

Bitte keinen Verweis aufs Git oder wie das heisst - da blicke ich wie letztens gesagt eh nicht durch.




@ justbig

Zitat_klimo: Nein, so eine Liste gibt es natürlich nicht.

Stimmt leider so nicht gänzlich ...

So nen Thread bezüglich problemlos löschbarer System-Apps gab es mal , gibts sicher auch noch - aber frag mich jetzt nicht wo genau , am besten einfach die SuFu mit dem Begriff Systemapps löschen füttern und dann die Search-Ergebnisse durchsuchen.

Ansonsten wie klimo schon richtig sagt - müsstest ja eigentlich aber auch selbst überschlagen können welche der Apps Du brauchst oder welche eher nicht. Dieser besagte Thread gab sowas wie ne kleine überschlagende Auflistung der löschbaren Apps - natürlich immer auf eigene Gefahr und ohne Gewähr sich das System nicht doch instabil zu machen oder gar zu zerschiessen - deshalb mal von mir hier auch keine Verlinkung dahin.

Ich persönlich habe zB nur die vier weiter oben genannten Life-Wallpapers , Maps , Hangouts , Calender.apk & den in der TRex integrierten ES-Dateiexplorer gelöscht.

Hintergrund des ganzen ist bei mir (obwohl ichs so genannt habe) aber nicht wirklich das schlanker machen (ok - bissl schon) , sondern das ich diese Wallpaper eh nie nutze , und bei den Apps ... das ich später diese Apps wie zB den integrierten ES gegen die black oder clear Variante ersetze. Selbige lassen sich durch ihre Signatur aber wie beim ES festgestellt nicht einfach drüberbügeln sondern das aufspielen klappte erst nach vorherigem löschen der jeweiligen apk.

So , das aber nurmal kurz OT zum Thema Systemapps löschen , möchte ich nun auch nicht weiter ausweiten.


@ TEAM-TRex

Ansonsten läuft die v35er Rom wirklich sehr sehr schön stabil und wie ich finde sogar noch nen Ticken schneller als die vorherigen v33 & v34.

Akkuwerte kann ich nachm Rückgehen des verwendeten Fancy auf r42-big auch nicht meckern , gestern im Laufe des Tages und über Nacht gerechnet nichtmal 25% Verlust der Kapazität - saubere Leistung.

Gruß Ronni


@ AndroidWilly

Jaja ... der gute alte Internet-Provider bzw APN-Thread

Krass, dass dieser Thread heute noch verwendet wird.

Jepp , scheint auch wie dort son bissl rauszulesen bei verschiedensten Roms aufzutreten das die APN's nicht übernommen werden - speziell wohl bei Verwenden von Roms mit Android 4.3.

Musste zwar auch erst ein bissl suchen letztes WE , aber hab ihn dann auch gefunden unter meinen abgespeicherten Fav-Threads.

Suchen deshalb - weil die Verlinkung im hiesigen Startpost zu dem dazumalem Zeitpunkt noch nicht stand bzw ich sie evl auch noch nicht für voll nahm.

Gruß Ronni

 

[T-REX600]

SELinux ist ein Security-Framework auf Basis der Mandatory Access Control, das Framework basiert auf dem Flask-Forschungsprojekt der amerikanischen NSA-Behörde [1]. Im Standardkernel ist es über das Linux-Security-Module-API (LSM) integriert. Alle Interaktionen zwischen so genannten Subjekten und Objekten sind durch eine gesonderte Security-Policy zu autorisieren.
Die Anweisungen enthalten dabei jedoch keine Datei-, Prozess- oder Benutzernamen, stattdessen kommt ein abstrahiertes Model mit Security-Labels zum Einsatz. Prozesse und Benutzer bekommen diese dynamisch zugewiesen, Dateien speichern das Label in den erweiterten Attributen. Es ist möglich, diese Policy zur Laufzeit des Systems zu ändern. Hierbei findet aber eine strikte Trennung von Policy und deren Durchsetzung statt.
Für das Enforcement sind diverse Hooks im Linux-Kernel zuständig. Sie erweitern die klassischen Zugriffsrechte der Discretionary Access Control (DAC) um die entsprechende MAC-Funktionalität. Über eine binäre Policy-Datei gelangen die eigentlichen Regelwerke in den Security-Server des Linux-Kernels.
SELinux kennt drei Modi: Im Enforcing-Mode ist jeder einzelne Zugriff einer Kontrolle durch die SELinux-Policy ausgesetzt. Jeder Zugriff wird ausgewertet und gegebenenfalls untersagt, wenn es keine Regel gibt, die diesen Zugriff erlaubt. Im Permissive Mode wird ebenfalls jeder Zugriff überwacht, allerdings kommt es nicht zur Durchsetzung der Regeln. Das bedeutet, dass ein Zugriff selbst dann stattfindet, wenn keine Regel den Zugriff explizit erlaubt.
SELinux schreibt für jeden nicht durch eine Regel erlaubten Zugriff einen Logeintrag, allerdings nur beim ersten Mal. Alle weiteren Zugriffe unterdrückt das System stillschweigend. Im Disabled Mode ist SELinux überhaupt nicht aktiv. Es kommen nur Zugriffsentscheidungen auf Basis der DAC zum Einsatz. Dabei muss der Administrator daran denken, dass Dateien, die im Disabled-Modus erzeugt wurden, auch kein Security-Label bekommen.

Edit:
Das klingt super, oder? Doch leider ist es weit von der Realität entfernt. Der SELinux-Implementation auf Android 4.3 fehlen derzeit einige wichtige Merkmale. Erstens ist SELinux nur im Permissiven Modus konfiguriert, das bedeutet Policies werden nicht durchgesetzt, und Verletzungen werden nur protokolliert. Wie oben zu sehen ist, bezeichnet das OTA-Update die Systempartitionen nicht korrekt (mein Testgerät ließ mich für eine Weile ziemlich ratlos dastehen, bis ich rausfand, dass der Forscher Pau Oliva genau dieselbe Erkenntnis auf der DEF CON 21 veröffentlicht hat), das bedeutet das ein Stock-Restore unumgänglich ist, wenn ein Entwickler es testen will. Abgesehen davon, dass die eingesetzten Policies alles andere als restriktiv sind, ist kein MAC für Android-Middleware verfügbar (ein Feature statt eines Teils des NSA Patch-Sets).
Was bedeutet das nun für den Endanwender? So wie’s derzeit aussieht, leider nicht viel. So wie auf Android 4.3 implementiert, kann SELinux lediglich getestet und Policies können entwickelt werden. Es gibt keine sichere Art, sie durchzusetzen. Jetzt ist in der Tat die Zeit der OEM-Anbieter gekommen. Google fördert nachdrücklich die Entwicklungen von SELinux-Implementationen (irgendwer BYOD?), die auf Stock-Funktionalitäten basieren – eher als auf zusammengeschusterten Add-Ons (hier wieder ein Verweis auf die DEFCON 21 für eine ausführliche Erklärung, was „Implementationsaspekte“ bedeuten können). Entwickler werden auf der anderen Seite dazu aufgefordert, sich mit den Standard-Policies vertraut zu machen und ihre Apps darauf zu testen. Werden wir je eine Android-Veröffentlichung mit SELinux im Enforce-Modus erleben? Das bleibt zumindest zu hoffen

 

[Don_Ron]

@ T-Rex600

Ooooha das ging ja schnell - Dankeschön

Ouuups - das muss ich mir glaube wohl wenigstens noch zwei- dreimal durchlesen und mental zu Gemüte führen - liest sich doch erstmal sehrsehr verwirrend. ;-)

Gruß Ronni

 

[T-REX600]

Ja Linux ist nicht einfach zu verstehen und Android erst recht nicht !

 

[jakal45]

SELinux ist ein Security-Framework auf Basis der Mandatory Access Control, das Framework basiert auf dem Flask-Forschungsprojekt der amerikanischen NSA-Behörde [1]. Im Standardkernel ist es über das Linux-Security-Module-API (LSM) integriert. Alle Interaktionen zwischen so genannten Subjekten und Objekten sind durch eine gesonderte Security-Policy zu autorisieren.
Die Anweisungen enthalten dabei jedoch keine Datei-, Prozess- oder Benutzernamen, stattdessen kommt ein abstrahiertes Model mit Security-Labels zum Einsatz. Prozesse und Benutzer bekommen diese dynamisch zugewiesen, Dateien speichern das Label in den erweiterten Attributen. Es ist möglich, diese Policy zur Laufzeit des Systems zu ändern. Hierbei findet aber eine strikte Trennung von Policy und deren Durchsetzung statt.
Für das Enforcement sind diverse Hooks im Linux-Kernel zuständig. Sie erweitern die klassischen Zugriffsrechte der Discretionary Access Control (DAC) um die entsprechende MAC-Funktionalität. Über eine binäre Policy-Datei gelangen die eigentlichen Regelwerke in den Security-Server des Linux-Kernels.
SELinux kennt drei Modi: Im Enforcing-Mode ist jeder einzelne Zugriff einer Kontrolle durch die SELinux-Policy ausgesetzt. Jeder Zugriff wird ausgewertet und gegebenenfalls untersagt, wenn es keine Regel gibt, die diesen Zugriff erlaubt. Im Permissive Mode wird ebenfalls jeder Zugriff überwacht, allerdings kommt es nicht zur Durchsetzung der Regeln. Das bedeutet, dass ein Zugriff selbst dann stattfindet, wenn keine Regel den Zugriff explizit erlaubt.
SELinux schreibt für jeden nicht durch eine Regel erlaubten Zugriff einen Logeintrag, allerdings nur beim ersten Mal. Alle weiteren Zugriffe unterdrückt das System stillschweigend. Im Disabled Mode ist SELinux überhaupt nicht aktiv. Es kommen nur Zugriffsentscheidungen auf Basis der DAC zum Einsatz. Dabei muss der Administrator daran denken, dass Dateien, die im Disabled-Modus erzeugt wurden, auch kein Security-Label bekommen.

Edit:
Das klingt super, oder? Doch leider ist es weit von der Realität entfernt. Der SELinux-Implementation auf Android 4.3 fehlen derzeit einige wichtige Merkmale. Erstens ist SELinux nur im Permissiven Modus konfiguriert, das bedeutet Policies werden nicht durchgesetzt, und Verletzungen werden nur protokolliert. Wie oben zu sehen ist, bezeichnet das OTA-Update die Systempartitionen nicht korrekt (mein Testgerät ließ mich für eine Weile ziemlich ratlos dastehen, bis ich rausfand, dass der Forscher Pau Oliva genau dieselbe Erkenntnis auf der DEF CON 21 veröffentlicht hat), das bedeutet das ein Stock-Restore unumgänglich ist, wenn ein Entwickler es testen will. Abgesehen davon, dass die eingesetzten Policies alles andere als restriktiv sind, ist kein MAC für Android-Middleware verfügbar (ein Feature statt eines Teils des NSA Patch-Sets).
Was bedeutet das nun für den Endanwender? So wie’s derzeit aussieht, leider nicht viel. So wie auf Android 4.3 implementiert, kann SELinux lediglich getestet und Policies können entwickelt werden. Es gibt keine sichere Art, sie durchzusetzen. Jetzt ist in der Tat die Zeit der OEM-Anbieter gekommen. Google fördert nachdrücklich die Entwicklungen von SELinux-Implementationen (irgendwer BYOD?), die auf Stock-Funktionalitäten basieren – eher als auf zusammengeschusterten Add-Ons (hier wieder ein Verweis auf die DEFCON 21 für eine ausführliche Erklärung, was „Implementationsaspekte“ bedeuten können). Entwickler werden auf der anderen Seite dazu aufgefordert, sich mit den Standard-Policies vertraut zu machen und ihre Apps darauf zu testen. Werden wir je eine Android-Veröffentlichung mit SELinux im Enforce-Modus erleben? Das bleibt zumindest zu hoffen

AAAAAAAAAAAAHHHHHHHHHHHHHHH ..................... ja alles klar, kenn mich aus

 

[CHaindog]

So, nun habe ich leider doch etwas gefunden (zumindest bei mir).
Nach einem Telefonat ist der Haken bei Datenverbindung raus. Kam heute schon 3 mal vor.

 

[jakal45]

Läuft alles kuschelweich; bei mir zumindest

 

[Don_Ron]

@ CHaindog

Nach einem Telefonat ist der Haken bei Datenverbindung raus.

Gerademal mehrfach probiert , bei mir alles easy - Häkchen für mobile Datenverbindung bleibt auch drinne.

 

[CHaindog]

Na mal sehen, morgen übernehme ich das Phone von Darkman, dann habe ich hoffentlich weniger Probleme mit.

 

[Don_Ron]

Glückwunsch zu Deinem neuen White-GNex ... hat sich meine dortige Anfrage betreff Noch-Verfügbarkeit ja auch erledigt - gut , ich suche ja auch eh mehr nach nem titan-farbenem.

Viel Spass dann mit dem neuen Spielzeug - Gruß Ronni

 

[CHaindog]

Das Titanfarbene Verkaufe ich, bzw ist verkauft.

 

[Don_Ron]

Is kein Problem , zwar platzte leider einer der letzten angestrebten Deals - habe aber auch schon ein anderes in eventueller Aussicht ... bzw ists bei mir ja eh nicht sooo eilig damit da ich ja ein top-funzendes in Verwendung habe.

Na dann drücke ich Dir mal die Daumen das es mit dem Whitey alles bissl besser bei Dir lööpen möge.

Sooo , nu aber End-OT (sonst kriegen wir noch eens uffn Deckel) ,

... Gruß Ronni