Beiträge von Berlino

17/12 läuft bei mir auch astrein - ohne Cata, aber mit Xposed.

Zitat

In version 79, I have fixed many crashes and bootloops that were reported on GitHub. It's hard to say which devices and ROMs profit from the changes. Affected devices mentioned in the issues were mainly HTC and LG, plus any devices which have activated the compiler filter "everything" for ART.

Background:
The reason for these issues is in pretty much all cases that AOSP can't handle so called "quickened" instructions like "invoke-virtual-quick". They're the result of optimizations when the ROM was compiled, and usually just need to be executable by the runtime. However, as Xposed needs to recompile the whole ROM to disable a few optimizations that would prevent hooks from being called, these instructions need to be understood by the compiler as well, which isn't always the case. It did get better in Android 6.0 due to beginning JIT support, so I could port several changes to 5.0 and 5.1 (which isn't as easy as it sounds). But even on 6.0, several fixes were required. Unfortunately, debugging the issues to find those fixes often takes many hours or even days, hence the rather long time between v78 and v79.

More issues?
I hope that by now, most of these issues should be solved. If you still come across any bootloops - even without any active modules - please open an issue on GitHub. You must include a logcat of the failing boot attempt, otherwise I can't help you. My recommendation: Clear Dalvik cache, restart device, execute "adb logcat -v time > logcat.txt" as early as possible, wait a few minutes, press Ctrl+C.

Android 6.0.1:
Additionally, I have merged the AOSP changes from 6.0.0 to 6.0.1. They're just a few fixes, so the SDK23 ZIP works on any 6.0.x ROM.

Genymotion:
The latest version of Genymotion emulator contains improved flashing scripts based on my GenyFlash project, allowing you to flash recovery ZIPs properly. Now you can simply drag & drop the Xposed Installer APK and then the x86 framework ZIPs from the first post onto the window, without the extra step of flashing GenyFlash. Due to the great boot speed and overall performance, module development becomes much more efficient (and no, they don't sponsor me, I really just like it).

Two final statements:
- Making Xposed "systemless" (i.e. work without modifying the /system partition) should be generally possible. However, it will certainly be much effort, especially due to the high diversity of devices. I follow the process of @Chainfire's systemless SuperSU experiment to see how feasible it is. Maybe once this approach has become more mature, it can be re-used by other projects such as Xposed. I'd want to avoid incorporating the whole kernel modification stuff though - if there was some kind of init.d-like interface that allows other projects to plug in and execute some commands at very early boot time (e.g. to mount a custom libart.so over the original one), that would be great. So much for wishful thinking - currently, I'm not working on this.

- It seems that some vendors have ported a change that was originally made in 5.1 back to 4.4 (KitKat). Xposed currently doesn't work with such ROMs. Why isn't this fixed yet? Well, I have completely restructured the source code and installation procedures for ART on Lollipop. Even though I kept Dalvik in mind, it will still require much more work and testing. Therefore, I'm not able to release pre-Lollipop files at the moment and due to the focus on Lollipop/Marshmallow, I don't think this will change for the next weeks or maybe even months.

Alles anzeigen

XposedBridgeApi-20150213.jar
XposedInstaller_3.0_alpha4.apk
xposed-uninstaller-20150831-arm.zip
xposed-uninstaller-20150831-arm64.zip
xposed-uninstaller-20150831-x86.zip
xposed-v79-sdk21-arm.zip (5.0)
xposed-v79-sdk21-arm64.zip (5.0)
xposed-v79-sdk21-x86.zip (5.0)
xposed-v79-sdk22-arm.zip (5.1)
xposed-v79-sdk22-arm64.zip (5.1)
xposed-v79-sdk22-x86.zip (5.1)
xposed-v79-sdk23-arm.zip (6.0/.x)
xposed-v79-sdk23-arm64.zip (6.0/.x)
xposed-v79-sdk23-x86.zip (6.0/.x)

Zitat

v3.4 is up: https://github.com/imoseyon/leanKern...llow-ChangeLog

Remember this will not boot on 6.0. 6.0.1 Marshmallow only!

I also put up a cm build in there - it has not been tested so let me know how it goes.

Zitat

v3.3 is up. A relatively small update. https://github.com/imoseyon/leanKern...llow-ChangeLog

I will work on making it CM13 compatible (and hopefully other CM based ROMS as well) next.

Habe die 2.1 auch eben geflasht und TiBu restored gerade dei Apps...bei mir waren ebenfalls keine APN's vorhanden - halb so wild, langsam kenne ich die Werte auswendig.

Zitat

v3.2.7 should fix battery stats for chroma and purenexus:

http://renderserver.net/?dir=devs/imoseyon/shamu/

No other change from v3.2.

Kann ich nicht sagen, habe immer noch die 58R-final mit Cata oben, gab ja bisher noch kein neues Stock-Update von Google. Also zu was das ganze neu flashen?

Also bisher läuft die Kombi sehr gut, habe keine Probleme festgestellt. Zum Glück hat man ein Nexus und MultiRom...da darf es dann auch schon des öfteren in den Fingern jucken - flash frei.

Die erste Beta für MM ist raus:

Zitat

What's missing in version for Marshmallow compared to Lollipop
- No NFC tile. Requires further investigation.
- No LockScreen tile. Requires further investigation.
- No Music tile.
- RingerMode tile has been changed to allow only ringer specific modes: sound/vibrate/sound&vibrate. It won't allow changing Do not disturb modes, but it's still capable of indicating current DND mode. Use stock tile for managing Do not disturb modes.
- Heads up features are limited since it is no longer a standalone system window but rather standard notification which can show in special mode where notification panel is invisible
- No status bar notification ticker features as support for ticker has been completely dropped in Marshmallow.
Full commit history can be found in project's github.
- No unlinking of ringer/notification volumes

QuickSettings management and SystemUI tuner
Avoid using SystemUI tuner for quick settings when you have QS management enabled in GravityBox.
SystemUI tuner QS management will crash as it doesn't know about tiles coming from GB.
Nothing to be fixed form GB side.

Known issues
- UNC ActiveScreen doesn't work properly cutting off notification sounds
- Search key in the Pie controls crashes SystemUI

Settings from Lollipop
It is possible to restore backup of the settings made in LP version of GravityBox.

Full history of changes for transition from LP to MM
https://github.com/GravityBox/Gravit...lp...v6.0.0_mm]

Alles anzeigen

Ja, habe ich auch so drauf (xtrasmooth + Cata-mod)...noch den hells drüber gebügelt, leider funzt der blu-spark nicht auf der Kombi.

Jedes Rom hat so seine Vorzüge, dieses ist übersichtlich von den Funktionen und sehr zackig. Da braucht es auch keinen edgy Kernel. Bisher funzt auch alles...hat gute Aktien auf meinen stabilen DD, andere Roms teste ich gern als 2nd im MR.

Jedem dasseine - Cata ist schon ein klasse Rom/Mod, aber die AOSiP läuft bisher ziemlich rund bei mir und ist zudem auch sehr smooth im scrollen (da brauche ich auch gar kein Xposed mehr, um die Bremsen zu lösen).;)

