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.
Related
Ive been enjoying Resurrection Remix [Unofficial] rom and was wondering if they or any other rom for the Xperia Z5 P will support Oreo?
There is no kernel so unfortunately no
tset351 said:
There is no kernel so unfortunately no
Click to expand...
Click to collapse
???
zacharias.maladroit said:
???
Click to expand...
Click to collapse
Well there are no kernel sources nor binaries, blobs etc. so I guess there will no custom rom be available anytime soon but please correct me if I'm wrong. I would be glad to have Oreo on my Z5P.
tset351 said:
Well there are no kernel sources nor binaries, blobs etc. so I guess there will no custom rom be available anytime soon but please correct me if I'm wrong. I would be glad to have Oreo on my Z5P.
Click to expand...
Click to collapse
The developer seems to be busy so allow me to answer (though I'm not that experienced). I'm pretty sure that Sony always releases it's phone's kernel sources. Phone hardware doesn't change from an update so when the sources are released they can be used to create a kernel for any android version (basically developers need access to unique hardware). Blobs are like closed-source kernel modules. They're provided with the kernel source but the manufacturer doesn't want them to be copyrighted or tampered with. So I'm sure that Oreo will be available on your device, just give the developers some time. And please don't answer questions if you don't know what you're talking about (at least write that you're inexperienced).
Nik0laTesla said:
The developer seems to be busy so allow me to answer (though I'm not that experienced). I'm pretty sure that Sony always releases it's phone's kernel sources. Phone hardware doesn't change from an update so when the sources are released they can be used to create a kernel for any android version (basically developers need access to unique hardware). Blobs are like closed-source kernel modules. They're provided with the kernel source but the manufacturer doesn't want them to be copyrighted or tampered with. So I'm sure that Oreo will be available on your device, just give the developers some time. And please don't answer questions if you don't know what you're talking about (at least write that you're inexperienced).
Click to expand...
Click to collapse
I am a very inexperienced person.
For MSM8994 platform there is only 3.10 kernel sources available, at least on sony's developer page. On open devices resource list, there are binaries for Z5 premium for 5.1, 6.0, 6.0.1, 7.0 and 7.1 but unfortunately no 8.0 or 8.1. And well, developers can take their time - as long as they want because I don't use that cell phone anymore and I won't expect any custom Rom changes anytime soon especially for a 2015 Device which had very less development going on since its launch.
But once again, I am very inexperienced.
Nik0laTesla said:
The developer seems to be busy so allow me to answer (though I'm not that experienced). I'm pretty sure that Sony always releases it's phone's kernel sources. Phone hardware doesn't change from an update so when the sources are released they can be used to create a kernel for any android version (basically developers need access to unique hardware). Blobs are like closed-source kernel modules. They're provided with the kernel source but the manufacturer doesn't want them to be copyrighted or tampered with. So I'm sure that Oreo will be available on your device, just give the developers some time.
Click to expand...
Click to collapse
Ok, sorry I got a bit mixed up in the devices :laugh:. Either way Snapdragon provides up to date documentation on their SOC's (which is the most important hardware component on the device) so developers should still be able to provide Oreo. And you are right the Z5 premium is an old device and support usually drops as soon as the developer gets rid of that device. But it's weird how much attention different devices get. For example I have a Oneplus X (SD801, I know it's ancient) (didn't even get Nougat) and there are multiple Oreo 8.1 ROMs available.
Hi, i'm asking to devs if it's possible to port say Galaxy S9's rom to Treble enabled devices or even other manufacterer roms such as LG's or HTC? I thought S9 was released with Oreo, therefore it should have Treble support and could its stock rom can be used a GSI rom or am i wrong? Thanks in advance.
+1. Want to see Samsung Experience on my device too
I Wont Samsung Experience on my Device Too :crying:
Most capable man atm
@fxsheep
Jamie_oppo said:
Most capable man atm
@fxsheep
Click to expand...
Click to collapse
Wait for SE 10.0 Android P,
I can be possible. Yes!
But there are many Knox dependecies on TW kernel. Even if you did, stuff like storage wont work at all.
I'm doing a lot of research about GSIs and Project Treble recently; and that was the FIRST thing that came in my mind.
"What if my Xiaomi could run Samsung Experience?"
I absolutely love Stock Android; and Android Pie looks pretty close to Samsung Experience 9.0 based on Oreo.
But still; it'd be nice to have Galaxy Note's exclusive features on a bloody Xiaomi!
I think its going to be a headache for developers; but a bug-free, smooth running Samsung Experience GSI would be a bombshell for sure!
HighonBolo said:
Hi, i'm asking to devs if it's possible to port say Galaxy S9's rom to Treble enabled devices or even other manufacterer roms such as LG's or HTC? I thought S9 was released with Oreo, therefore it should have Treble support and could its stock rom can be used a GSI rom or am i wrong? Thanks in advance.
Click to expand...
Click to collapse
I'm not a Dev but I can tell you, No it'll never happen!
Here's some reasons why....
Project treble is just a way to separate proprietory vendor files and driver's from the base of ROM and giving them a standard to interface with new roms. It means the device is compliant with treble roms, not that their stock ROM is.
Treble roms are built from source code and that code is written to allow 1 GSI to be installed on multiple devices and work their hardware. Samsung has no source code for their roms.
Allot of Samsung's features are all tied in with their framework and also hardware dependent.
So the only way to remotely get a manufacturer ROM on another device is by porting. Which is a difficult process.
aaron74 said:
I'm not a Dev but I can tell you, No it'll never happen!
Here's some reasons why....
Project treble is just a way to separate proprietory vendor files and driver's from the base of ROM and giving them a standard to interface with new roms. It means the device is compliant with treble roms, not that their stock ROM is.
Treble roms are built from source code and that code is written to allow 1 GSI to be installed on multiple devices and work their hardware. Samsung has no source code for their roms.
Allot of Samsung's features are all tied in with their framework and also hardware dependent.
So the only way to remotely get a manufacturer ROM on another device is by porting. Which is a difficult process.
Click to expand...
Click to collapse
Thanks, but I wanna ask what will happen if I done these:
1. ADB pull everything from /system on a rooted Samsung phone
2. Repack it into system.img
3. Use erfangsi tool to convert it into a GSI
Not challenging you, just completely out of my curiosity.
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
As far as I understand, in A-only GSIs the system partition (the GSI image) just contains the system files (the contents of $TARGET_ROOT_OUT in the build process). This whole partition is then mounted as /system in the OS.
By contrast, A/B GSIs have these same contents in the /system directory within the GSI image/partition. The root of the partition itself is then set as root (i.e. system-as-root, SAR) in the OS. As such, /system is not a mount point anymore, but a normal directory. The root of the image/partition (SAR) contains the init files etc. for booting (which in A-only setups reside on the ramdisk in the boot partition, so they are missing from an A-only GSI).
These are basically the only differences between the two, or rather: the former A-only GSI is for a non-SAR system; the latter A/B GSI is for a SAR-system. It is explained here, that these differences are minor and you can relatively simply convert a GSI image from A-only to A/B or back. (Back to A-only is even easier because you don't need all the root files.) Now, the manner in which /system is stored and where the root files are (SAR or not) does not seem to have anything to do with having a dual slot A/B system (for seamless OTA updates) or a single slot system (A-only). But apparently it does, since the names clearly say A-only and A/B. So let's find out where that comes from.
First of all about the SAR definition: Google's definition differs from what you'd expect. You can read about this in the Android documentation. New Android versions don't use SAR according to Google, as they do not first boot from the system partition. Instead, the new "method C devices" boot from ramdisk and then in a second stage boot the system partition; the older, "method B devices" boot from system directly and hence only those are called SAR by Google.
However, for all intents and purposes, SAR could just as well be defined as the system image/partition being the root partition, regardless if you boot from it in a single stage or not. Then, SAR corresponds to having a system image/partition like is done in A/B GSIs that you download from this forum, as mentioned above in the 2nd paragraph. We uphold this definition therefore, as does the documentation from the utility tool Magisk.
On this documentation page from Magisk it is nicely explained how the booting process and the partition structures evolved over subsequent Android versions. We'll recap a few crucial points, just to understand where A-only and A/B images are meant for:
Android 8 introduced project Treble for the first time and hence some devices should be capable of running GSIs. Booting was done from ramdisk (method A) and SAR was not a thing yet. Hence, devices running Android 8 and below (and possibly also some running Android 9 or even later) that use this boot method need A-only (non-SAR) GSIs (if Treble supported). Seamless updates were not a thing with this method.
Android 9 introduced SAR which was necessary for A/B seamless updating. In the Magisk documentation this is called "legacy SAR" (method B). Hence, devices running Android 9 (and possibly also some running Android 8 or ones upgraded to Android 10 or higher) using this method need A/B (SAR) GSIs (if Treble supported), whether or not seamless updates are supported.
Android 10 introduced the ramdisk again due to support for dynamic partitions. 2SI made SAR possible (method C). Hence, Android 10 or higher devices (and possibly also some running an older version of Android) using this method need A/B (SAR) GSIs (if Treble supported), whether or not seamless updates are supported. Android 10 always uses SAR with method C (but perhaps devices upgraded from lower versions can use Android 10 with non-SAR but method A instead?).
It's clear that having a two slot A/B device (for seamless updates) or a single slot A-only device has little to do with whether you need an A/B or an A-only GSI. The Magisk documentation defines four types of devices. Considering the above, only device type I always needs an "A-only" non-SAR GSI. Type II, III and IV always use "A/B" SAR GSIs, and indeed this means the kind of image needed is independent of whether seamless updates are supported or not (a device with type III does not and neither does a device with type IV with a single slot system).
The reason we apparently still call the GSIs for these old non-SAR devices "A-only" and the SAR ones "A/B" is now also clear: at one time, at the time of Android 7 and 8, many devices did not have seamless updates, which was a new feature (the Pixel was the first two slot device). So devices which had it were required to use method B (and hence legacy SAR), whereas single slot non A/B devices could also use the old method A (non-SAR). Even then, single slot A-only devices were still able to use method B anyway, if implemented that way. However, because then it was mostly true that single slot devices used method A and the dual slot devices used method B, people decided that all method B devices (be it single or dual slot) fall under the A/B denominator and that the A-only name is reserved for method A devices (where the A of course has nothing to do with the A in "A-only"; I hope you can still follow along).
So my question is: why don't we call A-only GSIs non-SAR and A/B GSIs SAR? That seems much less confusing. This forum even has three sub forums for A, A/B and A / A/B GSIs. That seems a bit much considering that there is only a minor difference in partition layout. I think that a single forum could suffice. Indeed, we can see that mostly everyone publishes their GSI in the A / A/B forum. Perhaps it's a good idea to create two forums then, called "GSI development" and "non-SAR (legacy) GSI development". Also, with Android 11 and higher the boot process is similar and compatible to Android 10, so going forward this important distinction will die out anyway and every GSI should work on every phone. (Unless yet another incompatible"method D" comes along.)
What strikes me as odd still, is that even for Android 10 and 11 releases there are "A-only" non-SAR GSIs offered. (To see what I mean look for example here at builds provided by @phhusson.) But I thought that non-SAR images are for older Android versions using method A. So my second question is: can these "A-only" GSIs with recent Android >9 versions even run on non-SAR devices? Is the SAR requirement for Android 10 then not so strict? Are they indeed only meant for the method A / non-SAR devices which can actually boot Android 10 and higher using method A?
As a last note, what I also find weird is that Google itself has a confusing name for its legacy non-SAR build targets: they add the "_ab" suffix. However, this has again nothing to do with seamingless A/B system updates on two-slot devices. I asked about that here. Please post there if you want to give some input on that.
Any thoughts are appreciated, especially regarding the two questions I have.
A-only/AB was used for historical reasons, because it was true on Oreo devices. But since then, Google calls Android 10 devices non-SAR (because they boot on initramfs, even though afterwards yes system is root), and sar property is set to false on those devices. So you can't just go around saying sar/non-sar, it'll a bit more correct, but still not correct. I could have switched to a "SAS" vs "SAR" naming convention (system-as-system VS system-as-root) but well I didn't have time
For your second question, yes that's the whole idea of "A-only GSI". No Android requirement is perfectly strict. Android requirements says you must have an x86 or an ARM, yet there are RISC-V Android. Android is opensource, you do whatever you want with it. Yes they are only meant for "method A" devices.
As for aosp_arm64 vs aosp_arm64_ab, the `_ab` refers to legacy ab devices, which have less requirements wrt properties
Thanks that clears up a whole lot. Except for the _ab part, but I guess we just have to view that just as a suffix for a legacy build target.
OP, this is an exceptional outline and analysis of SAR, the A/B partition scheme, A-only versus A/B, and their individual and collective relevance to GSI enabled devices. I have a question regarding Android 8.x Oreo and the applicability of A/B seamless updates. You stated that Android Oreo did not have seamless updates. I was of the understanding that the A/B seamless updates feature was first introduced with Android 7.0 Nougat, although at the time only Pixel devices actually had the A/B partition scheme. So, did Android 8 Oreo not include seamless updates for a particular reason? Thanks again for the great outline.
@Viva La Android You're right, seamless updates were already there in Android 7. Still Treble started with Android 8 if I'm not mistaken, so GSIs were not relevant before then, so I guess I just went from there. But indeed, my statement that Android 8 did not have seamless updates was just wrong, and poorly worded by me. I changed that paragraph to clear it up. I also put some more "single slot" / "dual slot terminology" in there as well so as to have an alternative naming scheme from "A devices" / "A/B devices". I hope I didn't make a mistake. It's easy to make a mistake with such a confusing naming scheme.
And thanks for the praise, I'm glad it's useful!
Quigley said:
@Viva La Android You're right, seamless updates were already there in Android 7. Still Treble started with Android 8 if I'm not mistaken, so GSIs were not relevant before then, so I guess I just went from there. But indeed, my statement that Android 8 did not have seamless updates was just wrong, and poorly worded by me. I changed that paragraph to clear it up. I also put some more "single slot" / "dual slot terminology" in there as well so as to have an alternative naming scheme from "A devices" / "A/B devices". I hope I didn't make a mistake. It's easy to make a mistake with such a confusing naming scheme.
And thanks for the praise, I'm glad it's useful!
Click to expand...
Click to collapse
You are quite welcome, and thanks again for the detailed and comprehensive outline of such a haphazard set of Android topics. Thank you for your clarification on my question.
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?