It’s been in a while.
We’ve been expecting Watch Face Studio users to immerse themselves in designing regardless of Wear OS platform, by applying Watch Face Format.
However, the unexpected new Wear OS requirement seems to intend to save the battery time of the Watch devices.
Samsung is still discussing with Google in order for many of the watch faces built by new Watch Face Studio to be accepted and registered to the Google PlayStore.
We are helping Google to review their criteria of enforcing the restriction and find ways to guide how to optimze well within the memory budget limit.
We’d like you to deliver your voice directly to Google so that Google can understand how uncomfortable you are .
I hope your voices and ours together to help Google to set the standards and measures for better watch faces.
Hi @catherina00 ,
First of all, thank you for all the effort you are putting in as always!
In recent months I have sent dozens of appeals to Google to improve the new memory requirements, especially for previously released watch faces that have already been downloaded several times and we certainly cannot make them worse due to their new policy.
Users would rightly get angry and we would only receive negative comments that would make our business worse.
In recent months I have only sent these appeals through support tickets and we often only receive pre-packaged responses.
Do you know other sources where we can send our appeals?
I also sent a long email to the Google Play merchandising team to improve the editorial side of the watch faces on the Play Store because it’s really disappointing at the moment.
I really don’t know what to do with them anymore. Every week there are new problems with Google.
I can only echo what Matteo has said. I have many watchface updates ‘parked’ due to the memory budget exceeded issue (all of which are currently on sale) and I do not want to start hacking them around to ultimately provide a poorer user experience to the detriment of my customers.
Several of my watchfaces are also affected by a font display issue on Wear OS 4 devices (support ticket# 47943) so I urgently need the updates to be published to overcome the issue.
I cannot tell you how demoralising it is to deal with Google’s review and rejection process. We currently have no method of assessing which aspect of the budget has been exceeded and by how much, and the review process is inconsistent. One watchface in my portfolio actually passed review recently and it’s one of the most complex faces I have and includes multiple animations.
The Google reviewers don’t appear to be able to provide any additional information and requests to escalate are ignored.
The problem has been ongoing for many months and the developer community is effectively still in the dark.
You ask that we raise this directly with Google.
What channel do you recommend we use that may actually reach someone who will listen?
Here’s a question for Google… How can we test our watchfaces to see if they exceed the memory budget?
Note that I’ve tried asking this question in an appeal scenario when a watchface has been rejected but Google either cannot or will not provide any informaion that would make everyone’s life easier. I don’t know why. I have asked to escalate the issue to the person responsible for the Wear OS watchface review process at Google, but such requests are simply ignored.
So it is possible, using adb, to query processes on the watch device but I don’t know whether any of the information I’ve managed to extract is relevant, if any. If Google could advise this would at least give us a way to measure memory usage…
Once you’re connected to your watch device using adb pair / adb connect you’re effectively able to use unix shell commands to interrogate Wear OS.
- I reason that we need to identify the specific process running the active watchface…
I used the command “adb shell ps -ef” to get a list of processes running on the watch device.
I expected to find a process named the same as my watchface, e.g. com.watchfacestudio.orb05, for example, but there isn’t one.
There is however a process named “com.samsung.wear.watchface.runtime”
I’m guessing that this is actually the process running the current active watchface.
It would be good to get this confirmed.
- Get the memory info for this process
I used “adb shell shell dumpsys meminfo PID”, where PID is the Process ID of the com.samsung.wear.watchface.runtime process given in the output of the ‘ps -ef’ command.
This gives a lot of information, but oddly the command does not complete until I wake up the watch (i.e. cause the watch to switch to active mode)
Example of info reported…
C:\Users\robsh>adb shell dumpsys meminfo 906
Applications Memory Usage (in Kilobytes):
Uptime: 95501819 Realtime: 689446527
** MEMINFO in pid 906 [com.samsung.wear.watchface.runtime] **
Pss Private Private SwapPss Rss Heap Heap Heap
Total Dirty Clean Dirty Total Size Alloc Free
------ ------ ------ ------ ------ ------ ------ ------
Native Heap 43691 42040 1624 657045 44340 852756 836072 16683
Dalvik Heap 59950 57860 1976 595 60768 61398 55254 6144
Dalvik Other 2487 2224 128 83 2784
Stack 492 436 56 344 496
Ashmem 33 0 0 0 244
Other dev 39 0 36 0 216
.so mmap 1384 100 144 88 12032
.jar mmap 936 0 292 0 6864
.apk mmap 2462 0 2280 0 3040
.ttf mmap 4 0 4 0 4
.dex mmap 4720 12 4704 204 5028
.oat mmap 661 0 56 0 6568
.art mmap 2691 1120 1032 134 10888
Other mmap 19 4 4 0 304
EGL mtrack 915 915 0 0 915
GL mtrack 14116 14116 0 0 14116
Unknown 248 180 64 321 392
TOTAL 793662 119007 12400 658814 168999 914154 891326 22827
Java Heap: 60012 71656
Native Heap: 42040 44340
Code: 7720 33936
Stack: 436 496
Graphics: 15031 15031
Private Other: 6168
TOTAL PSS: 793662 TOTAL RSS: 168999 TOTAL SWAP PSS: 658814
Views: 0 ViewRootImpl: 0
AppContexts: 130 Activities: 0
Assets: 55 AssetManagers: 0
Local Binders: 326 Proxy Binders: 1294
Parcel memory: 33 Parcel count: 124
Death Recipients: 65 OpenSSL Sockets: 0
PAGECACHE_OVERFLOW: 0 MALLOC_SIZE: 0
I don’t know as yet, which if any of this info is relevant to determining the memory budget usage.
I don’t know if this is in any way helpful but felt it best to share.
Perhaps Google can advise on a procedure?
Hello @catherina00 , I just found this thread and I’m sorry for the late reply.
Well, developing watch faces is a frustrating experience as of now. I worked hours and hours on many designs just to being unable to publish them, even after taking the time to optimize each and every asset used (just imagine how many time wasted!)
And, even worse, I have to explain to my users that yes, the update is ready since September for many of my watch faces, but I literally can’t release it without demolishing what is ALREADY available. Again, imagine how frustrating this is.
So, to synthesize: I can’t fully express my creativity. The Google team is unresponsive, the entire Play Store has weird indexing behaviors, I develop apps since 2014 and what I learned is that Google considers the developers something like an enemy or a problem. They doesn’t protect or help us. Even if we’re part of the reason why WearOS is doing good. Even if we bring earnings.
WFS is a wonderful program, but it still lacks some important feature and I’m sure that the team is working hard to add them.
I’m just sad because I love making watch faces and apps in general. But they let me down in many ways, many times. And I’m sick and tired.
I’ve seen solutions in this forum to get pass this memory budget limit error and have the watch face published in Play Store using WFS 1.5.7. That solution is to strip down and reduce stuff in the AOD of the watch face. Do you think this is the direction of Samsung/WFS team wanted? Let us know as soon as possible so that we can move forward in updating our watch faces and disregard the AOD. I honestly don’t like what is going on.
Considering some watchface developers mamage to publish their WatchFaces using Android Studio, while having full featured AODs, I don’t think this was the direction intended.
I’m just surprised that this is taking several months. This has started since May!
Hi @catherina00 ,
Many thanks for your willingness to solve something in the approval process on the Google Play Store. I really appreciate it and I am glad, that you and your colleagues have still the patience to be involved - THANK YOU!
My personal experience is almost the same as by other developers. Whether the dial will be approved or rejected based on the memory budget is currently a pure lottery. Sometimes the complicated AOD mode is approved on the first time, other times, almost minimal AOD mode is rejected also after the third optimization.
The only current solution is patience, perseverance and a cool head:) Once again, many many thanks for your effort!
Anyway, in my experience until now, the 100MB for active mode is quite reasonable with some optimization. Of course, no long animations, no big images, no more than 3-4 complications and so on, so it’s still limiting, but not blocking. The AOD requirement, instead, is nonsense, unless you have an empty AOD, or an AOD with little to no design elements, and just the time.
I reduced some of my watchfaces to the bare minimum in AOD, and they still are 25+ MB.
So, in my opinion, a first step in the right direction could be to increase the memory limit in AOD to AT LEAST 50MB. Many of my watch faces would be accepted in this way.
And please let us know if you have any news on this, even if I bet that you still didn’t hear from Google, knowing their response times…
How do you know this?? The only time I ever got any indication of where I stood was when I appealed. That’s when they actually provided me with a number, so I could figure out what the problem was and how to fix it.
@MergeLabs I appeal every single time, and most of the times they include the memory footprint details. That’s the only way to know that at the moment.