John in Michigan USA

Evernote takes a snapshot of your note every so often. If the note existing for long enough before the changes that didn't work out, you can revert to an earlier snapshot. https://help.evernote.com/hc/en-us/articles/208313858

IIRC Evernote uses an Android component, WebView, for some or most of the editor. I suppose you could roll back Android to an earlier version, but I'd want to do some research first. Maybe you have access to an Android device that hasn't updated in a while? Maybe you could use an Android emulator...which I've never done. I hear https://www.bluestacks.com/ is good, there are a lot of others. In connection with another forum post, I made this table showing recent version numbers of Evernote for Android and two other components (WebView and Uno) that appear in the Activity Log. It might give you some clues as to what's changed. The table is truncated on the right in my browser (Chrome on Win 7) for some reason but you shouldn't need the info that is truncated :-)

Hector, Thanks for the update, it does mean a lot to know that Evernote is still aware of this issue and the problems is causes for users. It would help a great deal if someone from Evernote could address the question: when these problems were first reported, why not roll back the changes to the last known good version (probably < 8.9) -- if not for everyone via Play Store, then why not at least offer users a manual way to download and install the last known good version. Evernote could post the 8.8.x .apk file someplace, so we don't have to rely on services like https://evernote.en.uptodown.com/android/old who offer a complete set of past .apks, but leave us to take it on faith that the .apk's are...unmodified, shall we say... I look forward to your response.

