Jump to content

EskeRahn

Keymaster
  • Content Count

    5,798
  • Joined

  • Last visited

  • Days Won

    348

Everything posted by EskeRahn

  1. That was very sad news, 😨 Will you get them at a later point? Wasn't The whole idea of the usb on a separate print that it should be easy to swap? If end of service, could you provide diagrams, so some handy persons could produce them, without the need of reverse engineering first? What parts are potentially available for the Pro1? If none/few it would be nice to know if we have to treat a Pro1 with the uttermost care as irreplaceable...
  2. When I have experimented with downgrading a good while back, and it works fine - though you will (almost) always need to wipe the user data in the process, and I always flashed the boot image as well.
  3. The 48MP sensor produces 12MP images after interpolation - I guess it is a sales thing that Sony market it as 48MP, and this is usually just copied by those that use it. e.g. FxTec. We have this difference discussed in another thread somewhere... Interesting with the 662/665, what software are you seeing this on? If I check my Pro1X with "Aida", it says "Qualcomm snapdragon 460/662", "Device Info HW" says "662", but "CPU-Z" says "665". So I guess that the app sort of takes a guess on the cpu based on the info available, rather than get an actual ID back - that could explain discrepan
  4. As can be seen even on the hash of the last four, the boot.img is not identical, and I know from AICP, that a flash can be quite picky on the bootloader selected matching the zip. So at the least when changing major version, I think you should flash the boot-loader first. For LOS I always flash the matching bootloader before booting into the recovery and sideloading the main zip. It might be a superfluous step in general. but I believe @tdm did the same thing in the guide he originally provided for v16, so I just followed that since...
  5. Thanks. So not that easy to extract after all - though possible if needed.
  6. It might be so on other builds, but not on the official builds for LineageOS 16, 17, 18, 19, 20, nor AICP as far as I can see. (It might be inside payload.bin though) Here latest Lineage
  7. We got no real info here, but we do know that many US carriers makes it it hard to do BYOD, so check with you carrier first, or be prepared to look for another carrier. There are some good info in this thread on what various US users have tried.
  8. I have stopped expecting any logic here, though I still expect that I will get it at some point.
  9. What they are now sending is the 8/256GB Blue QWERTY-EN, So those of us with more rare choices (like my Scandinavian keyboard) will have to wait further, despite having a number way below 568.
  10. For those interested, the old: https://web.archive.org/web/20230227093209/https://download.lineageos.org/pro1
  11. They changed the download site (this is Pro1, not Pro1X). As usual practically everywhere on the web these days to poor 'design' with extreme waste of screenspace. (see image below) And the recovery boot image now always have the name boot.img, so you would need to manually rename or move in subfolders to to keep pairs of files for later usage. (previously the recovery image were named e.g. lineage-20.0-yyyymmdd-recovery-pro1.img for 20.0 ) But it works as usual: (lineage-20.0-20230306-nightly-pro1-signed.zip on February 5 security patch installed smoothly using adb sideload and Mi
  12. Sad to hear... But could it be that when it fails, it is actually failing trying to switch to another band? I so not know if it is possible as a user, but could be interesting to see what would happen if we could lock it on a single band only. (Obviously not a solution, but just to help debug the issue, by narrowing it down)
  13. Oh I'm not saying that that is where I want the whole thing to be&go! BUT trying to be pragmatic, I would rather pay (even) more money than having a device I could not use, I would expect that -though far from all- some others might feel the same. It is not a matter of right or wrong here. Sure feel free to criticize all that went wrong, but venting our frustrations does not change anything. It is a matter of looking at the possible alternatives. Neither many with not working devices nor few with better working ones sounds good to me. Nor does shelling out more money of course. But if
  14. Absolutely. but as other have it failing going from 20 to 3/1, and you see the complete opposite, to me indicates that it is the switching that could be the real culprit. Their communication has unfortunately always been sparse to put it mildly. So slim chances of them telling about work looking for the bug and/or looking for a fix. Once they told they are aware of the problem, the next we will hear is if (hopefully: when) they can offer something that improves or even fixes the bug. I have not got a clue on their financial situation, and have no clue on the resources allocated
  15. That is a really interesting observation. And this points towards software/firmware and not hardware! I mean the most likely common denominator is that it works when not switching bands. So it could really be the band-switching that is flawed! That would explain why testing on different frequencies might have worked well, but real life switching could still fail. It might be under particular conditions or special pairs of bands - I have no idea, just guessing... If some carriers use mainly one band (at the least in some areas), we might not see it, but other carriers might rely more h
  16. ADD: Just had the issue on the Pro1, and the workaround does NOT help here, so most likely two different bugs, though with same symptom.
  17. Great that you found a workaround! And thanks for sharing, I will try that, the next time I get the similar bug on the Pro1. (At the least that unlock method works on the Pro1 too when the bug is not there) I got an early Pro1X unit from FxTec and a retail Pro1X bought from Expensys (still waiting on the super-early-bird one Perked for on IGG). And though I only use them for tests, I have not had fingerprint reader issues at all on these two (yet?) so I'm pretty sure it is not a general issue for the Pro1X. And as you still got see it on your factory reset unit, it should not be a
  18. (lineage-20.0-20230227-nightly-pro1-signed.zip on February 5 security patch installed smoothly using adb sideload and MindTheGapps-13.0.0-arm64-20221025_100653)
  19. I have not tried a complete backup and restore, but you might get some interesting info from the remark on the Persist partition in the top of this.
  20. Unfortunately I fear you got some hardware malfunction. If it was 'just' a software bug 'all' with a Pro1X would see the same.
  21. For what it is worth, I can say that it is not a general issue on the Pro1X, so either you got something installed that does not agree well with the Pro1X, or you got a faulty unit. Does it work generally unlocking from screen locked state? Is the bug limited to in apps? My best - well least bad -suggestion, is to save all on the device, and do a factory reset. At first without restoring anything, to see if it works unlocking the screen in this state. If that works, we are looking at software-conflicts. If it does not work, we are looking at hardware-issue.
  22. Note that the OP question was on the Pro1X, I was just telling that I have seen it on Pro1 too - I have not seen it on Pro1X -yet- though, but am not using it daily.
  23. A similar issue exists on the Original Pro1. Occasionally it get into that state, and a simple restart fixes it. But the issue comes back. Sometime the same day, sometimes weeks after. I see no real system in it. Except I have a suspicion that touching the reader while it is vibrating a notification, triggers the odd state - though not always. Or maybe it is while it is still receiving an sms/email/call. Picking it up in an idle state to e.g. send a message does not seem to trigger it - or only rarely so.
×
×
  • Create New...

Important Information

Terms