Ok Guys, Its my first post here but I have been lurking around here for quite some time, so I wont be as annoying as most noobs I guess
Anyway, I've tried many different ROMs on my captivate and I find all of them to be pretty good but I am yet to find one which packs all the goodies I want. They are not too much to ask for IMO. I need your advice and suggestions on this.
I want a ROM with the following in it:
-Extended Power menu(Recovery, Download)
-Touchwiz4 or Touchwiz4.5 launcher
-Gpsfix
-SuperUser Enabled
-ICS boot animation
-ICS themed( but wiht TW4)
-Some Tweaks for more battery life
- Some cool lockscreens(Preferably the ICS lock should be there)
- Shouldn't scoop up too much of memory( In some roms I couldn't get more than 120mb free RAM even in idle state. I want at least 170mb free)
scrypt said:
Ok Guys, Its my first post here but I have been lurking around here for quite some time, so I wont be as annoying as most noobs I guess
Anyway, I've tried many different ROMs on my captivate and I find all of them to be pretty good but I am yet to find one which packs all the goodies I want. They are not too much to ask for IMO. I need your advice and suggestions on this.
I want a ROM with the following in it:
-Extended Power menu(Recovery, Download)
-Touchwiz4 or Touchwiz4.5 launcher
-Gpsfix
-SuperUser Enabled
-ICS boot animation
-ICS themed( but wiht TW4)
-Some Tweaks for more battery life
- Some cool lockscreens(Preferably the ICS lock should be there)
- Shouldn't scoop up too much of memory( In some roms I couldn't get more than 120mb free RAM even in idle state. I want at least 170mb free)
Click to expand...
Click to collapse
Unfortunately, no one can tell you whats good for you. The only way to go about this is to read. From your questions, it appears that you dont appear too noob So, read the OP and last couple of pages of the threads. They should give a fair idea if anyone is facing any particular issues.
On side note; it appears KK4 source code has been released. So you may want to wait for some time before the magicians (Read: developers) wind their magic for ROMs and kernels.
If none of the roms have all the features...find one with the hardest to do (lock screen for example) and then add the rest in yourself.
This is xda...a place not only to download cool stuff..but also a place to learn how to do things yourself.
Like saying it needs to have a certain boot animation and launcher, that is EASILY changed.
I have found Fasty lll a real nice rom if you haven't tried it yet give it a shot. All you can do is try them to see if you like them.
knighted4
I've flashed MANY different ROM's, and not a single one has given me exactly what I wanted for features(Quite frankly, it's not the Dev's duty to fulfil my every wish). So what you end up with is, find a ROM that has as many of the most important features for you, that aren't apk related, load it, and modify it to suit your needs.
Truely, that is the best you're going to get. There are SO many different options available that it would be near imposible to find one that hits each and every thing on your list.......UNLESS you build the ROM yourself, and you can then cook it to suit your needs
No single ROM can fulfil your every desire...every rom has its highlights and low points but miui is better but u need to look for a touchwiz apk and install. On the bright side miui has customizable boot screen and lock screen
Sent from my I897 in the LION filled territory called Kenya using XDA App
This can turn in a redundant thread since every person has different needs.
On that note, thread closed.
PLEASE - No generic "This is awesome" or "Thank you!" posts. In fact, unless you're a themer or ROM developer with technical questions about this project, please refrain from cluttering the thread for the time being. This is NOT ready for users yet and needs a lot of work before it will be.
So, it has come up multiple times that users want some way to theme their devices. The problem is that until recently, the only option for that was CyanogenMod's theme engine. Unfortunately, integrating this is problematic for many ROMs - while it's fine for cherry-pickers who don't care about understanding what they're throwing into their project, it's a big issue for someone who does not want to put 13,000 lines of code into their project in a single patch. (CMTE is 13,000 lines of changes in frameworks/base, which is the very core of Android.) Also, it has been known to have resource usage and performance issues.
Over the past year, Sony has worked on getting a runtime resource overlay (RRO) implementation merged into Android. Most of the implementation was in Android 5.0, and a few bugfixes were in AOSP master until Android 5.1 was released.
A few months ago, a few developers figured out how to use RRO for theming. This system was called Layers, and initially appeared to have a huge amount of potential. Unfortunately, for various reasons, the system stagnated. The original set of commits to implement Layers had a whole pile of issues and clearly had not gone through code review, and when attempts were made to fix these issues, the Layers team wanted to make no further changes. For Omni, a core requirement we have for any theme system is that it cannot affect the user experience when no theme is in use/installed. Layers fails this criteria. (For example, in AOSP, the text on the battery history graph is pure black with no transparency. In Layers, it is mapped to "exposed_primary_text_light" which is a shade of black that includes transparency. There is no way for an overlay to change the other graphical elements that reference this resource without also affecting the battery history graph text, and vice versa. There were numerous other cases of "colors redefined" and "multiple different colors mapped to a single resource".)
I've been talking with members of a few project (including Slim and LiquidSmooth) about taking the basic concept behind Layers and fleshing it out into a mature system that addresses the various issues with Layers. Also, there's a desire to try and implement as much compatibility with CyanogenMod themes as possible without making excessive sacrifices (bloat, major mangling of Sony's RRO approach to facilitate compatibility with legacy themes... Despite nearly all themes requiring a rearchitecture for Lollipop...) in order to make it easier for themers to support this new approach.
Proposed Roadmap and Status
Here's a proposed roadmap I discussed with some guys from Slim and LS in a discussion on G+. None of this is set in stone though.
1) Merge CM's resource exposure commits. While there are many aspects of CMTE I dislike, these are unambiguously superior to the Layers resource exposure commits and I find nothing objectionable to any of them I've looked at so far, although they have yet to go through full review. STATUS: Up on Gerrit, they seem good.
2) Write a Python script that handles translating the overlays of a CMTE theme to one compatible with the new system - STATUS: Semi-working, but requires item 4 and fails for any theme that uses the "common" resource overlay. Themes that don't use "common" (like Mono and FlatshadeUI) can be translated in 3-4 minutes. Well-formed themes that use "common" require typically 20-30 minutes to manually dereference any "common" references. Some themes rely on some hacks CM has to handle incomplete styles in overlays and thus won't be supportable without hacks that may be undesirable.
3) Implement support for loading overlays from somewhere on /data - STATUS: Not started yet. Needs some good security gurus/SELinux guys to do right.
4) Implement support for overlays being able to reference their own resources. CMTE has this, I haven't quite figured out how they implemented it as it's 13,000 lines of code changes to sift through. - STATUS: See the commit list, this is currently working, however it is "proof of concept" quality
5) Implement support for a "common" overlay - many CMTE themes use this and more are using it as time goes on - STATUS: Not started yet. This may not be possible without architectural mangling to a degree that is undesirable
6) Well, this is more in parallel with items 4/5, but implement an app for managing overlays - it has to be after 3 though. Someone who sucks less than I do at UI/UX stuff needs to do this. - STATUS: Obviously not started yet. I've had a few people express interest in this stuff.
7) Longterm goal - Implement support for parsing a CMTE theme in the manager app. Gives similar results to CMTE, except the big difference is putting the "heavy lifting" in an app instead of frameworks/base. This keeps the really nasty code separate from the core frameworks and thus more maintainable. - STATUS: Not even close to started. There are some components of CMTE that I really dislike and this may not be possible to do without those components. It's also far more likely to fail in ways that make a themer look bad for something not necessarily their fault.
Ideally it should be able to provide fairly high compatibility with CMTE but without the system bloat and performance impacts that CMTE seems to entail.
Show me the Code! (Patches)
THESE PATCHES ARE A PROOF-OF-CONCEPT/WORK IN PROGRESS. DO NOT MERGE THESE INTO ANY PROJECT. I will NOT work with anyone who merges these before they are ready!
You can submit them to your own Gerrit for review, but DON'T merge them.
Resource exposure patches
These are similar to the patches that make up "Type 2 Layers" - but to maximize compatibility with CM themes, we're using CM's resource naming. In fact, all of these patches are cherry-picks from CM
https://gerrit.omnirom.org/#/c/13292/
https://gerrit.omnirom.org/#/c/13293/
https://gerrit.omnirom.org/#/c/13294/
https://gerrit.omnirom.org/#/c/13295/
Allowing overlays to reference their own resources
A major limitation of the vanilla RRO implementation is that an overlay cannot reference its own resources. Sometimes this is annoying, in other cases (such as windowBackground attributes - see http://developer.android.com/guide/topics/ui/themes.html ), it makes doing certain things impossible. One of my main goals has been to find the minimum amount of change to allow this. Currently, the patches below are also all extracted from CMTE's frameworks/base megacommit. If this architecture is preserved I'm going to fix authorship of these commits, but right now I'm hoping to use these to gain ideas for a better way to do this and in the process rewrite them. These commits in their current implementation have some serious architectural limitations.
https://gerrit.omnirom.org/#/c/13346/ - The core implementation. This allows overlays to use their own resources. I'm in the process of analyzing this to determine if there's a way to do this without the current limitations it has. Specifically, if you attempt to use a "standard" overlay with package ID 0x7f, the overlay will completely fail and cause severe issues.
https://gerrit.omnirom.org/13347/ - Treat a few other PackageIDs as being "static" packages. I'm still in the process of reading through Android's code to figure out the differences between static and dynamic references. Overlays must be one of these packageIDs or they will fail.
https://gerrit.omnirom.org/13350/ - Allow aapt to override the packageID by specifying it as an argument to -x - this is needed to produce overlays that don't bork the system
Overlay best-fit hacks
https://gerrit.omnirom.org/#/c/13324/ - With standard RRO, if an overlay only has one resolution of resource, and the overlaid package has a resource that is a better fit (for example, overlay only has xxhdpi and device is xhdpi), the overlaid package's resource would get used. The end result in Layers is that some overlays would behave inconsistently on some devices. (For example, I've never seen a Layers overlay for Hangouts properly theme chat bubbles on any of my devices...)
Misc other fixes
https://gerrit.omnirom.org/#/c/13356/ - Quick settings tiles have a hardcoded AnimatedVectorDrawable class. This doesn't need to be hardcoded and can be a generic Drawable - for example, some themers want to use a RippleDrawable here. This commit is from Steve Kondik
Frequently Asked Questions
Q: What is this sytem's name?
A: To be determined. Names I've thought of so far are Light Weight Theme System (LWTS) and Phoenix (rising from the layers of ash) - I'm personally leaning towards LWTS because it's very neutral and I also hate flashy names.
Q: How is this different from AOSP/Sony RRO?
A: It is RRO with some small changes to address limitations in the current AOSP/Sony implementation, such as inability of overlays to reference their own resources.
Q: How is this different from Layers?
A: Any patch that is part of this system will go through code review with stakeholders from multiple projects invited to participate. Also, a core requirement of this system is that it does not change the behavior/look of the system when a theme is not installed.
Q: How is this different from CyanogenMod's Theme Engine?
A: While the current state of this is almost entirely cherry-picks of subcomponents of CMTE, it is only 150-200 total lines of code vs. CMTE's 13,000 in frameworks/base alone. There are some components of CMTE that we either don't want or will require too much invasive code to implement. So far one architectural difference is that like Layers, the current plan is for most of the "heavy lifting" (AAPT) to be done on a themer's PC, not on-device. Also, like Layers, this approach currently DOES support multiple overlays for a given package target. (This is most commonly used by Layers themers to change navbar icons independently of whatever other theme is installed for the rest of SystemUI)
Q: If this is intended to be a multi-ROM collaborative project, why is it in the Omni forum?
A: Most of the existing "generic" forums have a lot of clutter. One of the things I want to discuss with people is a better location for this. Same goes for the current usage of Omni's Gerrit.
Q: Needing a hacked AAPT sucks! I hate this!
A: I don't like it either. Trying to find a better solution is a work in progress.
Q: What about fonts?
A: Something I'd like to support, but not implemented yet.
Q: What about icon-packs?
A: Something I'd like to support, but not implemented yet. CM's approach depends on some of their massive architectural changes to RRO. Also, most launchers have built-in support for icon packs. (CMTE also allows a method for themes to include icon packs that will work with any launcher.)
Q: What about bootanimations?
A: Something I'd like to support, but not implemented yet. Should not be hard
Q: What about wallpapers?
A: Someone should probably work on this. I personally hated any theme that overwrote my nice wallpapers from InterfaceLIFT... So someone else will need to work on it. This NEEDS the ability for a user to disable by default.
Q: What about applying themes/overlays without reboot?
A: Unlikely, this capability of CMTE is the root of many of their massive architectural changes to RRO, and is responsible for many of the other tentacles it has throughout frameworks/base unrelated to resource lookup. Implementing this is almost guaranteed bloat.
Where are the Dialer/InCallUI resource exposure commits?
I need to take a look at these, CMTE doesn't have any - it may be that they are unnecessary when combined with the ability for overlays to self-reference resources. For example, looking at https://gerrit.omnirom.org/#/c/11674/2 there is no need to modify anything in res/drawable with CMTE or this approach, as the items in res/drawable can simply be overlaid. I have not yet looked at the other items.
Porting CMTE Themes
*Documentation on how to port a CMTE theme to the new system goes here*
More leftovers
Original leftovers is going to be the porting guide
Why not just call it Overlays Theme Engine?
skynet11 said:
Why not just call it Overlays Theme Engine?
Click to expand...
Click to collapse
Hmm, maybe... It's more likely to get confused with Layers though. It's already bad enough that so many users confuse Layers with vanilla RRO.
Just want to say 2 things:
1) Icon packs are actually possible to make, I made for "educational purpose" a port of a little part of Moonshine Icon Pack, GemFlat theme icons and some icons I personally made.
There are some advantages compared to CM: you don't have to insert app activity in any XML file, but just overlay the icon using a layer that target the app you want to theme.
2) I didn't understand well a thing about portings: do you actually mean on Layers or on this new type of theme engine?
Just a quick heads up.
Let's please read the OP before posting. If your post is not going to contribute to a technical discussion of the situation, please do not post it here. If your post mysteriously disappears with no warning, it is because such was not heeded.
Thanks.
SPAstef said:
Just want to say 2 things:
1) Icon packs are actually possible to make, I made for "educational purpose" a port of a little part of Moonshine Icon Pack, GemFlat theme icons and some icons I personally made.
There are some advantages compared to CM: you don't have to insert app activity in any XML file, but just overlay the icon using a layer that target the app you want to theme.
2) I didn't understand well a thing about portings: do you actually mean on Layers or on this new type of theme engine?
Click to expand...
Click to collapse
I believe this new way.
LiquidSmooth maintainer for d2usc/vzw & p600
SPAstef said:
Just want to say 2 things:
1) Icon packs are actually possible to make, I made for "educational purpose" a port of a little part of Moonshine Icon Pack, GemFlat theme icons and some icons I personally made.
There are some advantages compared to CM: you don't have to insert app activity in any XML file, but just overlay the icon using a layer that target the app you want to theme.
2) I didn't understand well a thing about portings: do you actually mean on Layers or on this new type of theme engine?
Click to expand...
Click to collapse
1) Well, right now, icon packs can be loaded by launchers that are "icon pack" aware. CMTE allows any launcher to load an icon pack from the theme itself by altering the icon resource of the app itself. Right now "system icon packs" are pretty low priority since MOST popular launchers support loading icon packs themselves, unless someone can state a good use case for them other than "supports any launcher".
2) Since CMTE is the most common theming system with a LOT of themers behind it, it's ideal to try and make the transition from CMTE to any other system as painless as possible for a themer. A theme engine without themes is pretty useless. Layers attracted a lot of themers unhappy with CMTE mainly due to how Cyngn ran some of their theme contests, but many of those themers were still supporting CMTE. If you want someone to support more than one theme engine, and you're NOT the biggest one out there, you've got to make their life as easy as possible. (Strangely, one member of the Layers team said that everything he did was "for the themers" - but the majority of what he did made things harder for themers AND ROM developers, especially themers coming from CMTE.)
Also, just one request to moderators: Try to go light on the moderation unless things go bad. It's a long story, but one of my issues with the Layers team was going overboard on the moderation. That said, the post deleted was just a link to the Layers community with no other comments other than saying "don't reply to me"...
Entropy512 said:
1) Well, right now, icon packs can be loaded by launchers that are "icon pack" aware. CMTE allows any launcher to load an icon pack from the theme itself by altering the icon resource of the app itself. Right now "system icon packs" are pretty low priority since MOST popular launchers support loading icon packs themselves, unless someone can state a good use case for them other than "supports any launcher".
2) Since CMTE is the most common theming system with a LOT of themers behind it, it's ideal to try and make the transition from CMTE to any other system as painless as possible for a themer. A theme engine without themes is pretty useless. Layers attracted a lot of themers unhappy with CMTE mainly due to how Cyngn ran some of their theme contests, but many of those themers were still supporting CMTE. If you want someone to support more than one theme engine, and you're NOT the biggest one out there, you've got to make their life as easy as possible. (Strangely, one member of the Layers team said that everything he did was "for the themers" - but the majority of what he did made things harder for themers AND ROM developers, especially themers coming from CMTE.)
Also, just one request to moderators: Try to go light on the moderation unless things go bad. It's a long story, but one of my issues with the Layers team was going overboard on the moderation. That said, the post deleted was just a link to the Layers community with no other comments other than saying "don't reply to me"...
Click to expand...
Click to collapse
I am a themer of both CM and Layers. Now, CM has many features that Layers hasn't (such as fonts, wallpapers, boot animations...) But talking about app themes only I like very much more Layers because of exposed colors. In new "Layers 2.1" various errors that have been made during first exposing were fixed (as did @atl4ntis alone in his ROM), and you don't have to struggle with styles.xml for most of the things (so it's more noob friendly). Obviously there have been many situations where I missed thee possibility to link something to something other in the overlay.
So I think that layers isn't confusing very much. I found more confusing cm. I think that someone who never made themes would prefer layers to cmte. This is my opinion BTW
SPAstef said:
I am a themer of both CM and Layers. Now, CM has many features that Layers hasn't (such as fonts, wallpapers, boot animations...) But talking about app themes only I like very much more Layers because of exposed colors. In new "Layers 2.1" various errors that have been made during first exposing were fixed (as did @atl4ntis alone in his ROM), and you don't have to struggle with styles.xml for most of the things (so it's more noob friendly). Obviously there have been many situations where I missed thee possibility to link something to something other in the overlay.
So I think that layers isn't confusing very much. I found more confusing cm. I think that someone who never made themes would prefer layers to cmte. This is my opinion BTW
Click to expand...
Click to collapse
I think the whole thing about whether is easy or hard can easily be fixed by creating templates just like in the CMTE where a "noob" can just git clone that and start off with that.......
If the template is done right with comments and all, it shouldn't be an issue. Then you have support threads which can be made after things are set and done where people can help each other and get things going.
Nothing is ever going to be "noob proof". Just take a look around at all the guides and everything for the most simple things. As easy as it is to flash a ROM, there's actually videos and guides for that and people STILL find themselves with that deer in the headlight look
SPAstef said:
I am a themer of both CM and Layers. Now, CM has many features that Layers hasn't (such as fonts, wallpapers, boot animations...) But talking about app themes only I like very much more Layers because of exposed colors. In new "Layers 2.1" various errors that have been made during first exposing were fixed (as did @atl4ntis alone in his ROM), and you don't have to struggle with styles.xml for most of the things (so it's more noob friendly). Obviously there have been many situations where I missed thee possibility to link something to something other in the overlay.
So I think that layers isn't confusing very much. I found more confusing cm. I think that someone who never made themes would prefer layers to cmte. This is my opinion BTW
Click to expand...
Click to collapse
Well, CMTE exposes colors too - can you provide a specific example of something that was easier in Layers than CMTE due to not being exposed?
I'm guessing probably something in Dialer or InCallUI, since the resource exposure commits in the rest of CMTE are pretty similar to Layers with a few exceptions. I'm willing to consider some "laziness commits" that expose resources as long as they don't conflict with existing ways of doing things.
Other themers I've spoken to preferred CMTE over Layers by a long shot. I think the learning curve of Layers for basic theming might be a bit shorter, however CMTE allows a themer to do much more. I've seen piles of things in Mono, Coalfield, and FlatshadeUI that would be an utter nightmare to do on Layers, if even possible. (As evidenced by the fact that some guy has been trying to port Coalfield to Layers for 2-3 weeks now - I had Coalfield working about 20-30 minutes after I started working on getting it to work with the new system.)
I looked into these fixes you claim they made... They're the fixes I fought for two months to get people to agree on, it appears that after I gave up and said "I've had enough", they squashed the fixup commits into the original ones and changed authorship (In addition to removing the post with my proposal from their community). For reference - the original fixup commits that I put forward for Layers 2.1 are at https://gerrit.omnirom.org/#/q/status:open+topic:rro2p1 and were originally written in late February. Similarly, any CMTE resource naming convention compatibility in Layers was proposed by myself for Layers 3 (WIP at https://gerrit.omnirom.org/#/c/12323/2) and rejected along with the Layers 2.1 fixes - it appears they pulled THIS in too and called the whole thing 2.1. (You'd think that a naming convention change would merit a major version number bump...)
Mazda said:
I think the whole thing about whether is easy or hard can easily be fixed by creating templates just like in the CMTE where a "noob" can just git clone that and start off with that.......
If the template is done right with comments and all, it shouldn't be an issue. Then you have support threads which can be made after things are set and done where people can help each other and get things going.
Nothing is ever going to be "noob proof". Just take a look around at all the guides and everything for the most simple things. As easy as it is to flash a ROM, there's actually videos and guides for that and people STILL find themselves with that deer in the headlight look
Click to expand...
Click to collapse
One thing I want to do is to try and write some convenience tools for themers... This may be necessary to handle the "common" nightmare as I might need to preprocess "common" resources.
Of course, there are a lot of tradeoffs here... Sometimes making things TOO easy prompts a flood of some really awful stuff. Theme DIY was a great idea but it's led to a bunch of really horrible paid themes on the Play Store (despite the TDIY author stating that the tool was not to be used for paid themes), making people more reluctant to actually buy paid themes that ARE good.
Which is why I'm still torn on one feature of CMTE that handles cases where an overlay has an incomplete style that is missing attributes - Now, this makes a themer's life easier, but in general, the themes where lack of this feature has been a problem were ones of poor quality... One of the stated reasons for the patch was handling cases where an app updated causing the overlay to crash. The problem in this case is that it's better for something to be obviously wrong than for it to fail in subtle weird ways. Look at Facebook for example - at some point they made a MASSIVE overhaul of their styles. Some themes overlaid the "old" styles - as a result of the changes, they crashed with this engine, but caused strange graphical glitches in CMTE. (In fact, I need to check, but I think one themer removed all of his style overlays for Facebook from a theme because of this - at least he was considering it.)
I want to make themer's lives easier BUT I also don't want to encourage bad practices... There are some tough tradeoffs here.
I agree with you.
If also users with no theming capacity starts making paid themes this will be a pain for good themers.
Another question, do you have any ETA to complete this? (Or at least first points)
SPAstef said:
I agree with you.
If also users with no theming capacity starts making paid themes this will be a pain for good themers.
Another question, do you have any ETA to complete this? (Or at least first points)
Click to expand...
Click to collapse
As far as ETAs - there are a lot of unknowns here. Also, I need to finish up some core Omni stuff that I let slide for... WAY too long because I was spending time on theming and Layers. There's a gigantic CAF ifdef effort I need to finish so we can start nightlies.
Also, if I recall correctly, you were working with the guy behind Carbon UI? (Elixium Dark is the Layers form of Carbon UI???) - https://play.google.com/store/apps/details?id=com.zyxxeil.carbon.ui
That was a pretty easy port since he only used common for some of the keyboard drawables.
MilosUI took about ten minutes (mostly, again, handling "common" in the keyboard).
I think I'm gonna pop back over to FlatshadeUI for a while though.
Entropy512 said:
As far as ETAs - there are a lot of unknowns here. Also, I need to finish up some core Omni stuff that I let slide for... WAY too long because I was spending time on theming and Layers. There's a gigantic CAF ifdef effort I need to finish so we can start nightlies.
Also, if I recall correctly, you were working with the guy behind Carbon UI? (Elixium Dark is the Layers form of Carbon UI???) - https://play.google.com/store/apps/details?id=com.zyxxeil.carbon.ui
That was a pretty easy port since he only used common for some of the keyboard drawables.
MilosUI took about ten minutes (mostly, again, handling "common" in the keyboard).
I think I'm gonna pop back over to FlatshadeUI for a while though.
Click to expand...
Click to collapse
I didn't port it. We did it together (actually Elixium Dark was out 2 weeks before Carbon), so there was no problems into porting, because they are 2 different themes. With that project we showed that it's possible to make very good themes with both CM and Layers.
Milos is a port (but with some changes), yeah it was quite quick to port it.
Mainly the "hard work" is with common and with framework, systemUI and settings, as they are quite different to theme between the 2 platforms
I look forward to adding this to my comparison between Layers and the CyanogenMod Theme Engine when I publish it
Hey, guys! I'm here with another tool that basically opens for edit, all the framework-res bools. This allows toggling on and off a few core system features that could actually pay off. Read on to know a few of those cool features that you could edit with just a few taps and no complex CLIs!
What's Zenith?
The framework-res holds most of our core system settings which are referred to in most system as well as user-grade apps. As such, these settings aren't open for editing and for a few of 'em it's over mediocre in difficulty. Well, Zenith is the merger and this simple tool could unlock a couple of cool features that you didn't even know are up on your phone. It could even turn out to be the game changer for a few who're considering a phone upgrade!
What can it do?
Consider the bool, config_allowAllRotations. By default on most stock / vanilla Android devices, device rotation is restricted to just 3 orientations. In short, you don't get a reverse portrait (held upside down) or in some cases even a reverse landscape. The above-stated bool which by default is set to false when toggled unlocks this feature which could potentially turn out to be quite nifty to a few geeks out there at least. That's just one out of a pool of features that you could go explore! The configs right now are difficult to apprehend by the layman but a hair of logical reasoning might come in handy. A Google search would yield you nothing but a redirect to the AOSP archives on their git! Documentation support for each of the bools is on its way and let me tell you, it's community driven so hope you'd contribute! :good::laugh:
Is it buggy?
Follow the instructions built into a ReadMe option on the executable without which you might just shoot in the dark. And yeah I don't see any bugs as of now, let me know if you find any.
Cool, where do I find Zenith?
Right here! Check out the attached ZIP.
Not really, yet call it a BETA since it lacks an edge right now but let me know if any more features can be added. Thanks!
theGeekyLad said:
Hey, guys! I'm here with another tool that basically opens for edit, all the framework-res bools. This allows toggling on and off a few core system features that could actually pay off. Read on to know a few of those cool features that you could edit with just a few taps and no complex CLIs!
What's Zenith?
The framework-res holds most of our core system settings which are referred to in most system as well as user-grade apps. As such, these settings aren't open for editing and for a few of 'em it's over mediocre in difficulty. Well, Zenith is the merger and this simple tool could unlock a couple of cool features that you didn't even know are up on your phone. It could even turn out to be the game changer for a few who're considering a phone upgrade!
What can it do?
Consider the bool, config_allowAllRotations. By default on most stock / vanilla Android devices, device rotation is restricted to just 3 orientations. In short, you don't get a reverse portrait (held upside down) or in some cases even a reverse landscape. The above-stated bool which by default is set to false when toggled unlocks this feature which could potentially turn out to be quite nifty to a few geeks out there at least. That's just one out of a pool of features that you could go explore! The configs right now are difficult to apprehend by the layman but a hair of logical reasoning might come in handy. A Google search would yield you nothing but a redirect to the AOSP archives on their git! Documentation support for each of the bools is on its way and let me tell you, it's community driven so hope you'd contribute! :good::laugh:
Is it buggy?
Follow the instructions built into a ReadMe option on the executable without which you might just shoot in the dark. And yeah I don't see any bugs as of now, let me know if you find any.
Cool, where do I find Zenith?
Right here! Check out the attached ZIP.
Not really, yet call it a BETA since it lacks an edge right now but let me know if any more features can be added. Thanks!
Click to expand...
Click to collapse
Hi,
This looks interesting!
But since it's about frameworks, maybe you should mention whether they should or not be deodexed!
Nonta72 said:
Hi,
This looks interesting!
But since it's about frameworks, maybe you should mention whether they should or not be deodexed!
Click to expand...
Click to collapse
Hey Nonta72! Sorry for the not mentioning that, but it works regardless of whether the frameworks are deodexed or not. Just plays around with the XMLs! Thanks!
theGeekyLad said:
Hey Nonta72! Sorry for the not mentioning that, but it works regardless of whether the frameworks are deodexed or not. Just plays around with the XMLs! Thanks!
Click to expand...
Click to collapse
Nice, thanks!
I would like to hire the right developer for a personal project.
I absolutely dislike white statusbar icons. Most, if not all substratum
themes do not touch the status bar icon color, some use overlays to
change the background though. There is a substratum overlay for wifi icons but this seems overly
complex for such a simple icon swap, and there have been changes made by google
to prevent the signal icon from being changed, at least according to the developer.
In earlier versions of Android, SystemUI.apk could be extracted along with framework-res,apk, and the
resources swapped for icons of my choosing. I am going with an AOSP rom
based on Nougat (AICP, or Resurrection). I am not working with Sense roms. My understanding is that Oreo further limited
the ability to change statusbar icons, that would be my reason for going
with Nougat. I would rather stay with an Oreo build of AICP but that is not a must.
If you are interested, I would like an estimate of the time it would
take you to:
1. Tell me which files to pull and send to you
2. Determine where the resources and/or code must be decompiled/edited to make this
work, that is, signal, wifi, other icons of my choosing. I can provide the icon files.
3. Send me the edited files
4. I will test
5. Work with me to handle the bugs
6. Once we have a working setup, draft an outline of what you did which
would enable me to decompile/edit the appropriate apks or files so I can
do this myself later with different icons.
A bit about me:
I am tech savvy, familiar with the linux command line, adb, etc.
I am working with AOSP roms on a HTC M9. Rooted, S-OFF, it is a GSM
variant (himaul). But I am not a software developer.
I am not looking for an app to do this for me. But I am seeking out the expertise
to reverse engineer what I need to make this happen and do it manually.
In my hours of pouring over xda I read somewhere the inability to choose
the icons is a google policy. I can't stand the modern UI white, washed
out colors but themeing can take care of most of that. In case you ask,
I'm currently on 4.3 on a HTC M7 from 2014 and I have got to get going with a newer
device.
I realize your time is valuable and this will not be a trivial task (or expense)....I only ask you to reply having enough familiarity to dive in without too much OJT.
Please do include your hourly rate. I would have no problem if this work is made GPL and free to post here, if you like.
Thanks!!