If that’s indeed the case, I am surprised that you managed to figure this out and not these people. What are they thinking?!
There are some issues in WFS (how WFS creates watchface.xml). Declarative xml is going through Validation and when there is some issue, it throws errors or memory exceeding messages. Watch face will then not pass the review.
The Bug will be (maybe already was) rised against WFS soon. It was only discovered today while testing the WFF dial.
Maybe when it’s fixed, it will solve some of the memory usage issues.
3 Likes
I hope so, I have two watchfaces literally stuck in a limbo of submissions and rejections. They’re both not crucial, fortunately.
Edit: 18 rejections and counting…
Edit2: after countless rejections, 30 I believe, I gave up. I just need to update a watchface, exactly as it is, to a new WFS version, and this, at this time, is not possible unless the face is basically a joke in term of resources, animations and customization.
1 Like
Sorry for the double post, but I have more info to add separately from the previous. I went ahead and did some appeals, and I noticed a couple of interesting things:
- The appeal was for a new watch face containing 5 complications and a single 25 frames animation. The result was (of course) app still rejected and they wrote this
- The second appeal was for the same watch face, but i shortened the animation and removed a complication. App still rejected and this is the memory consumption this time
- Third appeal, and that’s the answer this time:
Thoughts:
- Why in the world, if I removed a complication and frames from the animation, the “memory footprint” in active mode has increased??
- I can’t stand the fact that I asked them how to check this memory footprint by myself before releasing and they replied with a prewritten useless answer every single time
- They are still not alingned, someone still checks for 10MB instead of 100.
- Basically, if I want to update a watch face using the latest WFS, I have to simplify the watch face A LOT. And this, we all know that, means bad reviews
2 Likes
I’ve seen AWF publish watchfaces with a lot of complications filling up the screen.
They’re passing the verifications
It leads me to guess that something is wrong with the latest WFS software in how they build the watchfaces into the Watch Face Format. When you use Android Studio to make the editing yourself, things seem to be working, f6ir the most part.
Problem is most probably with animations. I’m not using any.
I see huge problems in the decision to shift to Watch Face Format.
-
WFS will be very limited in terms of new features. We can already remove like 85% of WFS feature requests .
-
DWF (where on Wear OS 4, our watch faces are running) is a system app which is not available on Google Play. That means updates will only come when watch software is updated. Now imagine you have 100 watch faces created in WFS 1.4.20 / 1.5.7 and Samsung releases software update where their DWF is bugged. Immediately, all watch faces won’t be working and there is nothing you can do to fix it, just need to wait for another software update which will come in months rather than weeks.
There are also multiple DWF versions, each manufactures has its own (com.samsung.wear.watchface.runtime, com.google.wear.watchface.runtime) -
Resources and watchface.xml are not obfuscated, you can just go and steal full watch face design → No protection. (That’s why integrity protection is not working for WFS watch faces published with 1.4.20+)
Edit: maybe I’m wrong and DWF update can come not only within firmware update. 2nd point is only hypothetical.
6 Likes
Thanks @amoledwatchfaces for sharing your thoughts.
These are very critical aspects.
It would be great if a representative from the Samsung WFS team could give us more clarification on this side.
Please let us know what we should expect in the next few months or if we should close this business.
@sinjae @catherina00 @r.liechty_SDR
Thanks !
4 Likes
I have personally stopped making watchfaces for the time being, as it has become too unsustainable due to this massive and critical issue.
1 Like
This memory issue and the limitation of of 10 MB AOD and 100 MB active would have been somewhat fine and workable, if we had any way to check the memory footprint while building watch faces in WFS - which we don’t!
The way things are now is ridiculous and highly frustrating.
Going only through trial and error will get us nowhere, it’s such a clumsy and demotivating process. Not to mention “fighting” with uneducated Google Play reviewers.
I’m also reluctant to release any new watch faces because of this, even with the “stable” WFS 1.3.13.
Got multiple designs on the waiting list for over a month, while still hoping for a concrete fix from Google or Samsung, or both.
This issue needs to be taken seriously and fixed ASAP.
2 Likes
I back to WFS 1.3.13 after facing too many problems. Why you do not use it? I’m asking because after your message I got some suspicion that I’m missing some problem with V 1.3.13.
I use it, since it’s the only usable version which doesn’t seem to face memory issues (yet) when uploading to Play Store, that’s a positive side of 1.3.13.
However, random rejections due to “split bundle” (and other unusual reasons from Google Play reviewers) still seem relatively common, regardless of WFS version.
Another thing to note, which is a negative side of using 1.3.13, is that it doesn’t fully support Wear OS 4 and all its features - specifically the deeper integration with health app for seamless heart rate measurement and steps (which have their own issues right now as well, but that’s a separate issue on its own).
Building and uploading with 1.3.13 is okay for now (most users are still used to tap-to-measure BPM and such), but it’s not a long-term solution as it’s just a matter of time until this version becomes obsolete and unsupported, and we’re forced to upgrade all our work with some of the newer versions.
I’m truly hoping we’ll get a new and improved WFS version before that happens, which resolves or minimizes at least some of the current issues (memory budget issue, steps update issues, constant heart rate measurement issue, animation stutter).
2 Likes
@Persona , as @enkei_design wrote, I currently only use WFS 1.3.13 (with some limitations for Wear OS4) due to the countless memory issues that everyone knows about.
However, I am aware that it is only a temporary fix and sooner or later we will be forced to use the new WFS especially due to the minimum SDK version that Google will impose at 33 also for watch faces in a few months.
@amoledwatchfaces 's post has me further worried, especially in the part of future Watch Faces updates.
This is the reason we need to know what to expect in the coming months. We too have a family and we need to know what to plan for our future.
3 Likes
True but with also the biggest problem is that we cannot update (degrade) watch faces that have been downloaded several times in the last 2 years without “dismembering” them into their features, although we will have a function to monitor the memory budget in AOD mode. It makes no sense.
Users would be pissed and they would be right.
Google (and Samsung) should understand this side and give a smart solution.
They cannot think of fixing their issues of software resources, battery drain (etc), simply by limiting the features of the watch faces.
3 Likes
I’m just glad I’m not alone in this situation.
Another example: I have a watch face with a step goal bar, and I receive a lot of emails asking why it has a fixed step goal. Imagine having to explain that I have a version of the app which perfectly supports the step goal sync on Wear OS 4 currently running on my watch, but I tried to publish it for 2 months straight without success. Someone told me I was lying and I can’t blame them for thinking that.
And, given the current situation, I have watch faces I can’t literally migrate on WFS 1.4+ because they have multiple animations and dozens of customization options.
All we need is a better Google + Samsung cooperation. The watch face market is not that small and WFS should be the official and only tool to develop a watch face, imho.
1 Like
There is some misunderstanding in this thread.
Fundamentally the Resources and the code to render the Watch Face are separate this allows (I assume Google Play Services) to update the Watch Face rendering code without the need for the developer/designer to update Watch Face studio for system updates or other changes.
Please read the Google IO 23 blog it was not Samsung nor Watch Face Studio that changed the Watch Face Format it was a joint effort. The speaker for the changes was one that worked with Google for the new WFF.
See the SDC 23 video about Watch Face Format starting at about 3:50 in the presentation.
So basically the only reason to update to the new WFS version is for feature request it does not make them unimportant.
The resources are now separate from the Watch Face Rendering Code so this appears it is indeed something that the designer or developer can control but there may be something that WFS should optimize.
I’m not saying anyone is wrong but I think you all need to view the video read the blog and see if this is a step in the right direction or if like the people that thought displaying continuous heart rate were just blaming the first thing they noticed.
Ron
Samsung Developer Relations
Hi possible to try adb command on the watch face. Havnt tried it but read there is a dumpsys meminfo command
I understand and I don’t mean to criticize Samsung. I’m just saying that this “joint effort” can’t be over, because there are many problems that can’t be ignored. If you saw my above post, it seems like the “memory footprint” thing is unpredictable and still is an endless trial and error, for example.
The idea behind the new format is clever, I was really excited when Google announced it, but it must offer a similar or better experience, compared to the previous version, both to the developers and to the users. This, at the moment, is not true. That’s all, but like I said many times, I’m super grateful to Samsung for developing WFS and offering it for free to the designers/developers, this is undoubtful! 
- not obfuscated, easy to steal → correct me if I’m wrong but I can go, download @Matteo_Dini watch face, extract res folder, and I have full watch face ready for publishing. Hopefully this will be improved in the future.
WFS also currently produces wrong watchface.xml code which is not passing validator. Wait for the next version which is to be released next year will be hard.
This, I’m not sure about. DWF is a system app, nowhere to find on Google Play. It would be great it DWF was updatable via Play Services. I’ll try to find more info about this.
Thing is that now, new features must be added directly to WFF before being implemented in WFS. A lot of old features request are not achievable with the current WFF – WFS combo.
4 Likes
I’m intrigued by this comment. Is this the root of the ‘memory budget exceeded’ problem? I have a load of watchfaces all rebuilt with the latest WFS and all rejected for this reason.
If this is the root cause, then surely Samsung could conceivably produce an interim patch that fixes this critical issue and reduces the frustration for this community, the load on Google reviewers and the bottleneck in development.
@r.liechty_SDR could you provide Samsung’s latest position on this issue?
Hi. Just to add, I’m not sure if this is 100% related to memory budget issue. I just know that watchface.xml produced by WFS is in bad format and is currently not suitable for DWF. My latest updates made in WFS 1.5.7 are passing reviews so I think WFS made watch faces are reviewed differently than pure Watch Face Format watch faces.