Some notifications read improperly

[MolotovCherry]

When somebody quotes a message that was using new WeChat quote feature, the notifications will appear as [Message] instead of the actual message. This happen to regular unquoted messages

Also happens when links are sent

Using wechat 8.0.1, nevo 6.2, Android 11, pixel 2 xl

[MolotovCherry]

I tried to fix this by myself, but it turns out it's not that easy. It seems to be a WeChat bug.

What I learned is that in WeChatDecorator.java @ here
conversation.ext = IGNORE_CAR_EXTENDER ? null : new Notification.CarExtender(n).getUnreadConversation();

It is already being interpreted as [Message] even at this point. It appears to me that this is WeChat's fault for not providing proper data for the car bundle, because when CarExtender reaches the end
mUnreadConversation = UnreadConversation.getUnreadConversationFromBundle(b);, getUnreadConversationFromBundle() will return [Message] for all affected entries. After debugging the inside of getUnreadConversationFromBundle(), I can confirm the data was already affected for the car bundle.

The ticker data remains unaffected however.

For now it appears to me that the only solution to this problem would be to maintain a cache of ticker notifications and then maybe filter out and fix CarExtender's affected entries, then do a setUnreadConversation() for the affected entries in CarExtender. This way we won't lose the direct reply functionality.

[MolotovCherry]

I patched the problem by creating a Conversation History class and caching the conversation. If it sees a "[Message]", it will grab the data from the ticker, car bundle (if it's not corrupted), its internal cache (already calculated), or if all else fails calculate it from notification history (using getArchivedNotifications(); unfortunately I have no choice but to rely on this, as there's no other way to get the back data, e.g. in case the application didn't have it cached before and car bundle is corrupted). Because I'm not sure how good my solution is - and I'm sure you can come up with a better one, so I didn't send a pull request for it. However, I'll link to my solution for you to either use or help to derive your own from. Find it here

[oasisfeng]

Ye, Conversation History is also the plan in my mind, to improve the conversation experience and fix a lot more issues.

Thanks for sharing your thoughts on this.

[MolotovCherry]

Certainly!! Conversation History is really helpful. I even used it to implement recalled messages functionality (you can find in my dev branch)

[oasisfeng]

I'll review your contribution as soon as I had time.

[Marukon]

I patched the problem by creating a Conversation History class and caching the conversation. If it sees a "[Message]", it will grab the data from the ticker, car bundle (if it's not corrupted), its internal cache (already calculated), or if all else fails calculate it from notification history (using getArchivedNotifications(); unfortunately I have no choice but to rely on this, as there's no other way to get the back data, e.g. in case the application didn't have it cached before and car bundle is corrupted). Because I'm not sure how good my solution is - and I'm sure you can come up with a better one, so I didn't send a pull request for it. However, I'll link to my solution for you to either use or help to derive your own from. Find it here

Could you release a apk, please?

[MolotovCherry]

Could you release a apk, please?

@Marukon Due to the way the program is implemented, the apk wouldn't work for you due to sharedUserId and signing keys. As such, the apk would be incompatible with your Nevo, unless you decide to re-sign your Nevo + Decorator with a new signing key and change the sharedUserId + processes in the manifest. Your best bet is to wait for the author to check / merge / implement my solution (or a variation thereof / or his own version)

TLDR: Possible if you want to do a lot of work to make it compatible, otherwise, not possible

Side note for oasisfeng: My dev branch has a much newer version of these implementations. However, it also contains a lot of other stuff I've been working on that's not completely related to [Message]. Plus it's in Kotlin now. You may want to check that out too~

---

My solution to read conversation.ticker (which is the ONLY thing that has the message when they get quoted - so there's really no choice) is not ideal, since the ticker will finish the message with ... if it's too long (so we'll miss the whole message).