Building LineageOS 18.1 for device that only supports 19.1 - LineageOS Questions & Answers

I desperately need to get my work profile working on my new OnePlus Nord N200 5G (dre), and I've just discovered that it is apparently impossible to create a new work profile on LineageOS 19.1. It seems, however, that a work profile set up on 18.1 will continue to work after a dirty flash to 19.1. Thus, I'm hoping that I can install 18.1 on my device, setup of the work profile, and immediately dirty flash 19.1. I won't really need a fully functional build of 18.1; just something that will boot up and allow me to create the work profile before I dirty-flash 19.1.
In order to do this, I need to build LineageOS 18.1 for this device. Unfortunately, only 19.1 has ever been supported.
I have a build environment that is currently building 19.1, just as a test. I also have the most recent Android 11 vendor firmware, from which I should be able to extract any required proprietary files.
I'm really missing 2 things:
The list of proprietary files that I should extract from the vendor's firmware. (I have the 19.1 list, but I assume that it won't work.)
What other files do I need to create/edit to add the device to the 18.1 build tree.
Is there a guide somewhere that walks through the process?

Ah, @ipilcher I was hoping someone smarter than me would answer your question. It would do so much for all the Android forks, and Android in general. I've asked the same question to several devs on IRC and they all basically say "no, no easy way to explain it...". My kingdom for a guide that doesn't involve the School of Hard Knocks all the way through.
So in full disclosure, as of today, I haven't managed to build a ROM on an unsupported phone- but I have done full builds from source with LOS and Calyx (with bootloader relocking on the latter) using existing projects.
But... I would assume from others that have gotten the AOSP "Generic Stock Images" to run on various random phones that there isn't really that much you /need/ for what you want to do; you don't need a functioning modem, fingerprint sensor, camera, GPS, notification LED, battery management, etc.
From what I understand, if your vendor follows android specs, all that would be in one of the vendor partitions anyway. From the builds I've done (mostly Motorola and OnePlus devices) the proprietary files (in "stock" LOS) are sourced from a few different places, possibly from generic chipset support (the same tree is used for multiple devices by a manufacturer and/or chipset). One LOS 18.1 build had a whole bunch of (proprietary) files in it that weren't even in the stock rom image! If you are sourcing from stock firmware (OTA off OP site or one of the MSM images here) I'd assume that half the partition is spyware or manufacturer test/calibration tools, and the other half are the drivers you want for a fully functional phone- which, luckily, it seems you can fall short of without failure, so you can probably be pretty lax about picking.
The bootloader chain seems to have a lot of drama between Android 11, 12, and 13 (requiring flashing other partitions outside of the normal system ones)- I've never had a N200 to play with to know if it is high drama, too.
Hey, at least you're using a OnePlus with QC chipset, so EDL can bail you out of pretty much anything you do wrong. I hard-bricked a $500 Pixel and learned how absolutely hideous Google support is- never buying one of those again.
Hope that helps.