Klar, ich installiere jedes Rom sauber neu bzw. als 2nd im MR. Aber nen PC brauche ich dazu nicht. Mit dem Backup der Daten-Partition bin ich vorsichtig, da auch Rom-Einstellungen darin gespeichert werden. Das nutze ich nur bei Updates innerhalb desselben Roms.

Hehe, aus diesem Grund bin ich von Cata weg...is mir zu umständlich. Stock per fastboot mache ich nur, wenn ich mir das Phone zerschossen habe. Wenn es ein flashable von der 58R gibt, gern wieder Cata. Vorerst mal was anderes als DD...evtl. wird es ja dieses Rom hier.

Gerade mal die AOSiP geflasht, sehr smooth und nach-/mitflashen vom blu_spark klappte auch -> Batterieanzeige normal.

rovo89 hat jetzt für alle Android-Versionen ab LP 5.0 bis M 6.0 das Xposed Framework angeglichen:

Zitat

As promised, I have just uploaded version 78. It contains:
- [5.0 only] Bootloop on ROMs where the vendor has merged a recent security fix from 5.1
- [5.0/5.1 only] Backports of a few changes on Xposed that I had initially done for 6.0
- [6.0 only] Fix XModuleResources.createInstance() API method
- Fix for the invokeOriginalMethod() API method

Now, the 5.0, 5.1 and 6.0 ZIPs are in sync again. In the future, I plan to release ZIPs for all three Android versions at the same time again - even in case the changes affect only one version. I think that's better than having to keep track of the latest release per version. This time was an exception due to the backports that I needed to verify.

The source code is also published on GitHub now.

XposedBridgeApi-20150213.jar
XposedInstaller_3.0_alpha4.apk
xposed-uninstaller-20150831-arm.zip
xposed-uninstaller-20150831-arm64.zip
xposed-uninstaller-20150831-x86.zip
xposed-v78-sdk21-arm.zip (5.0)
xposed-v78-sdk21-arm64.zip (5.0)
xposed-v78-sdk21-x86.zip (5.0)
xposed-v78-sdk22-arm.zip (5.1)
xposed-v78-sdk22-arm64.zip (5.1)
xposed-v78-sdk22-x86.zip (5.1)
xposed-v78-sdk23-arm.zip (6.0)
xposed-v78-sdk23-arm64.zip (6.0)
xposed-v78-sdk23-x86.zip (6.0)

Zitat

"Some issues might arise from JIT (disabled by default, even in AOSP) and the "optimizing" compiler (which rewrites apps' code to be more efficient, due to which some calls might simply be skipped)."

