Update the status for memory budget limit

Hi all

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.

Thank you
Catherina

15 Likes

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.

Thanks again!

Matteo Dini

7 Likes

Hi Catherina,

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?

Best Rgds,

Rob Sharp

2 Likes

OK all,

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…

Procedure:

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.

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

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

 App Summary
                       Pss(KB)                        Rss(KB)
                        ------                         ------
           Java Heap:    60012                          71656
         Native Heap:    42040                          44340
                Code:     7720                          33936
               Stack:      436                            496
            Graphics:    15031                          15031
       Private Other:     6168
              System:   662255
             Unknown:                                    3540

           TOTAL PSS:   793662            TOTAL RSS:   168999       TOTAL SWAP PSS:   658814

 Objects
               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
            WebViews:        0

 SQL
         MEMORY_USED:        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?

2 Likes

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.

3 Likes

Hi @catherina00,

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.

1 Like

@Ballozi

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!

1 Like

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!

Regards,

Matus

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…

2 Likes

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.

1 Like

I like the way you made this post. This post is helpful for me and other people who need it.