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.
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.
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.
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
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.
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?
@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?
@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!
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.
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!
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.