Watch face exceeds memory usage: let's clarify

image

  • 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.

The last I knew WFS team was in talks with the WFF team or at least the Samsung people that are on that team.

Ron
Samsung Developer Relations

So, out of interest, what are you doing differently, if anything, in WFS to get your watchfaces approved without the memory budget issue?

My last design made with 1.5.7 was removed from all of the watch face lists on Google Play. It also has a problem says “Watch face is not compatible with the watch”

When I redesigned with 1.3.13 the problem was solved.

Not using animations, optimizing images. Also, I’m not using many images. Just creating lightweight watch faces.

1 Like

2 small news:

  1. I have one of my watch faces stuck in the rejection loop for the ambient mode (17MB) and I tried hiding almost everything in ambient mode. Nevertheless, it still gets rejected and has the same memory footprint in AOD. If a layer is hidden in AOD, it shouldn’t exist in this mode, right? Well, if this is true, I can’t explain why the memory footprint is still that high.
  2. I took a look at the files of my watch face and i noticed a possible improvement: if I use the same png in 2 different layers, it gets duplicated in the res folder, even if it’s the same exact resource. In my case, I have a png used 5 times! And there are 5 copies of it. Also, there are 2 unused png with the preview of an unknown watch face in the nodpi folder. Another great feature, but I’m quite offtopic here, would be a pngquant based optimizer embedded in the build process. Not everyone knows how to optimize a png, and even that it’s necessary.

I resubmitted the watch face after manually modifying the json and the resources folder to optimize it even further. But I have no doubt that Google will reject it again :slight_smile:

I realized the same thing but I could not find any way to modify the watch face file.
I changed the file name from …abb to … zip
opened with zip application
deleted unused PNG file
created .zip file
changed file name from …zip to …abb
This has not worked for me.

Could you tell us what to do?

Just a question about exceeding memory budget. We supposed to just keep within the 100mb/10mb thresholds for active and AOD face to get our faces passed, yeah? I would like to know if there is a tool, or a way to confirm if a face stacks up to that threshold? Or…are we just supposed to close our eyes and hope for the best?

1 Like

@rzrshrpstudio How are you determining the AOD memory usage for your watchface? I assume you’re using the adb tool and perhaps using dumpsys, but it would be most helpful if you could explain what you do to determine AOD mode usage?

Thanks,

Rob

@rob1585568856 you won’t like the answer: I submit the app and I appeal the rejections every single time. That’s the only way to know the memory footprint, if you’re lucky. And no, the watch face wasn’t accepted even after optimizing everything again. I would literally pay to have better support and tools to measure the memory footprint by myself.

Ah, right. I do the same thing, but have never managed to get any further information out of the reviewer. They always say " As much as I’d like to help, I’m not able to provide any more detail or a better answer to your question." Sigh!

1 Like

@MergeLabs @rob1585568856 @rzrshrpstudio @Persona

Please add your comments to this thread that way we can present a cohesive response to Play Store.

Regarding tools to measure since it is not the abb size but the runtime size of the watch Faces.

Someone posted here that the Pixel watch when you select apps will tell the functional size of the memory space. This is not available in the Android testing emulators.

We have asked the WFS team to add something like the OPR testing to WFS watch faces and they are looking if this is possible.

In addition WFS team is also trying to work with Play Store for better guidelines or loosen restrictions.

Again post in the other topic please.

Ron
Samsung Developer Relations

1 Like

Hello,

With regards tooling for checking the memory usage of Watch Face Format watch faces, please take a look here:

Here you can find the memory checker tool which is the same as is used in Play reviews, and an example of how to use it.

Many thanks

3 Likes

I don’t think the memory footprint is an issue any longer except for Ambient Mode (AOD). I heard the review team improved the algorithm. I wonder if it is this memory foot print evaluator in GitHub it appears to be about the same time frame.

Ron
Samsung Developer Relations

It’s still a problem, at least for me. I had to give up on porting some of my watch faces to the latest WFS. 90% of the rejections were for memory footprint in AOD indeed, but another 10% was for Active mode. Anyway, if the tool works, it could greatly speed up the process, thanks!

Hi. Just use the tool and when watch face passes both Active and AOD checks simply submit it for approval. It should be accepted from now.

WFS not support WFF format currently, right? So the tool is not working for WFS users or can we use it too?

Watch Face Studio 1.4.2 and 1.5.7 support Watch Face Format
see the release notes for WFS 1.4.13

  • Support watch face format of Wear OS

Active size limit was not an issue with the pre WFF watch faces and should not be a problem with the current WFF any longer, except in extreme circumstances. It may be for ambient mode but that would be because of a poorly designed AOD.

Ron
Samsung Developer Relations

1 Like