Hello guys. Well, since Android 4.4 x86 image for emulator is not yet available for download from google's or intel's repositories, I built my own build. It's just pure Android 4.4 built from official repositories, no customizations. So, if you don't want to spend 5+ hours building it yourself, you can download it here:
DOWNLOAD
So i have just one question , Can I use this image to boot android on my pc via usb ?
drive2droad said:
So i have just one question , Can I use this image to boot android on my pc via usb ?
Click to expand...
Click to collapse
To be honest, I'm not sure. You could be able to use it this way, but it's not made for this purpose. If you would like to use it for this purpose, you should get ISO image or build one yourself.
How do I change this into a ISO file so I can install it to virtualbox?
Guys, this is image for x86 emulator. If you want to have an ISO image, you should compile it yourself.
I have never compiled anything before. Is there some specific way to do it and is it easy? If not then where would I get the x86 emulator to make this image work?
Updated to version 1.1 - now uses branch android-4.4_r1.1
P.S.: I will not answer any questions which could be easily found on google
So I am guessing this is for the android sdk emulator then? If that is the case then it is a little too complicating for me. Isn't sdk emulators mostly for developers and enthusiasts? I am just interested in using an image for putting it on vmware and installing it for use. Well I guess I am off to search google for such a thing and if I find it I guess I will not bother to share it as it would seem everyone knows how to use google to find things that are "simple" to find as aptnutella says. Seriously why would I be asking about such a thing if I didn't already know that it is somewhere in google if I didn't already look. I have been searching everywhere and only found things about the sdk emulator. So I suppose I will keep searching since it is suppose to be simple enough to find.
Updated to version 1.2 - tag android-4.4_r1.2
If you are Arch Linux use, you can find package in AUR.
willmon22 said:
How do I change this into a ISO file so I can install it to virtualbox?
Click to expand...
Click to collapse
sorry, slightly offtopic:
if you want to learn how to compile and x86 build go here:
http://www.android-x86.org/getsourcecode
for an 4.3 build, to install via usb, look here:
http://www.android-x86.org/download
do a new iso with link please :good:
aptnutella said:
Hello guys. Well, since Android 4.4 x86 image for emulator is not yet available for download from google's or intel's repositories, I built my own build. It's just pure Android 4.4 built from official repositories, no customizations. So, if you don't want to spend 5+ hours building it yourself, you can download it here:
DOWNLOAD
Click to expand...
Click to collapse
Download link does not work - opens a blank page
I'm new to the forums and a novice programmer but here's my question:
There's an app I'd like to run on my device for work. Per the play store, the app requires Android 2.3.3 and I'm running 2.2.2. I'm running the most recent version of a custom ROM on an outdated device so can't update my device's build.
I'm wondering if it's possible to tweak the app's source code and repackage it to make it run on my device. I have downloaded the .apk file and tried to install it on my phone and get a parsing error. So with the help of google I have managed to get into the source code using dex2jar and jd-gui. Problem is I don't know much about how apks are written. I found something in the 'accessibilityservice' area that seems to check the android build version, but as far as I can tell that is checking for whether the device is running ICS (if build >= 14) whereas the app is said to be compatible with older builds as well.
Anyway - how complicated would it be to port an app backwards so that I could run it on my phone? You should assume that I'm already in over my head.
Thanks.
petegw42 said:
I'm new to the forums and a novice programmer but here's my question:
There's an app I'd like to run on my device for work. Per the play store, the app requires Android 2.3.3 and I'm running 2.2.2. I'm running the most recent version of a custom ROM on an outdated device so can't update my device's build.
I'm wondering if it's possible to tweak the app's source code and repackage it to make it run on my device. I have downloaded the .apk file and tried to install it on my phone and get a parsing error. So with the help of google I have managed to get into the source code using dex2jar and jd-gui. Problem is I don't know much about how apks are written. I found something in the 'accessibilityservice' area that seems to check the android build version, but as far as I can tell that is checking for whether the device is running ICS (if build >= 14) whereas the app is said to be compatible with older builds as well.
Anyway - how complicated would it be to port an app backwards so that I could run it on my phone? You should assume that I'm already in over my head.
Thanks.
Click to expand...
Click to collapse
A LOT of things changed from pre-2.3 to 2.3 in Android, code-wise. It was a huge upgrade, and a lot of unsupported things were implemented.
It's set to run on 2.3.3 simply because it uses functions that only exist in 2.3.3 and higher.
So to backport it you'd need to get the source code, check what functions require 2.3.3 or higher, edit them to use other functions/write the code yourself. You can't just simply remove the code that checks what version of Android you're running. That won't do a damn thing.
The last part is the near impossible one, because you'd most likely have to write code that goes deep into the Android framework.
If i were you, i'd simply look for another app that can do what you need and doesn't require 2.3.3 or higher. Though there aren't many out there. Most people base their app on 2.3.3 because like 95% or higher use that version (or a higher one).
If you were to dive into this, you'd need extensive knowledge of Android, Java & backporting.
Though i'm not able to help with that, at least the backporting part.
Moonbloom said:
A LOT of things changed from pre-2.3 to 2.3 in Android, code-wise. It was a huge upgrade, and a lot of unsupported things were implemented.
It's set to run on 2.3.3 simply because it uses functions that only exist in 2.3.3 and higher.
So to backport it you'd need to get the source code, check what functions require 2.3.3 or higher, edit them to use other functions/write the code yourself. You can't just simply remove the code that checks what version of Android you're running. That won't do a damn thing.
The last part is the near impossible one, because you'd most likely have to write code that goes deep into the Android framework.
If i were you, i'd simply look for another app that can do what you need and doesn't require 2.3.3 or higher. Though there aren't many out there. Most people base their app on 2.3.3 because like 95% or higher use that version (or a higher one).
If you were to dive into this, you'd need extensive knowledge of Android, Java & backporting.
Though i'm not able to help with that, at least the backporting part.
Click to expand...
Click to collapse
Thanks for the very helpful information. I will definitely not be attempting this.
Most likely will be getting a newer phone in a few months when I'm due for an upgrade so it'll be a moot point. Until then, I'll get by.
Update News Flash Galaxy note 4 running Oreo 8.1
3-29-18
OMG. I said it here first. 32 bit processors CAN be ported to Oreo. Maybe not trebel yet. Smug emoticon
In just a few days , not even I thought it was possible.
Running Oreo via lineageOS 15.1 with root on my Samsung Galaxy Note 4.
The dev who devotes time to compiling builds @ripee has had his daily downloads of 14.1 for the note 4 has more than doubled. Currently running about 250 users testing builds. SMOKIN.....
Here is the OP
https://forum.xda-developers.com/no...0-unofficial-lineage-15-1-rom-t3760969/page92
Update 2-28-18
OpenGapps 8.1 is released for both arm and arm 64.
That means Oreo can be compiled it 32 bit.
Researching Oreo and Oreo go compiler instructions.
Mebbe I can compile AOSP for my older Note 4 .. So cool
https://forum.xda-developers.com/android/apps-games/arm-unofficial-opengapps-builds-android-t3743495
Updated 1-20-18
Newest musings on top. Oreo Go is currently being modded into an older Sony phone. Awesome
So since I posted this OP...my musings have been correct in these posts.
This came out on XDA, check out the links in it.
https://www.xda-developers.com/android-go-old-android-8-1-oreo/
Android Oreo and android in general is getting closer to Linux . Mainly for the same reasons
I have been installing different distributions of Linux on an older laptop.
1. To learn installing hard to find drivers
2. Learning Linux architecture and commands
3. Learning to build Linux kernel for my device
http:// www.kernel.org
4. Learning to build lineageos14 in general
With these guides
https://forum.xda-developers.com/note-4/general/guide-build-lineageos-14-1-trltexx-t3567885
Thanks @_mone and @ripee
https://forum.xda-developers.com/chef-central/android/how-to-build-lineageos-14-1-t3551484
Thanks @FSadino
5. Actually compiling lineageOS-14 for my two devices I have access to
Galaxy note 4 Verizon thanks to @ripee for his contribution by building daily's at
https://forum.xda-developers.com/note-4/snapdragon-dev/rom-lineageos-14-1-t3536401
And my galaxy tab S2 sm-t710
Thanks to @Bonuzz for getting the camera, mic GPS and Bluetooth working, and posting sources
https://forum.xda-developers.com/tab-s2/development/t710-t715-lineage-14-1-t3713097
Thanks to @Ather for getting Samsung to release their Kernel sources and building a android 7 rom
https://forum.xda-developers.com/tab-s2/development/kernel-poseidonkernel-v1-0-permissive-t3588069
https://forum.xda-developers.com/tab-s2/development/rom-poseidonrom-v1-0-deodexedrooted-t3590228
6. Thinking and musing about things
Symlinks, multi boot, and partitions. ( Treble )
In Linux, I have another partition with downloaded files on another drive
When the kernel boots, the directory tree just sees /data even though it's a separate drive
This is because of a symbolic link that mounts the partition as a folder. This prevents me, from deleting that data with permissions
So the Trebel rules tell the vendor to make a separate partition in the drive but the kernel gets a symbolic link to it, and the user (Google) cannot over write the partition with the critical info..when the ROM gets flashed? correct ?
The bootloader has boot path a, or boot path b.
The user files are in protected memory
So with Linux, when I updated my kernel,
The grub bootloader tells me I can use kernel 4.1.x or 4.2.x when I boot
The kernel loads the drivers
And then looks at the symbolic links to mount the drives.
This is somewhere in the /etc files or somewhere
So Trebel has to be a set of decision trees based on symbic links to hardware
Where all the hardware drivers are independent of the kernel
More musings later. Must build....
**************
Dec 2017 sometime
Thanks to all for viewing my first OP.
I'm just learning about building ROMs, and look forward to this thread to spitball ideas and see what sticks.
If I don't know something its because I am correcting my ignorance.
This won't be an actually development thread, just trying to understand hardware from 30 years of not being in the tech field.
Eventually I will tire or wear out of driving truck, and work with my passion again.
I am a follow the steps kind of mind, so I am learning how the world of Android / Linux works.
If I understand the Trebel development correctly...
https://www.xda-developers.com/goog...ze-android-so-oems-can-update-devices-faster/
IF we can modify the older device drivers to be Trebel compliant, then once they work, then they always should work. And any Trebel ROM can work on Any Trebel Device withOUT compiling over and over.
This should result in an explosion of custom ROMs .
So I am suggesting a repository of drivers per device that are compliant for older devices.
How do we do that?
So here is the Google announcement of Trebel
https://android-developers.googleblog.com/2017/05/here-comes-treble-modular-base-for.html?m=1
Here is the developer preview of ”O”
https://developer.android.com/preview/download.html
It details how to install it on your Trebel Device.
Wow. Just Wow.
OH MY GOODNESS. I would love this on my lg g3, oneplus one, and moto e2. WOW.
TotalNoobTrucker said:
If I understand the Trebel development correctly...
https://www.xda-developers.com/goog...ze-android-so-oems-can-update-devices-faster/
IF we can modify the older device drivers to be Trebel compliant, then once they work, then they always should work. And any Trebel ROM can work on Any Trebel Device withOUT compiling over and over.
This should result in an explosion of custom ROMs .
So I am suggesting a repository of drivers per device that are compliant for older devices.
How do we do that?
Click to expand...
Click to collapse
How do you wanna to do that ?
Vendor files are NOT open-source so you cannot make them treble enabled sadly.
Haxk20 said:
How do you wanna to do that ?
Vendor files are NOT open-source so you cannot make them treble enabled sadly.
Click to expand...
Click to collapse
So far all it looks like ROM dev is trial and error with people posting guides on repeatable success... (Community)
I haven't built a ROM, ( haven't built a compiler computer yet) plus I drive truck 70 hrs a week..
but have read
https://forum.xda-developers.com/chef-central/android/guide-android-rom-development-t2814763/
And
https://forum.xda-developers.com/android/software/how-to-port-samsung-rom-to-samsung-t3481114/
So what's different in the building process? With Trebel?
Google dev page lists an additional partition for drivers called VENDOR
A file called manifest.xml
And a A/B partition.
So assuming I am building a Lineage OS ROM 14.x
In that compile process, everything is compiled in the ROM
Kernel, Lineage front end, AOSP programs etc.
So somewhere in the compiler process the drivers to my N910V are pulled in from somewhere? Github¿?
If they are not open source, they were pulled from system image via ADB or Android image kitchen and uploaded to where?
So i guess we need a guide on how to build Trebel for non Trebel devices. The folks on the other Trebel thread are doing it on newer devices and getting some exciting results.
There is only a couple of Lineage 15.x builds going, but once someone has the Process down to build a Trebel on non / close to Trebel hardware,
It should be repeatable for ANY Oreo and up compiled ROM.
I may not be able to build yet, but since Trebel is the new path, I want to gather Trebel success and Process here. Maybe make a guide..
In conclusion, the drivers may not be open source, but the code is out there somewhere.
Sent from my Lineage OS 14 Samsung Verizon Note 4 from @ripee
My other device is a Samsung T710 running Posiedon 1.0 . Thanks for a stable rooted tablet @Ather
Sent from my Samsung SM-N910V using XDA Labs
TotalNoobTrucker said:
So far all it looks like ROM dev is trial and error with people posting guides on repeatable success... (Community)
I haven't built a ROM, ( haven't built a compiler computer yet) plus I drive truck 70 hrs a week..
but have read
https://forum.xda-developers.com/chef-central/android/guide-android-rom-development-t2814763/
And
https://forum.xda-developers.com/android/software/how-to-port-samsung-rom-to-samsung-t3481114/
So what's different in the building process? With Trebel?
Google dev page lists an additional partition for drivers called VENDOR
A file called manifest.xml
And a A/B partition.
So assuming I am building a Lineage OS ROM 14.x
In that compile process, everything is compiled in the ROM
Kernel, Lineage front end, AOSP programs etc.
So somewhere in the compiler process the drivers to my N910V are pulled in from somewhere? Github¿?
If they are not open source, they were pulled from system image via ADB or Android image kitchen and uploaded to where?
So i guess we need a guide on how to build Trebel for non Trebel devices. The folks on the other Trebel thread are doing it on newer devices and getting some exciting results.
There is only a couple of Lineage 15.x builds going, but once someone has the Process down to build a Trebel on non / close to Trebel hardware,
It should be repeatable for ANY Oreo and up compiled ROM.
I may not be able to build yet, but since Trebel is the new path, I want to gather Trebel success and Process here. Maybe make a guide..
In conclusion, the drivers may not be open source, but the code is out there somewhere.
Sent from my Lineage OS 14 Samsung Verizon Note 4 from @ripee
My other device is a Samsung T710 running Posiedon 1.0 . Thanks
Click to expand...
Click to collapse
The OEM needs to add support for treble there is no treble for non-treble devices.
Treble works like so:
Vendor files are stored in separate partition (Those files are edited to work with treble)
Then android just takes those files from there and work.
The vendor files are not in system.img but in /vendors (the partition is mounted here)
Only a few devices have vendor files open source there is possible to make the device treble supported but 99% of devices have vendor files closed and so its not possible for some dev here to make the device supported.
Also A/B is new partition layout:
You have your system on A but once update is available its downloaded onto B and then it just switch them (Don't read about that much so I canbe wrong here).
Also I have build ROM for xperia P and if I wanted to build 8.0.0 I cannot use treble sadly that would have made my job lot easier.
Hmm.
Haxk20 said:
The OEM needs to add support for treble there is no treble for non-treble devices.
Treble works like so:
Vendor files are stored in separate partition (Those files are edited to work with treble)
Then android just takes those files from there and work.
The vendor files are not in system.img but in /vendors (the partition is mounted here)
Only a few devices have vendor files open source there is possible to make the device treble supported but 99% of devices have vendor files closed and so its not possible for some dev here to make the device supported.
Also A/B is new partition layout:
You have your system on A but once update is available its downloaded onto B and then it just switch them (Don't read about that much so I canbe wrong here).
Also I have build ROM for xperia P and if I wanted to build 8.0.0 I cannot use treble sadly that would have made my job lot easier.
Click to expand...
Click to collapse
So where are the Xperia P files you imported into your 8.0 biuld¿ Can't you put them in the vendor folder and see if it boots¿ I presume you have to make a manifest.xml file so the ROM can see the files
Sent from my Samsung SM-N910V using XDA Labs
TotalNoobTrucker said:
So where are the Xperia P files you imported into your 8.0 biuld¿ Can't you put them in the vendor folder and see if it boots¿ I presume you have to make a manifest.xml file so the ROM can see the files
Click to expand...
Click to collapse
I haven't done 8.0.0 build yet cause the device got only CM-12.1 and now trying to port 8.0.0 and no putting the files there will not work:
1. Old devices don't have that partition and evenif I reformat it and add it and edited fstab to see it.
2. The files NEEDS TO BE EDITED TO WORK WITH TREBLE. If it was that easy to make partition put there the files and tadaaa treble device then every old device could get 8.0.0 to run but well I don't see threads about it. It's not that easy you NEED THE SOURCES TO MAKE IT TREBLE ENABLED.
Haxk20 said:
I haven't done 8.0.0 build yet cause the device got only CM-12.1 and now trying to port 8.0.0 and no putting the files there will not work:
1. Old devices don't have that partition and evenif I reformat it and add it and edited fstab to see it.
2. The files NEEDS TO BE EDITED TO WORK WITH TREBLE. If it was that easy to make partition put there the files and tadaaa treble device then every old device could get 8.0.0 to run but well I don't see threads about it. It's not that easy you NEED THE SOURCES TO MAKE IT TREBLE ENABLED.
Click to expand...
Click to collapse
Sadly, I think android 8.1 trebel is 64 bit. My note 4 is a 32bit arm71
So I dunno how it could run on my note 4. However the nexus 6 is the same cpu hardware as the note 4
However the nexus 6p is the 8core with 2 other core chipset, which is 64 bit and supported by 8.1 Trebel
So me thinks the older devices are not able to run trebel
Sent from my Samsung SM-N910V using XDA Labs
TotalNoobTrucker said:
Sadly, I think android 8.1 trebel is 64 bit. My note 4 is a 32bit arm71
So I dunno how it could run on my note 4. However the nexus 6 is the same cpu hardware as the note 4
However the nexus 6p is the 8core with 2 other core chipset, which is 64 bit and supported by 8.1 Trebel
So me thinks the older devices are not able to run trebel
Click to expand...
Click to collapse
Yeah that's another problem even if there was a way to edit vendor files treble is 64bit only
If I undertand it correctly, there's another layer between the HAL and the android framework, the HIDL, which decribes the interface of the HAL.
Shouldn't we theorically be able to edit that?
The good news is my sm-t710 is a exynos5433 chipset which supports 64bit. So maybe I will get to play with 8.n someday
android1111 said:
If I undertand it correctly, there's another layer between the HAL and the android framework, the HIDL, which decribes the interface of the HAL.
Shouldn't we theorically be able to edit that?
Click to expand...
Click to collapse
I think so. If you look at the other forum, it seems they're editing only a couple files. The manifest.xml describes what files are the drivers and where to look for them. This is a crucial file, as the drivers are in a separate partition from the system/data partition now. Download one and read it .it's a very simple exchange script
TotalNoobTrucker said:
I think so. If you look at the other forum, it seems they're editing only a couple files. The manifest.xml describes what files are the drivers and where to look for them. This is a crucial file, as the drivers are in a separate partition from the system/data partition now. Download one and read it .it's a very simple exchange script
Click to expand...
Click to collapse
As I said above you NEED the vendor file sources then create /vendor partition to add the vendor files there.
Without sources you can't make Treble running.
So if you ever want to play with 8.0 on your phone you should start porting right now.
---------- Post added at 10:42 PM ---------- Previous post was at 10:41 PM ----------
TotalNoobTrucker said:
I think so. If you look at the other forum, it seems they're editing only a couple files. The manifest.xml describes what files are the drivers and where to look for them. This is a crucial file, as the drivers are in a separate partition from the system/data partition now. Download one and read it .it's a very simple exchange script
Click to expand...
Click to collapse
I mean porting as the "hard way" = modifying device tree to work with new sources and patching the sources.
Haxk20 said:
As I said above you NEED the vendor file sources then create /vendor partition to add the vendor files there.
Without sources you can't make Treble running.
So if you ever want to play with 8.0 on your phone you should start porting right now.
---------- Post added at 10:42 PM ---------- Previous post was at 10:41 PM ----------
I mean porting as the "hard way" = modifying device tree to work with new sources and patching the sources.
Click to expand...
Click to collapse
I get that to begin the process for non Trebel, that's the idea.
Move all the vendor libraries to the vendor file, and run them through the Google process to make them compliant.
I would have to find a piece of hardware that has the same SoC just to begin.
No wonder the note 4 stalled at 6.0.1, verizion want going to rewrite the code. Just to get to 7. They would rather sell note 8's
Sent from my Samsung SM-N910V using XDA Labs
See scenario 2 on
source android com devices architecture hidl-cpp
We need to code o adapt a passthrough HIDL
It's not a matter of editing a file
TotalNoobTrucker said:
I think so. If you look at the other forum, it seems they're editing only a couple files. The manifest.xml describes what files are the drivers and where to look for them. This is a crucial file, as the drivers are in a separate partition from the system/data partition now. Download one and read it .it's a very simple exchange script
Click to expand...
Click to collapse
It's not a matter of editing a file to tell Android and the kernel where to look for drivers. We are not "editing" manifest.xml, it is generated during the build process. The whole structure and system calls of the drivers is changed to make them suitable for treble. And that is done by the SoC vendor whomever they may be. You can build Oreo to work on older devices by using your existing drivers, but not by using treble, you have to use your existing kernel, and write your own "hooks" into your existing drivers (better be familiar with hex code), and do a LOT of modifications to the Android code. Treble is not intended as a way for older devices to get custom ROMs, as their pre Oreo kernels and drives are not capable.
A N00b's explanation of Project Treble
Okay so I've seen a lot of confusion about how Project Treble does and does not work, so I'm going to provide a small explanation, simplified to a fault, but it'll do:
In ye olden days (Nougat and back), the Android OS was very tightly integrated with the drivers of the system. This made custom firmware very difficult to port (relatively speaking). Certain drivers were more difficult to make workable and as a result you'd have work in progress ROMs that didn't have WI-FI or cameras working, etc. It really was a pain in the butt.
Project Treble changes all of that. What it does is separate the operating system from the drivers, making porting much easier for devices that support it. The problem is that in order to enable this it would require almost a complete rebuild of these drivers, which would in turn require access to the source code and a LOT of work (hence why companies like OnePlus are releasing devices with Nougat so they don't have to use Treble, which is required on all devices that start with Oreo).
In short, COULD Treble be ported to older devices? Yes; Google and Essential have proven that. Is it feasible? Unless you've got some friends at Samsung/HTC/Xiaomi/insert-other-company-here willing to leak source code, no not really. The only device that I could possibly see getting a Treble port is the HTC HD2, simply because that phone is basically the technological equivalent of a cockroach, and I think they may have actually reverse engineered their drivers to get them to work on so many operating systems. I know I've probably made some mistakes in my explanation, but it's my best way if simplifying how this works so that people don't come along, see Treble and expect an Oreo ROM for their Fire Phone or something
2390 said:
Okay so I've seen a lot of confusion about how Project Treble does and does not work, so I'm going to provide a small explanation, simplified to a fault, but it'll do:
In ye olden days (Nougat and back), the Android OS was very tightly integrated with the drivers of the system. This made custom firmware very difficult to port (relatively speaking). Certain drivers were more difficult to make workable and as a result you'd have work in progress ROMs that didn't have WI-FI or cameras working, etc. It really was a pain in the butt.
Project Treble changes all of that. What it does is separate the operating system from the drivers, making porting much easier for devices that support it. The problem is that in order to enable this it would require almost a complete rebuild of these drivers, which would in turn require access to the source code and a LOT of work (hence why companies like OnePlus are releasing devices with Nougat so they don't have to use Treble, which is required on all devices that start with Oreo).
In short, COULD Treble be ported to older devices? Yes; Google and Essential have proven that. Is it feasible? Unless you've got some friends at Samsung/HTC/Xiaomi/insert-other-company-here willing to leak source code, no not really. The only device that I could possibly see getting a Treble port is the HTC HD2, simply because that phone is basically the technological equivalent of a cockroach, and I think they may have actually reverse engineered their drivers to get them to work on so many operating systems. I know I've probably made some mistakes in my explanation, but it's my best way if simplifying how this works so that people don't come along, see Treble and expect an Oreo ROM for their Fire Phone or something
Click to expand...
Click to collapse
So who do we know at Samsung/HTC/Xiaomi ?
Haha.
Or better yet who do we ask there? Do they have only internal development? Customer service? How do some Devs get source code? When a company releases a developers version ( thankfully someone had a way to flash a dev version 5.1.1 of my verizion note 4 so it could get a ROM.. ), does the developers edition phone come with the support and access of developers?
The reason I ask. Is I used to have MSDN access when I worked at [email protected]#$0ft . just asking again. What's the path to be a developer from a builder like Samsung?
Good luck with that
TotalNoobTrucker said:
So who do we know at Samsung/HTC/Xiaomi ?
Haha.
Or better yet who do we ask there? Do they have only internal development? Customer service? How do some Devs get source code? When a company releases a developers version ( thankfully someone had a way to flash a dev version 5.1.1 of my verizion note 4 so it could get a ROM.. ), does the developers edition phone come with the support and access of developers?
The reason I ask. Is I used to have MSDN access when I worked at [email protected]#$0ft . just asking again. What's the path to be a developer from a builder like Samsung?
Click to expand...
Click to collapse
You're going to have better luck getting blood out of a rock than that. Even when they have "developer" editions of phones they don't give you access to their code, that just means it's totally unlocked for you to f*** up or flash ROMs to. The phone manufacturers get the drivers for the SoC from the manufacturer of the chip, and except in binary form that never leaves and stays in house. Only way you're going to get that is by knowing someone who works at Qualcomm, Samsung, etc. who is willing to risk being fired, sued, thrown in jail, or all of the above for stealing the source code and leaking it to you. When a phone manufacturer releases "source code" if you examine it you will find that those closed source drivers are not included, you can build it but a lot of things won't work. (Besides the fact that it is always outdated code).