SomeRandomGuy said:
Ah, @ipilcher I was hoping someone smarter than me would answer your question. It would do so much for all the Android forks, and Android in general. I've asked the same question to several devs on IRC and they all basically say "no, no easy way to explain it...". My kingdom for a guide that doesn't involve the School of Hard Knocks all the way through.
So in full disclosure, as of today, I haven't managed to build a ROM on an unsupported phone- but I have done full builds from source with LOS and Calyx (with bootloader relocking on the latter) using existing projects.
But... I would assume from others that have gotten the AOSP "Generic Stock Images" to run on various random phones that there isn't really that much you /need/ for what you want to do; you don't need a functioning modem, fingerprint sensor, camera, GPS, notification LED, battery management, etc.
From what I understand, if your vendor follows android specs, all that would be in one of the vendor partitions anyway. From the builds I've done (mostly Motorola and OnePlus devices) the proprietary files (in "stock" LOS) are sourced from a few different places, possibly from generic chipset support (the same tree is used for multiple devices by a manufacturer and/or chipset). One LOS 18.1 build had a whole bunch of (proprietary) files in it that weren't even in the stock rom image! If you are sourcing from stock firmware (OTA off OP site or one of the MSM images here) I'd assume that half the partition is spyware or manufacturer test/calibration tools, and the other half are the drivers you want for a fully functional phone- which, luckily, it seems you can fall short of without failure, so you can probably be pretty lax about picking.
The bootloader chain seems to have a lot of drama between Android 11, 12, and 13 (requiring flashing other partitions outside of the normal system ones)- I've never had a N200 to play with to know if it is high drama, too.
Hey, at least you're using a OnePlus with QC chipset, so EDL can bail you out of pretty much anything you do wrong. I hard-bricked a $500 Pixel and learned how absolutely hideous Google support is- never buying one of those again.
Hope that helps.
Click to expand...
Click to collapse
I just wanted to close this out and thank you for your response.
Fortunately, the issue that was driving me to try to build 18.1 for this device (https://gitlab.com/LineageOS/issues/android/-/issues/4983) has been diagnosed, and I was able to work around it.
Of course, I just realized that my wife's new Moto G 5G is an XT2213-3, not an XT2113-3, so maybe I'll revisit this subject some day.

Welllp... at the risk of being accused of insufficent RTFMing, I did stumble across this article the other day that nicely outlined a few things that I didn't know:
[GUIDE] [how to] CREATE OWN ROM [FOR ANY ANDROID DEVICE] [FOR N00B] [EASIEST METHODS]
NOTE: THIS GUIDE WILL WORK ANY ANDROID DEVICE BUT HAS FEW EXTRA PRE-SUGGESTED LINKS FOR GALAXY ACE PLUS USERS. Special Thanks to - dsixda for his awesome kitchen. Please Hit Thanks button for him. inspired by isidromxz's thread. Please kindly...
forum.xda-developers.com
It isn't exactly "build your own device tree on top of AOSP" which I think is what you wanted and I certainly still do... but it might help someone else who finds /this/ thread with the same question. It also ends with the wonderful quote "This thread is 10 yo. Leave it alone. things have changed" - which is pretty solid advice IMHO.
Ah well, if it wasn't a challenge, there would be no reward, eh?

Related

Questions about the new project Treble on Android

Hi guys.
I have some questions about the new android treble feature.
The way it is advertised, it seems to be the END of the fragmentation problem on android. But i dont know if it is over advertised.
1) "The A/B partition system is only for seamless update."
I've read this on the internet and the only difference between A and A/B is that A will update like older androids while A/B will be with the phone turned on with only a reboot being necessary. This shouldn't be something that will make treble more or less useful for the end-users.
2) Why I dont see people talking about system repartitioning the phone to enable A/B partition? Most phones have 32GB, with most being over 20GB in /data. Why not just repartition 1GB to enable A/B partition?
3) "The treble updates will still be released by the phone's manufaturer."
Really? I dont know if the updates are comming from google or phone manufacturer. Can someone confirm?
It does not make any sense to try to stop the fragmentation issue by still leaving the update task on the manufacturer's side...
After some time they will stop updating anyway.
4) "Android treble will be useless if the phone does not come with native treble support."
I really don't understand this. Ive read this in reddit I believe. But installing a custom treble supported rom wouldn't be easier to perform updates on the custom rom?
My thoughts are that the updates are going to be handled by google. By doing so, we could install any custom rom and forget it because "google will update it from now on". This makes sense to me. If treble is not heading to this, then they are doing it wrong...
IMO, I think that treble would be great if users could perform:
Get your old android phone's manufaturer proprietary files;
Save those files in a vendor folder;
Execute them in android 8 and on;
Leading every android device to the latest android version.
(This in a perfect world. I know this option is a dream.)
BUT, I believe this could be an option at least for the devices that received the oreo update (because they received the "updated proprietary files" that would work for the new android treble and by consequence, on all new android versions.
If so is true, the best that could happen is for custom rom devs, create their roms by packing the vendor files, integrating with AOSP and linking the updates from the google server. Done, phone will be "forever updated".
Any comments on those, please?
Thank you.
facsi2 said:
Hi guys.
I have some questions about the new android treble feature.
The way it is advertised, it seems to be the END of the fragmentation problem on android. But i dont know if it is over advertised.
1) "The A/B partition system is only for seamless update."
I've read this on the internet and the only difference between A and A/B is that A will update like older androids while A/B will be with the phone turned on with only a reboot being necessary. This shouldn't be something that will make treble more or less useful for the end-users.
2) Why I dont see people talking about system repartitioning the phone to enable A/B partition? Most phones have 32GB, with most being over 20GB in /data. Why not just repartition 1GB to enable A/B partition?
3) "The treble updates will still be released by the phone's manufaturer."
Really? I dont know if the updates are comming from google or phone manufacturer. Can someone confirm?
It does not make any sense to try to stop the fragmentation issue by still leaving the update task on the manufacturer's side...
After some time they will stop updating anyway.
4) "Android treble will be useless if the phone does not come with native treble support."
I really don't understand this. Ive read this in reddit I believe. But installing a custom treble supported rom wouldn't be easier to perform updates on the custom rom?
My thoughts are that the updates are going to be handled by google. By doing so, we could install any custom rom and forget it because "google will update it from now on". This makes sense to me. If treble is not heading to this, then they are doing it wrong...
IMO, I think that treble would be great if users could perform:
Get your old android phone's manufaturer proprietary files;
Save those files in a vendor folder;
Execute them in android 8 and on;
Leading every android device to the latest android version.
(This in a perfect world. I know this option is a dream.)
BUT, I believe this could be an option at least for the devices that received the oreo update (because they received the "updated proprietary files" that would work for the new android treble and by consequence, on all new android versions.
If so is true, the best that could happen is for custom rom devs, create their roms by packing the vendor files, integrating with AOSP and linking the updates from the google server. Done, phone will be "forever updated".
Any comments on those, please?
Thank you.
Click to expand...
Click to collapse
1) A/B devices also have a thing called "skip_initfs". In older devices, which is indeed A-only, we have the kernel ramdisk in boot partition. But in A/B devices, the boot ramdisk is only for recovery - when booting the system, the system actually contains the initramfs instead and it gets mounted to / (rootfs) instead of /system.
In short, A/B devices have init and ramdisk all in the system partition. This means Treble ROM's for A/B devices can easily have their own initfs, which makes things a little easier.
2) It also needs bootloader (either SBL or ABOOT, can't remember) support for AB, and these are almost never open source.
3) Treble allows OEM's (the hardware, e.g. Qualcomm) and the ODM (the brand, e.g. Xiaomi) to work independently. Treble provides a contract that the ODM and OEM must each pass verification black-box style, allowing independent development without reliance on the other. Best analogy I can think of is how drivers for Windows work - they don't need to know about what edition of Windows or model of PC it is; they just need to follow standards when making their hardware drivers - and if they do they can be sure that it should work with any other software.
Theoretically, Android P GSI should work straight away on a Treble-enabled Oreo phone. Maybe only with minimal changes - still too early to say. But this is the idea of it.
4) Not entirely true. Unofficial Treble (e.g. like we did for Mi A1) allows us to use GSI's thanks to Phh's work. And unlike many other official Treble devices, we have 100% compatibility with GSI's thanks to the fact that that we can fix GSI stuff on our own end. Many Treble devices are not properly "GSI-ready" vendor implementations, a common theme is that they still put essential Camera stuff in their system ROM instead of vendor (Treble verification I guess doesn't care about Camera support, sadly).
Updates from Google directly is a different program entirely; that's only for devices in Android One program.
Treble support with blobs from before Oreo is practically impossible. They need to be either modified and recompiled with the VNDK standards, or a very smart person needs to shim them. Don't ever expect a pre-Oreo device without source code to be Treble compatible - it's a monumental task that basically requires reverse-engineering the proprietary blobs. If you don't find that useful, then those are the breaks - this stuff was only introduced relatively recently. Treble is not a time machine
But again: Treble does NOT mean "updates directly from Google". That's only for official Android One devices.
Maybe one day Google will have an official thing akin to GSI. But not today. As it is, GSI - generic Treble ROM's - are the love child of Phh, there is no such thing as official updates directly from Google outside of Android One (and Pixel ofc).
As for your other speculation, it's mostly redundant - apparently, all devices that launch with Android P are required to have Treble. If I remember correctly. If the pre-P device is popular and open enough, then yeah you will get unofficial Treble (like we did with Mi A1). But that's all up to the device community. But just to reiterate one more time - this does NOT mean updates will come directly from Google.
In case you're wondering why the updates won't come directly from Google (and I predict that this will never be the case, outside of Android One program devices) - simple fact is because Android != Google. Google will never force Android vendors to use Google servers or update channel because Android itself is a very open platform; Treble is an architectural change regarding HAL abstraction - not an enforcement of Google doctrine. It'd be absurd if they did pull a stunt like that; would be like GNU saying "hey Ubuntu, Debian, and all you other guys - you have to use GNU update servers now, all your own servers are not allowed".
Many thanks, Dan. The smart thing to do is hope a new good phone gets released with latest android. Then we can keep if for a longer time thanks to treble. Planned obsolescence sucks.
Just for the curiosity, I own a moto z play and a galaxy s5 (just because of the IR blaster).
facsi2 said:
Many thanks, Dan. The smart thing to do is hope a new good phone gets released with latest android. Then we can keep if for a longer time thanks to treble. Planned obsolescence sucks.
Just for the curiosity, I own a moto z play and a galaxy s5 (just because of the IR blaster).
Click to expand...
Click to collapse
I have to say I am very glad I got the Mi A1. They did take a while to release the source code, but being an Android One device it was already "Treble-ready" - the HAL and vendor files were already binderized, as per requirements for Treble (that's the most difficult part in getting a Treble device).
My next device may be the A2, or a Pixel, it really depends on how long I keep this device (probably a while yet, since it's definitely getting P officially even).
And yeah, being a Xiaomi, they always have IR
CosmicDan said:
In case you're wondering why the updates won't come directly from Google (and I predict that this will never be the case, outside of Android One program devices) - simple fact is because Android != Google. Google will never force Android vendors to use Google servers or update channel because Android itself is a very open platform; Treble is an architectural change regarding HAL abstraction - not an enforcement of Google doctrine. It'd be absurd if they did pull a stunt like that; would be like GNU saying "hey Ubuntu, Debian, and all you other guys - you have to use GNU update servers now, all your own servers are not allowed".
Click to expand...
Click to collapse
I think in google (Android) updates being sent by google itself as it is the one who releases android security patches.
I took a look on Mi A1. it only misses NFC. I might wait another year to change my phone.
thanks
facsi2 said:
I think in google (Android) updates being sent by google itself as it is the one who releases android security patches.
I took a look on Mi A1. it only misses NFC. I might wait another year to change my phone.
thanks
Click to expand...
Click to collapse
What do you mean? Security updates can't be sent directly from Google, because every device is different and usually heavily modified at the source code level.
The whole point of Android One is that they are relatively pure, bit they still need to compile seperate security updates for different devices.
In short, there's no such thing as generic firmware, every firmware and therefore every update is still device-specific. Excluding GSI of course, which is not an official thing remember.
True about NFC, I never used it so forgot.
CosmicDan said:
What do you mean? Security updates can't be sent directly from Google, because every device is different and usually heavily modified at the source code level.
The whole point of Android One is that they are relatively pure, bit they still need to compile seperate security updates for different devices.
In short, there's no such thing as generic firmware, every firmware and therefore every update is still device-specific. Excluding GSI of course, which is not an official thing remember.
True about NFC, I never used it so forgot.
Click to expand...
Click to collapse
Isnt google responsible for those security updates in a general ROM and then manufacturers have to port that update for their devices?
https://source.android.com/security/bulletin/
What I meant was with treble, we could update our android directly from google, without having to wait for the manufacturer. Pretty much as how windows update work.
facsi2 said:
Isnt google responsible for those security updates in a general ROM and then manufacturers have to port that update for their devices?
https://source.android.com/security/bulletin/
What I meant was with treble, we could update our android directly from google, without having to wait for the manufacturer. Pretty much as how windows update work.
Click to expand...
Click to collapse
Yes, that's how they work.
But no, we cannot. As I said multiple times already - there is no such thing as a generic device to Google. GSI is created by Phh. Generic updates simply do not exist.
If Google ever makes an official GSI of some sort, or Phh works with someone to make an OTA system for his GSI's, then it could happen. But I wouldn't hold my breath for either of those things - the first one I already explained why it isn't feasible yet, and the second one costs too much money.
CosmicDan said:
Yes, that's how they work.
But no, we cannot. As I said multiple times already - there is no such thing as a generic device to Google. GSI is created by Phh. Generic updates simply do not exist.
If Google ever makes an official GSI of some sort, or Phh works with someone to make an OTA system for his GSI's, then it could happen. But I wouldn't hold my breath for either of those things - the first one I already explained why it isn't feasible yet, and the second one costs too much money.
Click to expand...
Click to collapse
I am confused. What is android AOSP rom then?
facsi2 said:
I am confused. What is android AOSP rom then?
Click to expand...
Click to collapse
https://en.m.wikipedia.org/wiki/Android_(operating_system)#AOSP
Read the "Development" paragraph. The following "Update schedule" section goes on the explain the history and situation of how updates work, basically the same as what I've already said.
got it. Many thanks.
Treble will be really useful for the users.
Btw, do you know if the source code released for moto z play the "same code" available for mi a1? I wonder if it is possible to do the same update you did on A1 on the ZP...
facsi2 said:
got it. Many thanks.
Treble will be really useful for the users.
Btw, do you know if the source code released for moto z play the "same code" available for mi a1? I wonder if it is possible to do the same update you did on A1 on the ZP...
Click to expand...
Click to collapse
Useful for users and developers!
I don't know what you mean by that question. By "same update" do you mean repartition for Treble?
CosmicDan said:
Useful for users and developers!
I don't know what you mean by that question. By "same update" do you mean repartition for Treble?
Click to expand...
Click to collapse
I ended up editing the phrase before sending it and I didn't fully checked it:
Do you know if the source code released for moto z play IS the "same code" available for mi a1? I wonder if it is possible to do the same update you did on A1 on the ZP
What I am asking is if the source code available for Moto z play have the contents to be able to port treble as you did on mi a1. I don't know by looking the contents on GitHub, if the code available is complete for that job.
Thanks
facsi2 said:
I ended up editing the phrase before sending it and I didn't fully checked it:
Do you know if the source code released for moto z play IS the "same code" available for mi a1? I wonder if it is possible to do the same update you did on A1 on the ZP
What I am asking is if the source code available for Moto z play have the contents to be able to port treble as you did on mi a1. I don't know by looking the contents on GitHub, if the code available is complete for that job.
Thanks
Click to expand...
Click to collapse
To port Treble to a device, these things are needed:
1) All the source code required to build standard AOSP, e.g. device tree and kernel. If you already have custom ROM's working f well for you device, this will likely be true.
2) Binderized vendor HAL. If you have *official* Oreo update from Motorola, this MAY be true. Manual inspection of compatibility_matrix.xml is required here, if everything in there matches the Treble requirements as listed on Android Developers then chances are it is ready.
3) An unused partition of ~500MB or more for Vendor, or the ability to repartition the device (many Qualcomm devices are standard GPT partitioned eMMC these days, if it is then it's possible).
That's a summary of the requirements. Obviously some technical investigation is required. Forward that info to any device developers who are interested in the project.
I read somewhere that device to be even updated to Pie have to have enabled Treble? Oreo required it only for launched devices and Pie require it from ALL devices.
Is it right or not? Unfortunately I cannot find it again
CosmicDan said:
To port Treble to a device, these things are needed:
1) All the source code required to build standard AOSP, e.g. device tree and kernel. If you already have custom ROM's working f well for you device, this will likely be true.
2) Binderized vendor HAL. If you have *official* Oreo update from Motorola, this MAY be true. Manual inspection of compatibility_matrix.xml is required here, if everything in there matches the Treble requirements as listed on Android Developers then chances are it is ready.
3) An unused partition of ~500MB or more for Vendor, or the ability to repartition the device (many Qualcomm devices are standard GPT partitioned eMMC these days, if it is then it's possible).
That's a summary of the requirements. Obviously some technical investigation is required. Forward that info to any device developers who are interested in the project.
Click to expand...
Click to collapse
About re-partitioning android device, is there a tool, command or anything universal to all the phones, like how in linux you can re-partition what and how you want. For example, I never saw a re-partition "mod" for samsung devices (ex. to give more space on /system). There is only one reason I can think of.
If samsung "download mode" is stored on a read-only pre-programmed chip, then re-partition should be no problem. If anything goes wrong, just flash stock firmware with CSC or flash official .PIT file.
If that is the case then there are no risks in re-partitioning a device.
There is a tool that can edit .PIT files, but what if someone wipes the bootloader partition?
Would "download mode" still be there for a roll-back, or would the device be permenantly bricked?
Is re-partition-ing safe?
If it is, then why doesn't any 3rd party recovery have an option for that, kinda like GPARTED. Is it impossible or what?
And if bootloader gets wiped, is there a way to re-program the device to the working order?
Sry for so many questions. Already tried to search but never got a straight-forward answer.
Shadow7107 said:
About re-partitioning android device, is there a tool, command or anything universal to all the phones, like how in linux you can re-partition what and how you want. For example, I never saw a re-partition "mod" for samsung devices (ex. to give more space on /system). There is only one reason I can think of.
If samsung "download mode" is stored on a read-only pre-programmed chip, then re-partition should be no problem. If anything goes wrong, just flash stock firmware with CSC or flash official .PIT file.
If that is the case then there are no risks in re-partitioning a device.
There is a tool that can edit .PIT files, but what if someone wipes the bootloader partition?
Would "download mode" still be there for a roll-back, or would the device be permenantly bricked?
Is re-partition-ing safe?
If it is, then why doesn't any 3rd party recovery have an option for that, kinda like GPARTED. Is it impossible or what?
And if bootloader gets wiped, is there a way to re-program the device to the working order?
Sry for so many questions. Already tried to search but never got a straight-forward answer.
Click to expand...
Click to collapse
No, nothing is standard when it comes to embedded systems (which our devices are). By "standard on Linux", you must mean "Standard on x86-based Linux" - which is mostly all MBR or GPT (but even then there are other less-common standards)
But as I said - many Qualcomm devices are in fact standard GPT, you can just use gdisk (a fork of fdisk which is better choice for GPT partition maps).
Repartitioning is relatively safe on SOME devices because they have an emergency bootloader/downloader which is on it's own EEPROM and not the eMMC or whatever. You will have to research the device for yourself to see if it has any "unbrick" capability. Again, many qualcomm devices have what is called "EDL mode" - EDL mode is still possible even if you "cat /dev/null > /dev/block/mmcblk0" for example - albeit you may need to disassemble the device to access test point to get it to be kicked into there.

Porting LineageOS to an Unsupported Device (with no similar devices)

Hi,
I am trying to port LineageOS to an unsupported device, an IBall Slide Cuddle A4.
Here's the guide I'm following : https://fat-tire.github.io/porting-intro.html
This is the part where I need help:
"Add the blobs to the vendor/ directory
Once you have a working recovery, it's now time to get CyanogenMod building and working.
The first thing to do is to get all the proprietary, binary blobs into the vendor/ folder, along with a .mk file that will include them in the final build.
This requires three steps:
Create extract-files.sh and setup-makefiles.sh scripts to pull those blob files from the device using adb and put them in the right /vendor/ directory. There are plenty of examples available for other devices.
Create an .mk Makefile to copy those files to the $OUT folder during the build process and put them in the right place. Again, use other devices as a guide for what this Makefile should look like. An example filename might be BoardConfigVendor.mk
Make sure that the Makefile you just created is included from your main BoardConfig.mk via a command such as -include vendor/[vendor]/[codename]/BoardConfigVendor.mk. Again, existing devices can illustrate how this is done.
Now revise the device/ directory
Since you have a working recovery, go back and start modifying the files in the device/ folder. As always, use other similar devices as a reference.
You now have a easy means to do backups and test your builds. So start tweaking the device folder itself, and see if you get it to boot... Once you do, from there its a matter of building and supporting the various parts and peripherals, one-by-one. "
Click to expand...
Click to collapse
Q #1: Where all should I look on my device for the proprietary blobs, and what do they look like? Can I manually extract them out of my existing ROM and paste them into the proper folder of the new one?
Q #2: What do I modify in the device/ folder?
Q #3: What does it mean to "build and support the various parts and peripherals" Does this mean to add the necessary drivers? If so, can I get these drivers from the stock ROM?
The reason I have to ask this here is because my device has NO similar LineageOS-supported devices with the same chipset for me to refer to. My tablet has a MediaTek MT8392 chipset, and I couldn't find any supported devices with an MT8392 (or an MT6592, which is very similar). Also, there is NO code available from the manufacturer, at all. The only resource I have is a stock ROM.
Are there any other ways in which a device can be similar enough for me to use as reference?
It would be really nice if someone could provide links to articles explaining the above 3 things, or if someone has already gone through this process, share their experience.
Also, will my kernel (v3.4.67) be compatible with the latest LineageOS 16 / Android 9 or will I have to build an earlier version?
I am very new to Android development, but that doesn't mean that I can't learn!
That's a hard task for getting started. A mtk device with no twrp available. I recommend to start with low hanging fruits. Like buying an old phone with dropped lineageOS support and building an updated version.
I understand that it is quite difficult. So instead of doing a full port myself, I am now trying the method of taking an image made for a similar MTK device and transferring the device-specific files from my stock ROM, as shown in the following guide:
https://www.techubng.com/2017/09/how-to-port-lineage-os-14-nougat-rom-on-mtk.html
It says:
"From System/lib/hw: Delete all mt6572.so blobs and replace with these blobs: DOWNLOAD BLOBS
Now copy these files from stock to port:
System/lib/hwcomposer.mt65xx.so
System/lib/gralloc
System/lib/lib.audio.primary.so
Systemlib/lib.mali.soS
System/Etc
System/lib/libcameracustom.so
System/etc/firmware
System/lib/libfeatureio.so
boot/kernel
boot/unventd.rc (only if you are getting stuck at logo)
boot/Replace only camera lines under #Camera from stock boot.img init.rc to init.mt6572.rclib/libcamdrv.solib/libcamalgo.so"
But my stock ROM does not have any of the files he listed uner /system/lib! Can I ignore these files, or is there some other place where these files could be? (I checked /vendor)
Also, what about all the other files in /system/lib? Which ones are device-specific and does anything else need to be copied into the new ROM?
As for the TWRP, I have found tools like Easy Magic TWRP Installer ( https://forum.hovatek.com/thread-5162.html ) which will automatically do the porting given the boot.img and recovery.img from the stock ROM. Are these safe to use, as long as I provide the right info to the tool?
I want to use LineageOS on this tablet because the stock OS has some annoying bugs and is quite old (Android 4.4.2) considering how recent the tablet is and how much capability the tablet's hardware has. The manufacturer (IBall) has provided no updates at all.
Lineage OS on Samsung Galaxy J3 Achieve (SM-J337P)
Can I pay a developer to make a working ROM to put Lineage OS on the Samsung Galaxy J3 Achieve (SM-J337P) ?
If so, how do I find a developer who can do it?
hey, i have a sm-t280 that have a similar supported device. how i port to it?
i have a sm-t280 that i wan't to update the android. the only exit i found it's build linegeos or aosp for it, can anyone help me?
here is the source tree:
vendor tree: huttps://github.com/gtexswifi/android_vendor_samsung_gtexswifi
-----
device tree: huttps://github.com/gtexswifi/android_device_samsung_gtexswifi
-----
kernel tree: huttps://github.com/pfent/sm-t280-kernel
[i writed huttps because i don't have posted 10 posts already]
Porting similar device mt6750t
vinaypundith said:
I understand that it is quite difficult. So instead of doing a full port myself, I am now trying the method of taking an image made for a similar MTK device and transferring the device-specific files from my stock ROM, as shown in the following guide:
https://www.techubng.com/2017/09/how-to-port-lineage-os-14-nougat-rom-on-mtk.html
It says:
"From System/lib/hw: Delete all mt6572.so blobs and replace with these blobs: DOWNLOAD BLOBS
Now copy these files from stock to port:
System/lib/hwcomposer.mt65xx.so
System/lib/gralloc
System/lib/lib.audio.primary.so
Systemlib/lib.mali.soS
System/Etc
System/lib/libcameracustom.so
System/etc/firmware
System/lib/libfeatureio.so
boot/kernel
boot/unventd.rc (only if you are getting stuck at logo)
boot/Replace only camera lines under #Camera from stock boot.img init.rc to init.mt6572.rclib/libcamdrv.solib/libcamalgo.so"
But my stock ROM does not have any of the files he listed uner /system/lib! Can I ignore these files, or is there some other place where these files could be? (I checked /vendor)
Also, what about all the other files in /system/lib? Which ones are device-specific and does anything else need to be copied into the new ROM?
As for the TWRP, I have found tools like Easy Magic TWRP Installer ( https://forum.hovatek.com/thread-5162.html ) which will automatically do the porting given the boot.img and recovery.img from the stock ROM. Are these safe to use, as long as I provide the right info to the tool?
I want to use LineageOS on this tablet because the stock OS has some annoying bugs and is quite old (Android 4.4.2) considering how recent the tablet is and how much capability the tablet's hardware has. The manufacturer (IBall) has provided no updates at all.
Click to expand...
Click to collapse
I saw Lineage OS 16 for HomTom S99….
I have HomTom HT70 with same Chipset of HomTom S99 MT6750T….
Im trying to read and follow carefully your guide but still i have bootloop..
Is it Possible to Port it to Homtom HT70 so we can have Android 9 too??
https://forum.xda-developers.com/ge...tom-ht70-6-0-hd-189-mt6750t-4gb-64gb-t3803052
hey, I have a samsung j7 j700t (t-mobile), and if it has a similar version that is the j700f / h / m, but I have tried it and it does not work for me. What do I have to do to make it work for me? Help me please!!!
AlexRsl1999 said:
hey, I have a samsung j7 j700t (t-mobile), and if it has a similar version that is the j700f / h / m, but I have tried it and it does not work for me. What do I have to do to make it work for me? Help me please!!!
Click to expand...
Click to collapse
Different processsor. J700t is Qualcomm. J700f is exynos
kurtn said:
Different processsor. J700t is Qualcomm. J700f is exynos
Click to expand...
Click to collapse
But my processor is Exynos 7580 to 1.5GHz
AlexRsl1999 said:
But my processor is Exynos 7580 to 1.5GHz
Click to expand...
Click to collapse
If you haven't already, I'd recommend checking in Geekbench as there's a lot of conflicting information on the web. Usually, Samsung only puts the Exynos chip in GSM only devices sold outside the US.
There is a custom rom for a variant of my device (Huawei g760) please how can i make it work on my device (Huawei g7-UL20) they both have the same specs and processor everything is the same
YomaAroriode said:
There is a custom rom for a variant of my device (Huawei g760) please how can i make it work on my device (Huawei g7-UL20) they both have the same specs and processor everything is the same
Click to expand...
Click to collapse
Have you unlocked the bootloader, before huawei stopped allowing it?
kurtn said:
Have you unlocked the bootloader, before huawei stopped allowing it?
Click to expand...
Click to collapse
Yes my bootloader is unlocked
kurtn said:
Have you unlocked the bootloader, befes ore huawei stopped allowing it?
Click to expand...
Click to collapse
Yes my bootloader is unlocked
I followed this guide: https://forum.xda-developers.com/t/guide-porting-twrp-without-source.3843473/
And ported the twrp recovery made for huawei g760 to my g7-UL20
Now how do i modify the custom rom for it to work on my device. Please i need your help!!
kurtn said:
That's a hard task for getting started. A mtk device with no twrp available. I recommend to start with low hanging fruits. Like buying an old phone with dropped lineageOS support and building an updated version.
Click to expand...
Click to collapse
Hi there, I just noticed this reply you had made and I have a question about a device that may have had Lineage support.
What I would like to do, once I have my new phone that is, is to take my current phone Motorola Edge+ (2020) and turn it into a small Lineage tablet.
However, there is one slight problem with this, and that is rhat there is currently no Lineage support for this device, but there is support for it's younger brother the Motorola Edge (2020).
Now I do know that porting is possible between devices, but I've seen a lot of guides says they should have the certain similarities such as processor and such.
However the CPU, GPU and Chipset are slightly different (Same brands though), will this pose a problem in porting?
I of course do realize that I will of course need the proprietary blobs from Motorola for this device and I believe I have found them.
Finally, I am curious if you know of any up to date guides on porting? I will of course continue researching myself, however I thought I would make an enquiry anyway.
Any help you may be able to provide would be greatly appreciated.
Bloodstalker
Bloodstalker82 said:
Hi there, I just noticed this reply you had made and I have a question about a device that may have had Lineage support.
What I would like to do, once I have my new phone that is, is to take my current phone Motorola Edge+ (2020) and turn it into a small Lineage tablet.
However, there is one slight problem with this, and that is rhat there is currently no Lineage support for this device, but there is support for it's younger brother the Motorola Edge (2020).
Now I do know that porting is possible between devices, but I've seen a lot of guides says they should have the certain similarities such as processor and such.
However the CPU, GPU and Chipset are slightly different (Same brands though), will this pose a problem in porting?
I of course do realize that I will of course need the proprietary blobs from Motorola for this device and I believe I have found them.
Finally, I am curious if you know of any up to date guides on porting? I will of course continue researching myself, however I thought I would make an enquiry anyway.
Any help you may be able to provide would be greatly appreciated.
Bloodstalker
Click to expand...
Click to collapse
Install a gsi
GSI Rom´s For Motorola Edge +?
Hi for everyone! I have been looking for custom rom for our Motorola Edge +. But I haven't found any yet. However there is the option of the GSI rom's, this smartphone has an A / B system partition. 64-bit ARM CPU architecture. (information...
forum.xda-developers.com
Thank you very much for your reply. I had seen that I could uae a GSI, however I had not realized it is actually possible with Lineage. I clearly misread the topic.
kurtn said:
That's a hard task for getting started. A mtk device with no twrp available. I recommend to start with low hanging fruits. Like buying an old phone with dropped lineageOS support and building an updated version.
Click to expand...
Click to collapse
yo i have a phone with an unofficial version of lineageos 15.1 (Lenovo K8 Note) how would i go about building that newer version

Android 10 for G5S (Montana) ?

I know the G5S is the forsaken of the family G5 and I know too its bad to ask for ETAs, but I would like to know if have any possibility to make Android 10 real for this device.
Thx for attention and sorry if a make something wrong making this post I'm just curious.
1ZeeN said:
I know the G5S is the forsaken of the family G5 and I know too its bad to ask for ETAs, but I would like to know if have any possibility to make Android 10 real for this device.
Thx for attention and sorry if a make something wrong making this post I'm just curious.
Click to expand...
Click to collapse
Android Q is possible, but will require a tidious rewrite of some parts of Android, most noticable is RIL (sim card, radio and so on) and camera.
You can experiment around with different versions of Lineage OS 16.0 as a base, and then some Android Q Gsi, but depending on the Gsi you choose and LOS build you based on, it may boot, but things may not work.
For more Information, you may want to visit the Guide I made a while ago in the, well, guides section of the G5s.
In the meantime, consider joining one of the telegram groups (the main one is mainly Portuguese, idk why)
Main: @montanalabtesters Chat
@montanalab Update feed
Okay, a new release of CAF (Aosp optimized by Qualcomm) got released, but it uses some new Repository structure. Thaaaaats annoying
Im Going to GSI port Havoc 3.5, just wait
Some random said:
Android Q is possible, but will require a tidious rewrite of some parts of Android, most noticable is RIL (sim card, radio and so on) and camera.
You can experiment around with different versions of Lineage OS 16.0 as a base, and then some Android Q Gsi, but depending on the Gsi you choose and LOS build you based on, it may boot, but things may not work.
For more Information, you may want to visit the Guide I made a while ago in the, well, guides section of the G5s.
In the meantime, consider joining one of the telegram groups (the main one is mainly Portuguese, idk why)
Main: @montanalabtesters Chat
@montanalab Update feed
Click to expand...
Click to collapse
Hey! Remember Me?
Yeah I did it
"MotoX Project
idk why i choose that name, but this is a place for my "creations" mainly android Q Gsi development and maybe some OOS updates
Everything here is distributed in either .zip files or .img files and with permission by the owners"
https://t.me/MotoXProject
You should get telegram for this if you don't have it already
not nice these motoproject people on telegram
thought they was helping me change OS on a moto Montana G5 and i get muted for typing too much. and they gave me a dodgy OS to run on my phone essentially bricking my phone.. so luckily i backed up the stock OS before doing anything so whatever you do guys don't trust the team on telegram. they only there to wind you up and destroy ya phone

Question Finding manufacturing date for Motorola E (2020) XT2052-1

I bought an XT2052 (US Cellular channel) last week in a small shop while on a trip in the Caribbeans, i'm trying to find the manufacturing date (box looks kinda old) as there are issues with customs ROMs missing touch screen support for newer variants.
Tried various IMEI checkers and a Motorola algorithm from the serial number (but my serial number doesn't follow the naming convention). No info on box either.
Any way to get this? Thanks.
Did you try the newest builds here?
index - powered by h5ai v0.29.2 (https://larsjung.de/h5ai/)
index - powered by h5ai v0.29.2 (https://larsjung.de/h5ai/)
build.lolinet.com
This phone came out mid 2020 and had a short production run. It's very much a lower end budget phone, so it's quite exciting it might get lineageos 19.
fddm said:
Did you try the newest builds here?
index - powered by h5ai v0.29.2 (https://larsjung.de/h5ai/)
index - powered by h5ai v0.29.2 (https://larsjung.de/h5ai/)
build.lolinet.com
This phone came out mid 2020 and had a short production run. It's very much a lower end budget phone, so it's quite exciting it might get lineageos 19.
Click to expand...
Click to collapse
I haven't tried it yet as i'm trying to get OrangeFox working on it first (some bundled Magisk installation error), but it is exciting that my randomly bought phone has this support - i bought it as my even cheap ass ZTE Blade needed to be replaced due to cracked screen and went for one of the cheapest i could find in local shops.
I'm looking for a google-less ROM and since /e/os is based off Lineage i might actually try to make a variant for it. This is all new to me but as a software dev this is going to be my pet project.
Edit: short term: planning to manually degoogle LOS
Longer term: make an e/os variant
I suppose if you were to take modules and firmware from the gapps build and make a magisk module, you'd be able to install that and flash the boot.img to get touch working on the nogapps build. That or grab the sources and make a new build.
Seems like a lot of work compared to just disabling apks you don't want, though.
If i understand correctly, the least effort would be to get touch working on the nogapps LOS build? Any rough idea how much more effort would it be to make a custom or unofficial /e/os build?
If your just trying to build a different branch, I suppose it wouldn't be very difficult. Or at least it wouldn't require much technical skill. Just a matter of learning how to build an unofficial los and having the hardware to do it.
Edit: I decided to test swapping kernels for the nogapps build. It's made easier since there doesn't appear to be external modules and there was only one new firmware file.
Thanks for the Chipone touchscreen vendor file!
If i understand correctly, the boot image is the LOS kernel with added Chipone support, right? Have you tested it on a XT2052-1 by any chance?
As soon as i get OrangeFox, TWRP or another recovery working hopefully sometime this week i will test it and let you know. Your help is greatly appreciated.
That's the dumped boot image from the 10/5/21 build, which contains the kernel, and a magisk module with the missing firmware. Using Magisk in this case would be annoying, I should have made it a recovery installer in hindsight. You can always just place the file with your recovery's root shell.
I have -6 with a focaltech ts, but your model doesn't have anything to do with ts controller. They'll throw in whatever's available on the market at the time, so you have to look at your kernel logs to find out.

Kernel development

Is there anything that would be interested in a custom kernel or maybe custom roms for this device? I can pick one up pretty cheap on eBay, just wondering what the landscape if the community is here.
From what I could see on GitHub, some developers tried to use the kernel sources, but it seems that OnePlus forgot to release some parts of it. So for now no one has created any roms or kernels, there is just an unofficial TWRP.
I'm quite good with recreating the kernel sources, I have done so for the N10, N200 5G, and a few other devices. See here. The missing parts are mostly Qualcomm specific code they keep in CAF repositories. Until my device touches down in my mailbox I'll need some testers. I'll have the kernel source completed well before then.
Sorry but personally I don't think I can help testing, since it's my main device I'd rather avoid having to erase my data every time.
That's understandable. You wouldn't happen to have a boot.img I can start with? The stock firmware doesn't have the files broken up individually.
If anyone wants to follow development:
OnePlus Nord N100 Community
You can view and join @OPn100 right away.
t.me
I have this one from the latest update (EU variant, I don't know if it changes anything):

Categories

Resources