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
This is simply the sequel to my last launcher project, Sapphire Launcher. I started this project last August and began the beta in June of this year. So, Instead of boring you with a story of how I started and what an android launcher is, I will start with what is important to know before you post any comments.
Sapphyx Launcher is not intended to be another Pixel based Launcher. I provide the settings needed to transform the launcher from the "Pixel" interface back to the original launcherinterface. I am not a code junky, this is a learning project for me to learn how to properly use Google Services, Firebase, Analytics, Communicate properly with the user base and community on Google Plus, learn android from within the launcher application and provide cool customization options to your android device. Sapphyx is for Android 6.0 and above because of the code structure I use and the performance I promise.
Sapphyx Launcher is my vision of what I would call an original launcher. Its the kind of experience that slaps you in the face alittle bit to get you thinking why havn't other developers taken up such originality in their homescreen replacement projects. Like my old custom roms (Bionx Roms), i promise a unique experience and a very good customer feedback appreciation program. The launcher, like many other custom launchers, offer customization to pretty much everything. Label text size and color, grid options, toggling views and menus, unique navigation from point A to point B, material user interface, Context Pages, Gestures, Notification bubbles and more! Sapphyx Launcher has been called the ADW of its time as it brings back memories of my current users of the original ADW launcher from gingerbread with the amount of options that are offered. In Sapphyx Launcher, I offer a unique and exclusive feature called Context Pages (Now available in the latest beta) which are my replacement of a swipe to left add on. These pages offer different tools, features and shortcuts to daily tasked completed by the user. Sapphyx Launcher is a premium application and requires a license to use some of the advanced options. I also offer free license to users on certain occasions. Sapphyx Launcher is fully optimized for 64bit environment and Snapdragon chipsets.
MAIN FEATURES (Based on latest beta release)
-Transitional Themeing
-Notification Bubbles
-Homescreen Customization
-Dock Preferences
-Folder Preferences
-Unique Launcher Drawer with toolbar
-Context Pages (With Chooser)
-Unique Wallpaper manager
-Powerful Launcher Settings
-Google Services and Firebase
-Fabric Error Reporting
And more...
If a Licensed is missing, its because I am still testing the code and determining if its reliable for my project. I have no intentions to add Google Now or Oreo features. I may create my own implementation of something similar going forward if requested.
I urge you to join the Google Plus Group as that is my home and where I will be posting majority of what I am working on and previews and also you can sign up from for beta build releases.
Google Play Link
Google Plus Group
XDA Labs Link: https://labs.xda-developers.com/store/app/com.gsd.launcher.sapphyx
XDA:DevDB Information
Sapphyx Launcher, App for all devices (see above for details)
Contributors
Nx Biotic
Version Information
Status: Stable
Current Version: 1.00.20
Beta Release Date: 2017-08-16
Created 2017-08-18
Last Updated 2017-08-18
Rollouts/Updates
Sapphyx Launcher will be distributed in 3 ways. On Google Play, users have a choice of the stable channel and beta channel. The stable channel will distribute builds that are dependable, less buggy and user friendly. Beta builds will have experimental settings, have relatively new features readying for the stable channel and is open.
Xda Labs will feature dev preview builds in the Alpha Channel, mirrored beta versions and stable versions.
The Google Play Rating system for beta builds point users to this forum.
Ratings
I take the rating system seriously. If you abuse the system you will be pointed out or ignored. If you call out a user or developer, i will call you out publicly. Rate the application based on its performance, its features and reliability. Not what you think it should be or what you want it to be. Do not demand features.
License
I may not include license to a 3rd party resource if i am testing it or its relatively new. A license will be included if its solid and dependable and plan to be kept in the project.
#first!! Excellent launcher bro!!
Hoping to have the final beta update out before the end of August. After that, the next update after that will begin locking features and settings and users will be required to purchase either my premium or onyx license key (no difference except value and support). A handful of features will stay unlocked like icon editing and icon pack support.
Is there a way not to use the extended homescreen. I am not able to go back to homescreen when i am on another screen without opening that ****in extended screen
Gesendet von meinem SM-G935F mit Tapatalk
js45721 said:
Is there a way not to use the extended homescreen. I am not able to go back to homescreen when i am on another screen without opening that ****in extended screen
Gesendet von meinem SM-G935F mit Tapatalk
Click to expand...
Click to collapse
I am currently working on a way to lock it out for users who don't like the intentions of it. Its based on a Drawer layout thus the launcher layout is placed inside of it so its not something i can just disable with a view toggle. I have to find a way to lock the drawer from being accessed. Right now, its i provided an enforced lock toggle. Yes, this is a priority im working on.
This actually looks really good, seems to fix the handful of things that bother me about the pixel launcher.ill give it a shot for a few days and see how it does on my s8(TouchWiz is ehh), I'll be sure to post any bugs I find to the g+ group
huffmybrd said:
This actually looks really good, seems to fix the handful of things that bother me about the pixel launcher.ill give it a shot for a few days and see how it does on my s8(TouchWiz is ehh), I'll be sure to post any bugs I find to the g+ group
Click to expand...
Click to collapse
Very much appreciated. I like to tell users they don't have to keep Sapphyx installed, i care more about what they noticed or found that could be wrong.
Pushed out an update today to the following apps in regards to Sapphyx Launcher.
GSD Premium license now adds a Time Page module for Static Pages (Simple Widget, may add more to it later).
Sapphyx SideDrawer now listens to Drawer Background Color and Column Count shared preferences.
Getting ready to release the API for devs to mess around with as well as adding Shared Preferences inside Sapphyx Launcher settings they will have access to. For example: Static Pages background color.
Happy weekend everyone.
Update 1.00.25 available on playstore, xda labs coming soon.
woow seems very promising launcher!
can you implement a static page that have same feature of oneplus shelf or arrow launcher? i hate google now page on the left, and i would love a scrollable page where i can add my widget and app shortcut!
Hope this can be a added soon1
okaiuz said:
woow seems very promising launcher!
can you implement a static page that have same feature of oneplus shelf or arrow launcher? i hate google now page on the left, and i would love a scrollable page where i can add my widget and app shortcut!
Hope this can be a added soon1
Click to expand...
Click to collapse
I already have plans to develop a page similar to Shelf. If I don't get to it, another dev will be able to soon as I will be releasing the API soon todo so. Im just not their yet to be satisfied with public usage.
I felt the same while developing this launcher, i wanted the same concept just another package or feature.
Nx Biotic said:
I already have plans to develop a page similar to Shelf. If I don't get to it, another dev will be able to soon as I will be releasing the API soon todo so. Im just not their yet to be satisfied with public usage.
I felt the same while developing this launcher, i wanted the same concept just another package or feature.
Click to expand...
Click to collapse
great work man!
I started working on publishing the Sapphyx Launcher API on github. Repository is live but the tutorial and setup isn't finished yet, been busy.
If you have any interest in it, feel free to star it. Github account can be accessed in the launcher about information. Il have some things documented above in OP when everything on github is finalized.
API is live on my github. I will be publishing some of my pages on my Github for examples.
The next update will be official release anf as a reminder will be locking all premium settings and requiring a key to unlock.
As apart of the update, Im compiling on Android Oreo which has broken a few things and improved performance so Im in the middle of a massive rework right now. The Extended homescreen is more aggressive now, making it feel more like a drawer than a extra page on your homescreen. This makes it less visible for users to notice if you do not want to use it vs users who will be using it. A large number of Force Closes have been patched. Ive gone through the launcher settings and moved a few things around while revamping a few views (Like the Avatar bottom menu).
Il be focusing on more user requests near release so keep the logs and requests and feedback coming.
A new feature im currently working on for Sapphyx Launcher. Kinda like a mock of the One plus Shelf.
Nx Biotic said:
A new feature im currently working on for Sapphyx Launcher. Kinda like a mock of the One plus Shelf.
Click to expand...
Click to collapse
looks lit man !
cant wait
Another look at the redesigned Left and Right Panes in Sapphyx Launcher's new update currently in development.
Static Pages now have an indicator to indicate which page you are on and how far left you are. Above the container is now a Google Now search widget which solves the delima of Now on left as clicking on it opens Google Now in that view. (I could add the Companion code from lawnchair but i really don't want to copy from them)
The Smart Pane has pretty much a final design. Just lacking its features at the moment. Currently looking at some options users could benefit from if they choose to use this feature for a cleaner homescreen setup.
This new update is planned for the end of September or beginning of October. I have a few things i want to touch up as far as existing tweaks, revamp the UX for the launcher settings, fix a few straggling bugs in a few tweaks and finalize the new Smart Pane and lock all premium settings.
A project update for xda followers.
I plan on doing a dev preview as an alpha build on xda labs soon. This build would be labled as an Alpha build and be a preview of the fall update. I hope to have this live next week. If you use this build, I expect feeeback. I will announce when it goes live.
I recently just switched to the newest Android Studio 3 beta and updated the launcher to compile on Oreo. The result was a massive amount of broken activities and actions because of new behavior and deprecated code and rules in Oreo. I have been working hard to fix everything and patch anything in need and remove anything that was completely broken. The result was a faster launcher but their is some weird behavior still and we're trying to locate the bugs and fix them (For example the drawer hangs or gets stuck as you swipe up from the dock)
I have been finishing up what I need to for a few new features, one of them being Sleeve. Sleeve is my representation of the One Plus Shelf feature. Altho it isn't 100% complete yet, I want users to get to try it and here from them what All could go in this hidden home screen. This screen is summoned via a gesture or launcher action.
A great amount of the launcher and interface has been rewritten to be more user friendly and easier to use as well as make that first impressions on many. The launcher settings has been re organized, a new long click listener was added to the carrot indicator. A few fixes to icon pack helper for Oreo and patches to pre existing tweaks so they behave correctly.
Be sure to follow the google plus group for more info and previews and to share your feedback and requests easier.
Dev preview builds are available on xda labs. Please select Alpha channel.
https://labs.xda-developers.com/store/app/com.gsd.launcher.sapphyx
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!!