After updating to WFS 1.1.9 I’ve started releasing updates to some older watch faces, mostly just introducing more colors for customization options.
Every single update has been rejected by Google Play.
Reasons for rejection were “SPLIT_BUNDLE 1:” in one watch face, “SPLIT_BUNDLE 4:” in another, while in few others rejection reason was a previously annoying “Heart BPM is not working as described/shown in store listing.”.
Does anyone have any idea what these “SPLIT_BUNDLE” issues are related to?
Perhaps it’s caused the latest WFS 1.1.9 update, I’ve never seen this as reason for rejection before.
Also, I thought the BPM issue would no longer be an issue when simply releasing an update to an existing watch face (which was already approved for Wear OS, and has a working BPM indicator), but it seems that Google started rejecting simple app updates due to this annoying issue.
I’ve submitted appeals for all rejections, asking for more info on what exactly didn’t work for them (as well as explaining how BPM indicators work in WFS), but I don’t expect much, based on previous experiences.
Its not related to WFS version update. I uploaded wf two days before created with previous version of WFS. Got rejected and same kind of mail received. I guess its related something else.
I’m not sure this is relevant in this case, though. The “SPLIT_BUNDLE” issue I got wasn’t defined or related to anything, just under title “Basic functionality of app isn’t working as described” and no other details.
The “SPLIT_BUNDLE” issue mentioned in the link is strictly defined as “Policy Declaration for Play Safety Label” issue, and the answer suggests changing the Data safety form in Play Console and stating that the app does collect user data, which makes sense.
This isn’t the case with watch faces made with WFS, as far as I’m aware. No data is being collected or shared, so I’ve selected “No” for the “Does your app collect or share any of the required user data types?” question in the Data safety form, this is true for all my other watch faces which haven’t had this rejection problem.
Just re-upload your watch face. Take one step at a time, if you upload a new version aab file, I suggest no other updates come along with it like updating the Main Store listing or other stuff. Update your watch face silently. Here is mine by the way. I also get this from a watch face that I just updated the little portion of the description.
have you got your Data privacy policy published? You need that even if you don’t collect any data
As noted in the link shared by hs619.choi All apps are required to complete an accurate Data safety section that discloses their data collection and sharing practices - this is a requirement even if your app does not collect any user data.
Yes, I have it published and available, it states that my watch faces don’t collect any user data.
App submission process in the Play Console doesn’t really let you submit an app fully without submitting the Privacy policy and filling the Data safety form.
I don’t believe this rejection is related to data privacy, hopefully it would be defined if that was an issue.
Problem here is mostly lack of info about specific rejection reason, as “SPLIT_BUNDLE” doesn’t really define anything on its own, and yet it’s the only thing that’s mentioned.
Thanks @Ballozi for your suggestion, I’ve re-uploaded one of the watch faces with a newer version number and no other changes, hopefully this will work.
I’ll wait for replies from Google Play for other rejections as I’ve already submitted the appeals, and update this topic if there’s any new information. It’s almost weekend now so I don’t expect any news on this until Monday.
UPDATE:
Simply submitting a new version, without changing anything else, worked for all rejected watch faces!
It’s hard to believe that’s all it took, but I guess it’s the simplest solutions that work best. Still very weird how Google handles (and rejects) functional updates.
Hopefully this helps someone facing similar issues. Thanks everyone for your help!