Yeah. I was wondering why I didn't come across any issues at all with the optimizing compiler during development - especially as Xposed Installer relies on certain methods not being optimized away. It turned out that a special kind of optimization wasn't done for debuggable versions of apps - so on my device, with Xposed Installer installed via Eclipse, everything was fine, but when you have the release build, some hooks are ineffective because the method is never really called, so the active Xposed version wasn't detected properly...

That's why I had to upload a new version 77 which disables the method inliner for the optimizing compiler as well, just like it was for the normal ("quick") compiler already. It will also trigger the recompilation of all oat files, so the first boot will take longer again.

XposedBridgeApi-20150213.jar
XposedInstaller_3.0_alpha4.apk
xposed-uninstaller-20150831-arm.zip
xposed-uninstaller-20150831-arm64.zip
xposed-uninstaller-20150831-x86.zip
xposed-v75-sdk21-arm.zip (5.0)
xposed-v75-sdk21-arm64.zip (5.0)
xposed-v75-sdk21-x86.zip (5.0)
xposed-v75-sdk22-arm.zip (5.1)
xposed-v75-sdk22-arm64.zip (5.1)
xposed-v75-sdk22-x86.zip (5.1)
xposed-v77-sdk23-arm.zip (6.0)
xposed-v77-sdk23-arm64.zip (6.0)
xposed-v77-sdk23-x86.zip (6.0)

rovo89 hat nun Xposex Framework v76 für Android M 6.0 rausgebracht:

Zitat

Marshmallow!

I have just uploaded version 76 with support for Android 6.0 (Marshmallow). Even though I tested it only on my Nexus 9/arm64, I'm confident that the arm and x86 builds will work fine as well. The Xposed Installer app didn't require any changes, you can still use version 3.0 alpha4.

What else can I say about it? Well, as expected, the upgrade from 5.1 to 6.0 was a much bigger one than from 5.0 to 5.1. Therefore, porting the Xposed-related changes in ART was more complicated, but as Google has done a lot of refactoring, I could simplify some of my own changes as well. Pretty much everything is ported now, except for support for gzipped and encrypted files - let's see if vendors even use them on 6.0.

The only limitations I'm aware of at this time are:
- I have only tested this with SuperSU installed, due to which dm-verity and some SELinux rules are disabled. Especially dm-verity would definitely conflict with the modifications of the system partition.
- Access to preferences files might be blocked by SELinux, and Xposed is currently not able to work around that. (*) Some modules might be affected by this, nevertheless I strongly recommend to keep SELinux enabled and enforcing to keep your device as safe as possible.
- I could not test all Xposed APIs. The system is booting without any error messages from Xposed, but some functions that the framework makes available might still need to be adjusted for Marshmallow.
- Obviously, modules themselves might need to be updated as well due to changes in AOSP. Please be patient and give module developers the time to make the required changes. If you absolutely "cannot live" without module X, don't update to Marshmallow yet.
- Some issues might arise from JIT (disabled by default, even in AOSP) and the "optimizing" compiler (which rewrites apps' code to be more efficient, due to which some calls might simply be skipped). Both of these are new in Marshmallow and might have various consequences in combination with Xposed, from hooks that silently don't work to crashes. However, as it's running stable for me, I decided not to disable them and will instead look into them in more detail if concrete issues are reported.

Three more things:
- I plan to publish a new version for Lollipop (5.0/5.1) within the next days, with backports of some of the changes I did for Marshmallow. This needs some more testing though.
- I know that some vendors seem to have backported the latest 5.1 security fix (see a few posts above) to 5.0, due to which Xposed is no longer working. This should also be fixed with the next version.
- I will push the changes to GitHub soon, also within the next days (once I have made sure they don't break 5.0/5.1).

And now: Have fun flashing Marshmallow and Xposed! Discussions gohere.

(*) For developers: Marshmallow now lets apps run with context "u:r:untrusted_app:s0:c512,c768" instead of "u:r:untrusted_app:s0". If the app is run by a secondary user, the level ("c<nnn>,c<nnn>") is different, and system apps (like Settings) don't have such a level at all. The SELinux policy allows access to app data files only when the the level of the file and the process matches exactly, therefore you can no longer access preferences created by a primary user app from apps like Settings or while logged in as secondary user. I do have workarounds for Zygote and system_server, but I can't use them for normal apps in their current state as it might open big security holes.

Alles anzeigen

Zitat

v3.2 is up: https://github.com/imoseyon/leanKern...llow-ChangeLog

Sorry guys i haven't had a chance to look at PureNexus yet. Will take a look soon...

Die Velocity ist im Moment eines der schnellsten Roms und hat übersichtliche Features, allerdings fällt mir auf, dass die Uhrzeit nicht richtig gesynct wird, wenn der Bildschirm an ist (In den Einstellungen für Datum und Uhrzeit ist aber alles auf automatisch eingestellt).

Habe mal etwas recherchiert und 2 build.prop-Einträge hinzugefügt, mit denen das Problem nun behoben zu sein scheint:

persist.timed.enable=true
persist.sys.timezone=europe/amsterdam