ZTE Nubia N3 NX608J

[VGerris]

This is the repit-dump.log from a ZTE Nubia N3 (NX608J) with android 7.1. I would like to be able to flash an Android 9 or 10 ROM from similar models like the Redmi Note 6 pro or Max 2. I need a working vendor partition for that, is that possible?

I used TWRP 3.2.1-0 compiled by nemo-nemo to run the dump by using fastboot boot recovery-image.img . Rom is official as supplied , perhaps modified with gapps by vendor. No repartitioning was done.

repit-dump.log

Thanks for your help!

[Lanchon]

your device is almost surely affected by #55.

I need a working vendor partition for that, is that possible?

REPIT cannot add or remove partitions.

[VGerris]

Hi,

Thank you for the update. Is there any way to test this, besides bricking the device, like some kind of debugging? Huawei is known to lock things down, so perhaps it is not Qualcomm? Would be great to figure out. I have two phones of this model, I can consider trying it out anyway if the risk is not too high. There is barely any economical value on it when stock on Android 7... Thank you!

On Tue, Jun 27, 2023, 03:35 Lanchon @.***> wrote:

your device is almost surely affected by #55 https://github.com/Lanchon/REPIT/issues/55.

I need a working vendor partition for that, is that possible?

REPIT cannot add or remove partitions.

— Reply to this email directly, view it on GitHub https://github.com/Lanchon/REPIT/issues/107#issuecomment-1608114297, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAGB3CN5P6TSB3NG3UKUUUDXNHP73ANCNFSM4OUPGHZQ . You are receiving this because you authored the thread.Message ID: @.***>

[Lanchon]

it is not huawei, its qualcomm. they provide devel boards for the chips and a customized complete android distro, including bootloaders, in source form. these BLs check the PT signature if configured to, and i suppose checks are on by default.

given that this phone is 2018 and that qualcomm started enforcing PT signatures around 2014 i think, this phone PT is 99% likely to be protected.

porting android is more than running a GSI. different android versions require different kernel versions, and the kernel is of course not included in GSI images. running an newer kernel on an old device is serious porting work, as google and OEMs don't mainline their kernel patches.

if your view is utilitarian, just throw away the phones and buy community supported phones. if you want to learn, you can try porting android to your device. note that this is a lot of work, and will cost you much more than the value of a couple of old phones.

[VGerris]

Hi,

Thank you very much for the elaborate response and explanation, also on XDA. I mainly wanted to give it a go to port / upgrade to learn and see how far I got. I like the hardware and thought it would be great to run a newer android. I have been compiling kernels and porting some recoveries, all not that complicated. I was wondering how much work and complicated it would be to have a kernel and recovery with LVM support as you mentioned. Judging from your description it sounds like a lot of work and quite complicated to make it into something useful. Is there info on LVM support and how to approach that? Could be cool to give it a go. Time is a limitation I have unfortunately, but with some others it might be cool to give it a try ! Thanks again!

On Tue, Jun 27, 2023, 06:07 Lanchon @.***> wrote:

it is not huawei, its qualcomm. they provide devel boards for the chips and a customized complete android distro, including bootloaders, in source form. these BLs check the PT signature if configured to, and i suppose checks are on by default.

given that this phone is 2018 and that qualcomm started enforcing PT signatures around 2014 i think, this phone PT is 99% likely to be protected.

porting android is more than running a GSI. different android versions require different kernel versions, and the kernel is of course not included in GSI images. running an newer kernel on an old device is serious porting work, as google and OEMs don't mainline their kernel patches.

if your view is utilitarian, just throw away the phones and buy community supported phones. if you want to learn, you can try porting android to your device. note that this is a lot of work, and will cost you much more than the value of a couple of old phones.

— Reply to this email directly, view it on GitHub https://github.com/Lanchon/REPIT/issues/107#issuecomment-1608383987, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAGB3CKPNRPDFOJGBZE5EADXNIBY7ANCNFSM4OUPGHZQ . You are receiving this because you authored the thread.Message ID: @.***>

[Lanchon]

assuming a port for a very similar device does not exist...

you'd start by porting the kernel. for that you very much need the current OEM kernel sources. you have the right to it but not all manufacturers comply with GPL. with that, you'd select a tree from which you think the OEM worked to produce the OEM sources (mainline, google android kernel, codeaurora, etc). now you'd start to compare the OEM sources with different points in tree history, and finally choose a specific point as the closest.

there will be many differences, such as many cherripicked commits or out of tree changes by the OEM. try to express the OEM sources as some tree state + cherrypicks as much as possible, with minimum OEM changes. this is an art form.

now you have a maintained tree + some OEM changes. so you can "fastforward" the tree to the necessary version for your new android and port the OEM changes (hopefully few) to the new tree state. you should end up with a newer kernel with the right drivers for your device.

before starting, check that building the OEM sources actually produces a working kernel that works with the OEM system or a GSI. after finishing kernel work, you should end with a newer kernel that runs the old system, as userland compatibility is almost never broken on linux. at this point, a newer GSI should work. now its time to start porting android itself.

LVM is a really simple mainlined device stack. just turning on a flag during kernel compile will include it. for simplicity it should be linked in and not a loadable module, given that you'll probably need it to access the partition where the modules are.

btw, loadable modules are very much a part of the kernel and not the userland. building a new kernel requires that you also build all loadable modules, sources of which the OEM hopefully gave you.