Related
As topic says, is there a custom recovery available for R819 ?
I found TWRP for Chinese R819T version, but is it compatible also with the R819 ?
samusalo said:
As topic says, is there a custom recovery available for R819 ?
I found TWRP for Chinese R819T version, but is it compatible also with the R819 ?
Click to expand...
Click to collapse
Not yet. Dees_Troy is working on it now, he got an R819 a day or two ago. (Edit: oops, he doesn't have his yet, he was just working with someone else.)
I just got mine earlier today. Right now I am trying to get a complete return-to-stock package from Oppo. Yeah, I could extract everything and eventually build one myself, but it's SO much easier when the manufacturer provides it for you. Unfortunately it's the weekend and the Oppo guys are in a complete different timezone than I am. I think that was the main reason Dees_Troy is halted too - Trying to boot the image using "fastboot boot" doesn't work, and he's (understandably) nervous about flashing a recovery when he doesn't have a return-to-stock image.
Edit: FYI, motochopper works for rooting. It's a royal pain to get it working with this device on Windows machines, but on Linux, you only need to get ADB running by adding 0x22d9 to ~/.android/adb_usb.ini
Entropy512 said:
Not yet. Dees_Troy is working on it now, he got an R819 a day or two ago. (Edit: oops, he doesn't have his yet, he was just working with someone else.)
I just got mine earlier today. Right now I am trying to get a complete return-to-stock package from Oppo. Yeah, I could extract everything and eventually build one myself, but it's SO much easier when the manufacturer provides it for you. Unfortunately it's the weekend and the Oppo guys are in a complete different timezone than I am. I think that was the main reason Dees_Troy is halted too - Trying to boot the image using "fastboot boot" doesn't work, and he's (understandably) nervous about flashing a recovery when he doesn't have a return-to-stock image.
Edit: FYI, motochopper works for rooting. It's a royal pain to get it working with this device on Windows machines, but on Linux, you only need to get ADB running by adding 0x22d9 to ~/.android/adb_usb.ini
Click to expand...
Click to collapse
What about Kernel SOurces and Other Trees ?
GuneetAtwal said:
What about Kernel SOurces and Other Trees ?
Click to expand...
Click to collapse
https://github.com/oppo-source/R819-Kernel-Source-4.2
MediaTek's kernel build system gives me a headache... It's a mess. Also, there are some nasty licensing conflicts between various files there. It's better than no source at all, but there are some issues a few of us are in contact with Oppo to resolve. (Oppo has been EXTREMELY cooperative so far.)
The biggest problem is that right now fastboot won't allow you to flash or boot any kernel images, whether normal boot or recovery. This means that if you hose up a device by flashing a bad recovery or kernel, you've got a brick. Supposedly Oppo is also working on fixing this too.
I successfully wrote a test TWRP image that Dees_Troy provided me, but I'm not going to make it public for the following reasons:
1) MTK's dumchar driver used to read/write kernel and recovery partitions does not do any size enforcement. Backing up a kernel in recovery will result in a 4GB backup image at the moment... I've figured out how to fix the driver, however:
2) Being unable to recover from bricks using fastboot means that this thing is extremely dangerous
3) The fstab is probably still not right for the device
The biggest blocker is 2) above - once that's resolved it should be a matter of only a few days.
Edit: I was partially wrong. It's not possible to flash recovery from fastboot, but you can flash replacement boot images.
Entropy512 said:
https://github.com/oppo-source/R819-Kernel-Source-4.2
MediaTek's kernel build system gives me a headache... It's a mess. Also, there are some nasty licensing conflicts between various files there. It's better than no source at all, but there are some issues a few of us are in contact with Oppo to resolve. (Oppo has been EXTREMELY cooperative so far.)
The biggest problem is that right now fastboot won't allow you to flash or boot any kernel images, whether normal boot or recovery. This means that if you hose up a device by flashing a bad recovery or kernel, you've got a brick. Supposedly Oppo is also working on fixing this too.
I successfully wrote a test TWRP image that Dees_Troy provided me, but I'm not going to make it public for the following reasons:
1) MTK's dumchar driver used to read/write kernel and recovery partitions does not do any size enforcement. Backing up a kernel in recovery will result in a 4GB backup image at the moment... I've figured out how to fix the driver, however:
2) Being unable to recover from bricks using fastboot means that this thing is extremely dangerous
3) The fstab is probably still not right for the device
The biggest blocker is 2) above - once that's resolved it should be a matter of only a few days.
Edit: I was partially wrong. It's not possible to flash recovery from fastboot, but you can flash replacement boot images.
Click to expand...
Click to collapse
WEll it is same as Xperia C's Source and other Leaked Source :/ i Don't know why Mediatek don't make a Simple Filesystem like that of Nvidea and Qualcomm
i think it comes with cwm right,thats what a developer told me:fingers-crossed:
Zpik said:
i think it comes with cwm right,thats what a developer told me:fingers-crossed:
Click to expand...
Click to collapse
No, it does not. Stock Android "3e" recovery.
There's a TWRP image nearly ready, but who knows when it will be fully ready for public consumption. I won't be working on it (or anything else) at all this week for various reasons.
I finally got a response from Gnurou about this and it seems very promising.
gnurou said:
I have almost nothing but good news about the X1:
- It is supported by upstream Linux
- It is supported by Nouveau (or rather will soon be, I need to
cleanup and send some patches but I have Mesa rendering stuff
already!)
The issue is that a lot of patches for X1 and its GPU are still
in-flight, but please check
https://github.com/Gnurou/linux/tree/staging/nouveau for something
that is up-to-date. You even have a tegra210-p2571-e01.dts device tree
that should be fit for SHIELD TV, if you can get it to interact with the bootloader.
I haven't played with SHIELD TV personally for lack of a device, but
if I can get my hands on one I will probably try to boot that very
configuration and see what happens.
Click to expand...
Click to collapse
One note is that his staging/nouveau branch doesn't have the DTS, but his staging/work branch does. I'm going to assume that's what he meant.
Unfortunately, like he mentioned, this isn't upstream yet. And apparently there's some discussion on how to implement the new platform in the upstream kernel. Guess for now that means we stick with Gnurou's forked kernel until that gets sorted out.
There's one major problem that needs solved (and I won't be able to actively debug and test it for a couple days). There's no known way to pass the bootloader a different dtb. My first thought is to use this patch temporarily to allow appending the dtb to the image. Now like the first reply to the patch states, this is a horrible idea, but it should at least get the device booting. Once I get multirom working, I can load in a new dtb before kexec which will be much cleaner. That doesn't help anyone that wants to fastboot boot, though. Anyone have any ideas on that?
When I'm able to run new builds and start testing this, I'll post more info. Just wanted to get this out there for other interested who might get it done first.
Steel01 said:
One note is that his staging/nouveau branch doesn't have the DTS, but his staging/work branch does. I'm going to assume that's what he meant..
Click to expand...
Click to collapse
You are correct, staging/work is the branch you should use for any upstream-based X1 work. staging/nouveau is my staging area for Nouveau-related patches. staging/work is the same branch merged with the latest -next and many staging Tegra-related patches (including decent X1 support) from the Tegra maintainer (tagr). These patches will make it upstream eventually, but it will take some time.
So yeah, staging/work is actually a linux-next with extra X1 support patches + a few other staging patches of mine, I know this sounds scary but we are careful to keep it in a decent shape.
Steel01 said:
There's one major problem that needs solved (and I won't be able to actively debug and test it for a couple days). There's no known way to pass the bootloader a different dtb. My first thought is to use this patch temporarily to allow appending the dtb to the image. Now like the first reply to the patch states, this is a horrible idea, but it should at least get the device booting. Once I get multirom working, I can load in a new dtb before kexec which will be much cleaner. That doesn't help anyone that wants to fastboot boot, though. Anyone have any ideas on that?.
Click to expand...
Click to collapse
Does bootloader unlocking/fastboot boot work as expected? I haven't been able to check so far.
Regarding device tree: it seems like Android and the bootloader use the same device tree, which is convenient but has the undesired side-effect that if you replace the DTB partition with an upstream DT, the bootloader doesn't work anymore and if you try to boot upstream with the Android device tree, you will have lots of features missing (if it boots at all).
That's something that really ought to be fixed in a future OTA. Can you state the problem precisely and what you think would be a good way to work it around? I can think of using a separate DT for Android, or maybe a way to embed the device tree in the boot image (although the boot image format doesn't seem to allows that?).
I will try to get my hands on a retail device so I can experiment with it myself as well, but not sure when that could happen.
Well, I tried to boot a kernel to no avail, just a black screen. I reverted:
https://github.com/Gnurou/linux/commit/61bd93ce801bb6df36eda257a9d2d16c02863cdd
and applied (not cleanly, one chunk had to be manually patched):
http://lkml.iu.edu/hypermail/linux/kernel/1506.0/03053.html
Nothing. I used an old bbfs from Roth testing. But I didn't spend too much time on it, so it might be as simple as early printk not being on and the kernel was trying to tell me I'm stupid, but couldn't.
Bootloader requests? Well first, the command line support needs fixed. I was working on porting CM and added the disable selinux kernel cmdline flag like I did for the Portable and Tablet and it got completely ignored. That's embedded in the boot image, haven't tried fastboot -c.
So, when I saw the question on how to handle dtbs, I had what I thought was a crazy idea, but turns out I wasn't the first.
http://www.cnx-software.com/2014/05...device-tree-file-from-android-firmware-files/
Hijack the second boot section of the boot image and stuff the dtb in there.
The precise problem is that the bootloader doesn't support swapping dtbs. And worse as you stated, the bootloader won't work unless an android dtb is on the dtb partition. (Incidentally, that partition just got added to my list of never touch partitions on my Shield devices...)
Oh, and yes, fastboot oem unlock and boot work as expected. As does flash and erase. It justctakes the next half of forever to erase the pros user data partition.
I finally had a breakthrough on CM, so I may not have as much time to tinker with this over the next couple days as I expected. But I'll try to get a basic bb booting as soon as I can. It just might drive me up a wall to stare at a black screen with no way to know what's wrong first...
@Gnurou: Any progress on the inside on this? Fastboot is even worse in the latest release. Can't bring it up via a hardware method (have to 'reboot bootloader' to get to it) and fastboot boot is completely broken, just hangs the system when passing it anything, official or not). So doing more testing on the consumer side is much more difficult. Especially since I still haven't figured out how to get kexec/multirom working still...
Hi! I still need to put my hands on a Shield device to be honest. I have been making progress on the GPU front though, to a point where acceleration is now starting to work with upstream to a point where it should be soon possible to use X.
Thanks for pinging me though, I will ask for a Shield retail device and see by myself what needs to be done.
As more Lineage OS builds come on line and multiple "nightly" update builds for devices start to appear, one of the issues users may face is the how and why of installing them. The Lineage UPDATER states that it will reboot to the device's recovery to install the update, but that doesn't guarantee anything. If that recovery happens to be, for example, TWRP 3.0.2.0 on an LG v410 tablet, all that might happen is you might find yourself, as I did, staring at a TWRP screen with NOTHING happening. The goal of this thread is to give Lineage users a place to consolidate their experience-based knowledge of how to handle this - other than re-flashing the whole thing -for whatever device(s) they may have.
It will probably be the same as for my L900 with CM13 were I have to download the update, reboot into TWRP and update manually.
Sent from my SM-G900T using Tapatalk
nezlek said:
As more Lineage OS builds come on line and multiple "nightly" update builds for devices start to appear, one of the issues users may face is the how and why of installing them. The Lineage UPDATER states that it will reboot to the device's recovery to install the update, but that doesn't guarantee anything. If that recovery happens to be, for example, TWRP 3.0.2.0 on an LG v410 tablet, all that might happen is you might find yourself, as I did, staring at a TWRP screen with NOTHING happening. The goal of this thread is to give Lineage users a place to consolidate their experience-based knowledge of how to handle this - other than re-flashing the whole thing -for whatever device(s) they may have.
Click to expand...
Click to collapse
Are you able to navigate to the download directory in TWRP?
/data/data/org.lineageos.updater/app_updates
This is far from the worst thing that has ever happened, but WHAT, for instance WOULD be the recoveries that DO allow for automated updates? In my case, I downloaded the new nightly to the root directory my SD Card and let fly, and everything worked, but that seems rather not elegant.
nezlek said:
This is far from the worst thing that has ever happened, but WHAT, for instance WOULD be the recoveries that DO allow for automated updates? In my case, I downloaded the new nightly to the root directory my SD Card and let fly, and everything worked, but that seems rather not elegant.
Click to expand...
Click to collapse
Automated updates work fine for me. It automatically boots onto TWRP, applies the update, and reboots.
Might be a device-specific issue. I am on the OnePlus One, and the same TWRP version (of course made for my device).
I am guessing that perhaps there is an issue reading or writing the recovery script.
Interesting. Sure didn't work for me this a.m. but as I said, far from the end of the world. I also think the "nightly" is going to morph into the "weekly" and that will be fine, too. I have yet to find anything that doesn't work to my satisfaction aside from not automatically picking up my Wi-Fi at boot - not exactly a deal breaker
nezlek said:
Interesting. Sure didn't work for me this a.m. but as I said, far from the end of the world. I also think the "nightly" is going to morph into the "weekly" and that will be fine, too. I have yet to find anything that doesn't work to my satisfaction aside from not automatically picking up my Wi-Fi at boot - not exactly a deal breaker
Click to expand...
Click to collapse
BTW, are you able to navigate to that directory in TWRP?
Oops. Right after I clicked on send I realized I didn't answer your question!!
Yes, and the zip file is there, but nothing happened. As I said, far from fatal.
I updated my opo (Bacon) with the nightly ota download and most recent twrp, after reboot I had lost my home screen (2 of 3 pages remained) and several of the apps that I had dragged to those screens.. didn't work well for me. I let the ota reboot into twrp and it seemed to proceed without troubles until the opo came back to life. (finished booting)
Galaxy S5 SM-G900T here. Wiped my phone and installed lineage-14.1-20170131-nightly-klte-signed.zip with open_gapps-arm-7.1-stock-20170131 the day it came out and it has been good so far, no crashes or freezes and all apps work good except FolderMount, no biggie. Tried to install lineage-14.1-20170207-nightly-signed.zip and is giving me an "error 7 can't install this package on top of incompatible data". Any way to fix this without factory reset? Doesn't make sense to factory reset every week for an update.
Update: Tried to reflash lineage-14.1-20170131-nightly-klte-signed.zip and got the same error. So something must have changed. The only thing I can think of is I have SU 2.79 installed.
Update 2: Removed root, restored boot and same continues. I dont want to wipe on every update.
Sent from my SM-G900T using Tapatalk
Well, now semi-automatic at any rate.
Are you able to navigate to the download directory in TWRP?
/data/data/org.lineageos.updater/app_updates
First, sincere THANKS to jhedfors for this priceless bit of wisdom
Getting better. Still no "automatic update" but the latest "nightly" build did fire up TWRP, and put the update zip file into the aforementioned folder, and after that, installing it was the proverbial snap. I can't speak for everyone, but I would find no horror in the folks at Lineage giving in to reality and calling the "WEEKLY" as opposed to "NIGHTLY" builds.
Hey, since the only device I happen to have running Nougat at the moment also happens to be the OLDEST device I use on a regular basis, the Complaint Department shall remain CLOSED on this one. :angel:
I have an LG G3 (d855) with working LineageOS. The updater downloads OK and the zip is indeed in /data/data/org.lineageos.updater/app_updates, but TWRP refuses to do anything about it on reboot. I can browse to the folder manually, but it does feel that something isn't firing to get TWRP to perform the install automatically.
What is the trigger for TWRP to install a specific Zip on reboot?
D
For me, One Plus 3, automatic updates don't work. Also manually installing the latest
https://mirrorbits.lineageos.org/full/oneplus3/20170214/lineage-14.1-20170214-nightly-oneplus3-signed.zip gives me an error:
Checking for MD5 file...
Skipping MD5 check: no MD5 file found
Zip file is corrupt!
Updating partition details...
...done
Any idea?
I did a migration via experimental build coming from cm13 then updated to lineage 14, which worked OK.
But since then I cannot update the daily builds.
I have the "same" issue on a Nexus 6.
The updater tells me I have an update, I ok it to download. Once done, I click install, gets into recovery and stops.
Still in the recovery, if I try to manually install from the downloaded location (data/data/...), it says zip failed.
I reboot and try opening that zip on a PC and sure enough, Windows thinks it is corrupt also.
If I re-download manually from "https://download.lineageos.org/shamu" that copy opens fine on the PC and when moved to the phone (data/data/...) installs fine.
There is something corrupting the zip when the updater does its thing. ;-(
Note: This isn't a migration, I have just been updating "nightlies".
Stuck in the TWRP...
Hi everyone, in trouble :/...I have got an LG d802 and updated TWRP from 2.8.7 to 3.0.2-1, then did a boot/system backup of the current cm 13.0 and after that the "experimental" update (as described in the recent update & builds post on lineageos) from cm 13.0 to lineage 14.1 which worked.
I decided to use lineage updater to go to the latest nightly as described which must have failed (booted in TWRP an did nothing...). When installing the 14.1 nightly manually, TWRP 3.0.2-1 showed two error lines with "unknown command".
Since then I'm stuck in TWRP.
Restore of cm 13.0 backup was not possible with neither TWRP 3.0.2-1 nor 2.8.7, no errors, just wouldn't boot. I can't even find any cm 13 build... to try to back which would be an option of course.
I did wipe the system then, lineage expermental + nightly or just nightly can be installed "successfully" with TWRP 3.0.2-1 and 2.8.7 with no errors there anymore, but also the system won't boot.
Please, please help (and/or redirect me to the right thread), what can I do? Thank you!
First, you can ignore the two errors in TWRP
I've gotten them with each update I've installed, but in my case - an LG v410 tablet - I have successfully, if manually, installed three updates so far, with a few peculiarities. "Automatic" is just a nine-letter word concerning updates at this point. I can live with that.
One - it is going to download it to /data/data in the tablet's storage no matter WHAT I do. I can live with that.
Two - I seem to have to download the update at least two times before the Lineage updater accepts the fact that it is there. I can live with that, too.
Three - a "getting there and almost what I want with no major glitches" Nougat build is much preferred to a KitKat build that LG couldn't give a rat's rear end about supporting, and I can DEFINITELY live with that.
But, back to YOUR problem with being stuck in TWRP. Worst case disaster recovery scenario - ANY chance you have a non-Lineage ROM you can revert to and start over from THERE? Realize what a pain that is going to be, but... When I still had CM 12.1 on it, I once did that out of desperation when nothing else seemed to be able to get it to boot. WHY such a laborious process fixed it I have NO IDEA, but better to have a working mystery than a well understood paperweight.
I ASSUME you have respectable backups of your data, etc.. so that loss of TIME is your major issue ?? Also assume you've wiped the caches, etc..?? You COULD try offloading your data, wiping data, and reloading.
It also seems to take a LONG time to reboot after an update. Can I assume you are at least getting to the Lineage animated LOGO screen or are you hanging in TWRP itself?
nezlek said:
I ASSUME you have respectable backups of your data, etc.. so that loss of TIME is your major issue ?? Also assume you've wiped the caches, etc..?? You COULD try offloading your data, wiping data, and reloading.
It also seems to take a LONG time to reboot after an update. Can I assume you are at least getting to the Lineage animated LOGO screen or are you hanging in TWRP itself?
Click to expand...
Click to collapse
I'm hanging in TWRP, also did wipe data before. I found a full 13.0 backup, selected all but Data because of storage space..."successful"...still system won't boot...
(Power Off in TWRP doesn't even work, just reboots, if that is of any help...)...A wild guess...file system issue maybe?
Yikes
As reasonable a guess as any, I suppose. I admit I've never had TWRP refuse to power off if nothing else, no matter how badly I had screwed things up (often spectacularly) elsewhere.
ASSUME you've tried the hold the power button until it shuts off, after which it should have booted to Android when powered on trick. Or, assuming you can do so, pull the battery?
Perhaps your bootloader is the culprit. Can you just re-flash that?
I got stuck in TWRP Recovery Boot-Loop. Already had the issue before with cm14.1 beginning of december. Didn't they fix the bug or is it another one?
For the specs: I got a Nexus 4 - mako.
I did this FIX and it booted up again as it was before: https://forum.xda-developers.com/tmobile-lg-g3/general/fix-recovery-loop-twrp-computer-t2873386
What's now correct update? Download and dirty install manually in TWRP?
Thanks for the post
:good:
I've NEVER encountered that issue so glad to see someone has figured out a more elegant solution. I suspect your CM 14.1 problem is / was device (build for it) specific, as NONE of my CM / Lineage devices has ever done any such thing and they've all been updated several times in the last month.
In every case, however, I 've had to MANUALLY install the update zip file from within TWRP. Far worse things have happened and since I drive a stick shift car anyway, what the problem?
I'm thinking about picking up a Pixel XL soon (currently still using a Nexus 6) and I kind of just assumed that development on the Pixels was moving fine, until I started looking into it tonight, only to find that there is still only RC versions of TWRP that sound super buggy, and Lineage doesn't even have official builds for either device because of some issue with Google Apps and the partition system on the phone.
So, this leads me to a few questions:
1) Is the TWRP RC2 build for the Pixel XL fairly stable, functional and safe to use? I only ever really do the very occasional backup/restore within TWRP and flash stuff, so as long as the basic functionality is working I'd be happy.
2) This whole two partition thing sounds like a bit of a nightmare to me and sounds like a way riskier setup. Is it easier to brick this phone than other phones that use a normal partition layout, and is it possible to recover from something like that fairly easily?
3) For anyone that uses Invisiblek's unofficial Lineage builds, do they work fine? I know it has some crashing issue when trying to record multiple 30 FPS videos in succession, but that doesn't matter to me at all really. Is it possible to simply flash the official Lineage root file on this unofficial build to have the built in root, or would I be required to use SuperSU?
4) I see people talking about vendor images, and something about the phone getting hot or having super high CPU and memory usage until they reflashed this image. What is this about?
Thanks in advance to anyone who is able to answer any of my questions!
admiralspeedy said:
I'm thinking about picking up a Pixel XL soon (currently still using a Nexus 6) and I kind of just assumed that development on the Pixels was moving fine, until I started looking into it tonight, only to find that there is still only RC versions of TWRP that sound super buggy, and Lineage doesn't even have official builds for either device because of some issue with Google Apps and the partition system on the phone.
So, this leads me to a few questions:
1) Is the TWRP RC2 build for the Pixel XL fairly stable, functional and safe to use? I only ever really do the very occasional backup/restore within TWRP and flash stuff, so as long as the basic functionality is working I'd be happy.
2) This whole two partition thing sounds like a bit of a nightmare to me and sounds like a way riskier setup. Is it easier to brick this phone than other phones that use a normal partition layout, and is it possible to recover from something like that fairly easily?
3) For anyone that uses Invisiblek's unofficial Lineage builds, do they work fine? I know it has some crashing issue when trying to record multiple 30 FPS videos in succession, but that doesn't matter to me at all really. Is it possible to simply flash the official Lineage root file on this unofficial build to have the built in root, or would I be required to use SuperSU?
4) I see people talking about vendor images, and something about the phone getting hot or having super high CPU and memory usage until they reflashed this image. What is this about?
Thanks in advance to anyone who is able to answer any of my questions!
Click to expand...
Click to collapse
Hello,
I think I can answer some of your questions...
1 - TWRP is stable enough for the usual tasks. Some people seem to have issues with restoring partitions on RC2 and end up with some partitions word. Some others say they have no problems. Who's right, who's wrong, is it a particular scenario that makes this problem occurs, I don't know. I just use RC1 without issue...
Also, you are not obliged to install TWRP. You can "fastboot boot twrp.img" RC1 version, do your things and reboot. If you want to stay on stock firmware, it's a nice feature, since you won't have to reflash stock boot.img to take an OTA (Recovery is now part of the boot.img unlike older version which had a proper recovery partition).
2 - I feel you here. I felt scared as well the first time I had to deal with the beast. The only advise I can give you is: read, read and... read again. It's not so hard once you understand how it works. Also, you can still ask for some help if you are unsure, people here are really helpful!
Some users have bricked their devices and those got fixed. But as far as i remember, none that got hard bricked (I only read the Pixel XL forum since two months, so of course I may have missed some ).
3 - I'm a Pure Nexus user. Works very well, if you are looking for a stable alternative. :angel:
4 - I have never had this problem, sorry... But just take a look at this if you want to know the vendor.img is: https://plus.google.com/+JeanBaptisteQueru/posts/akHWypRNEn3
Every months with new security patch, a new vendor.img is included in the factory image or OTA.
If you install lineage OS from maybe April 2017 you'll likely have to flash N2G47E vendor.img which you can find here: https://developers.google.com/android/images inside the factory image archive.
If you install lineage OS April updates, you are fine with this vendor.img.
But in May, you'll have to flash a new vendor.img. Usually you will be notified by the ROM developer, which vendor.img is needed. Considering Google sometimes release two or three builds every months.
Hope that helps a little bit... :good:
Good luck...
I have Oneplus One with CyanogenMod 13.x. As of now, there's no CyanogenMod anymore, so I decided to leap to another ROM so I can keep using this toy for a while longer.
Now I have an issue with Paranoid Android 6.0.2 and 7.2.1 (two of the earliest latest roms in site). I'm stuck in bootloop.
I unlocked the bootloader, flashed TWRP in, flashed Paranoid Android. Both of these PA ROMs decided to get stuck in loading screen between device boot and OS. Should I flash GApps before booting, or should it boot without them? I have a feeling that it should. But if not, then I have another issue. I was dum-dum enough to download full open-GApps package. This results in "error 70" during GApps flash because system partition "has insufficient space". :silly:
Do I really have to go and sideload smaller GApps in there? Just for the record, I'm not flashing things first time. Only confirming my own speculations.
UPDATE #1: Never mind. I *think* I found the cause. I always rooted my phone after flashing. It seems that I had bad SuperSU and it messed up with the flash. I flashed LineageOS and decided to not root. It works neatly (well, as neatly as nightlies can work). Tomorrow I'll try same with PA and see how it goes. My guess is, that it will work just as neatly.