Support (Ticket# 2830826) informs me that it is a feature that Evernote for Android will keep my display screen lit and unlocked anytime a note is open. In fact it seems to do this even if I am looking at the All Notes list, or any note list! My request is to make this feature a configurable setting. I for one would much rather not inadvertently drain my battery, even if it means the screen locks up sometimes when I'm reading a long document, lost in though, distracted, etc. This is important for security, too! But people other than me may disagree...which is why it should be a *setting*, not an always-active feature. Also, phone OS's are getting quite smart about screen lock, they often are able to tell based on the app (or the usage pattern) that some apps -- readers, video players, games, others -- shouldn't lock, while most should. In fact, I'll bet if Evernote implemented a full screen option, the OS would respect that and not lock the screen while in full screen mode. How about it?

A (relatively?) new feature of the discussion forums is, you can vote for your favorite feature request. So everybody, go to the link below and, be sure you're logged in, then smash that up-vote button, it is top left of the screen. Attached is a screen shot of it, it is circled in red

I had the same issue. Support tells me it is a feature of Evernote, if a note is open on screen, Evernote will prevent the screen from sleeping. This is for users who use Evernote to read long documents and don't want the screen turning off. I am sympathetic to readers, but Android offers build-in features to over-ride the default screen lock / sleep timer. These OS features are configurable, and increasingly, they are smart enough to guess when you are reading and prevent or delay the screen from sleeping. Evernote should let the OS handle this!

For what it's worth, I'd like to again ask that Evernote make this a feature of the apps (Android, iOS). It is even harder to do this manually in an app with the on-screen keyboard. Reliable 3rd party apps don't see to exist, or else, they need access to everything on my device. Please, please put this simple feature into the EN apps! It could be added to the editor control bar (the one we use to insert check-boxes, for example.

Fellow GTD fan here. Sorry this happened. Since you are new to saved searches, you might be wondering, does it matter whether you create the saved searches (and/or add them to the shortcuts list) on the Win client, the Web client, or the Android app? Answer: it shouldn't matter, and before v. 8.9 I've been able to use saved searches and shortcuts created on any client on any other client. Have a look at https://discussion.evernote.com/topic/119365-search-not-working/ see if it describes what you are seeing. It is a pretty long thread that discusses various scenarios or variations on the search problem. Sounds like you're experiencing the saved search & shortcuts variation, not the endless hourglass variation. Or maybe those are two separate bugs introduced in ver. 8.9? If you want the full picture, follow the links in the comments as well. TL;DR - Open a ticket with support, but if they can't solve it, it is probably a known issue that Evernote shows no signs of fixing soon. Here are some direct links to some workarounds: clear local search history & clear cache Install ver 8.8 from outside the Play Store (!) and disable auto-updates On Android app, go to All Notes screen, use the magnifying to perform your search from scratch. Then, instead of saving the search, use the "send to Home screen" option from the 3-dots menu. Use that icon instead of the saved search. Somewhere in the comments of the thread, there's a link to another thread with comments where somebody who isn't me proposes this workaround. I can't locate that comment right now, so I can't give them credit...

Fair point, should have thought of that.

I tried this and it gave me an extra $10 credit. I haven't set up billing yet, so if you haven't got your $5 maybe they don't do it unless I covert to a paying customer? Which I will likely do. Thanks.!

Six years ago I gave them a 5 star review. Since then, I've updated the review each year. Any year that included one or more long-standing, reported and well-documented bugs, I deducted a star from my review, and wrote about the problem in the review. I am now at 1 star, been there since last year. What's worse: at least 1/3 of these bugs are regressions -- by which I man a bug that occurred in a feature that as working fine in the previous version, a bug that could have been solved by simply rolling back the change(s) in the relevant code section(s) so that the feature resumes working again. Any team with basic source control and non-spaghetti code can easily do this. Plus, they should be doing regression testing, so that when a change causes a previously identified bug to re-occur, the team spots that right away instead of waiting for users to leave/complain. <insert broken record emoji>

Downgrading brings back memories....what I remember from 2+ years ago is, downgrading won't destroy or prevent access to existing large notes, but it will prevent you from creating new ones over the size limit. It may let you edit, but it presumably won't let you save if the edited note is too large. So far, reasonable...but the limit can cause some very subtle problems! For example, if you cut a large embedded object from a note, get distracted by a notification or something, then paste it in a different part of the note...and the note auto-saves in between the cut and the paste, it might not let you paste, as technically you are making the existing copy of the note, which is under the size limit, into an oversize note. Or, if you use the EN app control to start a voice (or worse, video) recording...if you accidentally exceed the size that can be saved into a note, it will show you an error message (reasonable) but it will also send whatever you recorded into the bit bucket! Many people have encountered this...support assures is, there is no temp file of your recording. You'll have to re-record whatever it is. Without the size limit, this bug usually only happened when your device was slow, or if the user on a fast device doesn't wait 10-20 secs after stopping the recording for the file to attach itself and appear in the new note. Even on a fast device, if you try to make any other changes to the note before the recording fully saves, the save sometimes fails in which case your recording is lost. With the size limit, it must means there one more condition (size) that could trigger this bit bucket bug...and NO it hasn't been fixed to the best of my knowledge. Another scenario had to do with pasting objects that are file-less images (ie. you copy an image into the buffer without first downloading it) into a note. Sometimes the paste operation would convert let's say a X MB .png into a 5x MG generic image object during a paste operation. I think that scenario was patched re certain image types, but I highly doubt all the various possible large, file-less paste objects where addressed systematically. This bug could still be lurking, waiting for you. It could cause your note to exceed the size limit inadvertently...or to exceed the upload limit inadvertently. I haven't reproduced these scenarios in a while; but when I do anything mission critical, even with Premium, I assume they're still out there...waiting to strike!!! Good luck and do keep us posted. This makes me want to try Notion. Is there a referal a friend or similar program from them?

@rimboma it would be interesting to know your detailed version number from your most recent activity log. Under the "Device and Install Info" section you will find lines similar to: Evernote version: 8.x(yyyyyyy) Evernote revision: 8.x_zzzz Evernote type: public (or something else) This information would help determine if your issue is related to @Bill Clarke 's problem.

@Lexbrkly It might be interesting to check your activity log and post the build number and revision number of 8.9 that you have. Here's what I found when I did this.

@Dave-in-Decatur thanks for the links, I will start following those discussions too. It looks like Evernote on Android is having a version contamination problem. Astoundingly, this appears to have been going on for quite a while.

Updated update: I am no longer sure that I installed the Beta version of the Evernote app by accident. I am beginning to think that Evernote, or Google Play, is distributing the Beta version to non-Beta users. I think this for two reasons: two days ago, the EN app on my Pixel 2 XL (that was working fine) auto-updated and now I appear to have the beta software again (ver 8.9 according to Menu -> Settings -> Support) on my Pixel. Yesterday, the EN app on my NVIDIA Shield K1 (that was working fine) auto-updated and now it too appears to have the beta software (ver 8.9 according to Menu -> Settings -> Support). I am interested if anyone is experiencing this who has NOT been a past member of the Android Beta program? I opened Ticket# 2814243 re issue 1 above. The first line support person clearly understand the problem but is apparently powerless to do anything about it. The support person(s) above that seem mired it some sort of dysfunction, as there has been no update to the ticket since it was opened. Sad, sad face.

...turns out my problem wasn't related to this problem. I'd accidentally installed a Beta version of the app. It is surprisingly easy to do, even though I long since left the beta programme on Google Play. I think it happened because, when I got a new phone, G Play offered a list of previously installed apps that I might want to put on the new phone. I probably clicked Evernote without drilling down to see it was Beta.

Update: I re-installed on my NVIDIA Shield K1 (Android 7; EN Android app 8.8.1) and saved searches are working fine. But, they are still badly broken on the Pixel as per the ticket I opened. EN support is supposed to be open Sunday (for chat, at least) but apparently they don't check email, as I haven't heard a thing from them.

This sounds like it could be related to ticket #2804215 that I opened Mar 22, 22:14 PDT. Quoted below is what I put in the ticket, except for the link to my activity log. Pixel 2 XL, Android 9, EN for Android 8.9. I didn't post here until now because I wanted to give support a chance to fix or at least respond to this very serious and embarrassing failure before making it public, but as of now, I've gotten no response. I am a premium user. Time permitting, I will re-install Evernote on my old tablet and see if the problem is there too. I am disgruntled.

This saved search works most of the time, but sometimes subtly fails (or, from Evernote's point a view, works as designed albeit un-intuitively). I remember submitting several scenarios as bugs/feature requests but can't find them at the moment. Ultimately, my work-around on Android was to create an EN 5x2 "list" widget and set it to show reminders. This shows all of them by date due, with the ones that are overdue or due today in a separate sub-section at the top of the list, and doesn't have any unintuitive/buggy behaviors. I wish they could expose the exact code behind this widget so I could use it in a saved search!

Helpful to know. This is considered a bug, isn't it?

@Scott T. Thanks. I'm a glutton for punishment, so I've been reading the TOTP and HOTP RFCs. I see that asymmetric keys are not really a part of the RFCs; they would probably fall under the category of allowed but not required. So I withdraw my statement "only the user can generate codes". I guess TOTP isn't as robust as I assumed it was. But it is certainly appropriate for this use case. I am still concerned that audited code apparently made it into production with a logic error, even though that logic error itself presents only a minor security problem (codes leaking without user's knowledge).

Not impressed with the logic section of that code. That code is supposed to be audited before going live. Auditing means testing *all* execution paths or branches of the code. If they couldn't find this logic error in the audit, it wasn't much of an audit. Furthermore, sending out the G Auth code gives up one of the strongest features of Google Auth, a thing that separates it from simple, SMS-based 2FA: only the user can generate codes! Letting the server generate codes is the equivalent of storing the user's password in the clear in the user database...you should always store a salted hash of it, or otherwise prevent server admins from being able to easily discover user passwords for themselves. I guess the lesson is, don't put important stuff like bank info into Evernote! Edit: I should add that I just experienced this bug when logging into the Web interface from a friend's PC. Waterfox browser v. 56.2.8 (64-bit)

@EdH Yikes! That's bad.

To confirm: @EdH you are getting the exact same six digit code that the Google Authenticator app displays for about 30 seconds, via text? Or are you getting a text with a different six digit code that also works, but is different from the one displayed by the Google Authenticator app? Have you tried waiting until after the currently displayed code on G Auth expires before trying the code from the text? Can you still authenticate? IIRC, Evernote servers aren't supposed to be able to generate the 6 digit codes generated by the G Auth app running on the end-user's device. Those codes are generated in real time, based on a hash of the private key (that only the end-user has; not even Google's servers are supposed to keep this!) and date time stamp. Evernote servers shouldn't even be able to access that info, until the user enters the code, then the [edit: EN client or the EN server, not sure which, uses that code to query] the Google service and gets a token back saying if the code is valid at that moment in time.