Will these changes work on the sense files?
http://forum.xda-developers.com/showthread.php?t=2504373
Or is this already done by someone?
I don't think so as smali codes from sense are different to the ones in AOSP and the guide you linked to was made for changing AOSP smalis. However, @xpirt would be the one to answer this question correctly.
Related
If I understand android correctly the kernel source has to be open. And the Google rom source is also open (AOSP, right?) But what about the rom, like das bamf, source. Is it open and able to be downloaded?
The HTC Sense Framework and related applications are not open source. You modify it by decompiling to bytecode and manually editing the results.
Ok so lets take the GB roms. They are based off the GB leak. So what does "based off" mean in that context. Are they tweaking source files or are they tweaking xml, build.prop, etc. files? This might be asking a too complicated question, but lets take das bamf sense 3.0, they took the GB leak, and then added the Sense 3.0 Framework on top, I understand then resized images and such, but what had to be "done" to make it work? Find working apks for camera and such?
What I am getting at, is I am curious about Rom development. I am going to start small, thinking CM7 over on the Nook Color, seems like a good device to mess around on. And I know that source is available due to it being built from AOSP, but I was wondering about the Roms built off of, say, MR1 that is delivered by Verizon.
There is no source to the gingerbread leak or for any of the leaks based on sense, rom creators just do what I said in my last post. That's how it's done for anything build off of sense period.
If you dont believe me, try googling for "htc sense source code" and see how far that gets you. If that still doesnt make sense, google "decompile code"
If you want actual source code, you have to stick with building off of roms created with the Android Open Source Project like CM and OMFGB.
Oh I believe you. Thanks for the info, that is what I was curious about. So most of the Sense development is in a hex editor? Interesting.
you could hex edit, but there's easier ways. Google for apktool and dalvik bytecode instructions
Thanks. That info is very helpful in understanding all of this stuff.
sure, good luck
The first thing I want to say is that my English is not really good. I hope you understand my questions.
I have an idea for a new Android rom, but I'm faced with a dilemma. I want to have as much as possible supported devices, so I also can just build a launcher apk which can be installed through Google Play. In this way all mobile devices with the minimal platform version can use it. The biggest problem is that I don't only want a replacement for the application launcher but also the notification drawer and everything else. Is it possible to replace them also? I don't think so, so I think I'll work on a custom rom.
The next problem is which base rom I would use if I really build a custom rom. It's most likely to use AOSP as base because it's clean. The question is which version of AOSP: Gingerbread, Ice Cream Sandwich, or the newest version Jelly Bean. You would probably say Jelly Bean because this is the newest version. The problem is the phone support. Gingerbread is supported on most phones. If I build ICS or JB the phones which are supported by Cyanogenmod are easy to support, because I can use their device files. The only problem is that my phone, the Samsung Galaxy Gio is not officially supported and the unofficial port is not really stable. I don't think it's a big problem to use this device files and just wait till the developer makes it more stable, but I don't know for sure.
The last thing I want to know is if it's really that simple to support multiple devices. If I read tutorials about porting existing roms to your device they all say you just have to add your device files to the source and compile it. But they never say something about the kernel. Most devices need another kernel because their hardware is different isn't it? Please explain me how this works.
I'm sorry about this hazy story, but please help me before I make wrong choices. Thanks on purpose.
Wietse
WietsedeVries said:
The biggest problem is that I don't only want a replacement for the application launcher but also the notification drawer and everything else. Is it possible to replace them also? I don't think so, so I think I'll work on a custom rom.
Click to expand...
Click to collapse
These changes you are talking about can be done. They are system changes so not supported by the android app installer.
Eg: Your notification drawer, status bar are part of SystemUI.apk. The source for this is can be found in the AOSP source code under android/frameworks/base/...
You can make your modifications, compile it into an apk and then make a flashable zip to replace the current one (or push it via a rooted adb console).
or you can compile the entire source code into a flashable zip (eg CM7,9 etc..) and use it a replacement ROM with your modifications.
This is the line between an application under the android runtime and the android runtime itself.
these files, under framework are part of the OS. so to provide a customized version of the operating itself is what people like to call ROMs.
Now ROMs (like any OS) are device dependant. Windows has the code to run in a lot of different hardware configs, but android aims to be small. It should have only the minimum required code to efficiently run itself on a device.
Thats the kernel. The kernel communicates with the hardware and so the rest of the hardware can happily talk to a working kernel and expect the hardware to function as advertised. Kernel is a simple program which goes into the RAM on system start and sits there directing the operation of the phone.
Kernel devs work on making sure the hardware and the android runtime work perfectly together. Now, in this imperfect world, not all sources are open, even though they should be. and therein the issue lies.
If you want to compile android from source and make sure it works on your phone, first you need to make sure you have the kernel with all the changes(patches) to it made by the vendor (chap who made the phone and bullied you into buying it) to get it working on your hardware.
If you dont have that, you have to do it yourself. Or wait for someone else to do it.
once you can compile android and get it working on your phone with all the itty bitty hardware working A-OK.. then you can browse through the source, make changes as per your individual requirements and compile it into a ROM.
see the changes to the OS are separate from the changes to the kernel. The kernel changes are for hardware-software interaction so they are phone SPECIFIC.
but changes to your custom android OS (ROM) can be "cherry-picked" from other ROM/gerrit/AOSP/CM/AOKP sources and put inside your own source tree to get included in your build.
so if you have all the device / kernel stuff from a working android distribution, you can take the source of another android distribution and swap the device stuff into it and see if it works.
hope this helps.
wingie6200 said:
These changes you are talking about can be done. They are system changes so not supported by the android app installer.
Eg: Your notification drawer, status bar are part of SystemUI.apk. The source for this is can be found in the AOSP source code under android/frameworks/base/...
You can make your modifications, compile it into an apk and then make a flashable zip to replace the current one (or push it via a rooted adb console).
or you can compile the entire source code into a flashable zip (eg CM7,9 etc..) and use it a replacement ROM with your modifications.
This is the line between an application under the android runtime and the android runtime itself.
these files, under framework are part of the OS. so to provide a customized version of the operating itself is what people like to call ROMs.
Now ROMs (like any OS) are device dependant. Windows has the code to run in a lot of different hardware configs, but android aims to be small. It should have only the minimum required code to efficiently run itself on a device.
Thats the kernel. The kernel communicates with the hardware and so the rest of the hardware can happily talk to a working kernel and expect the hardware to function as advertised. Kernel is a simple program which goes into the RAM on system start and sits there directing the operation of the phone.
Kernel devs work on making sure the hardware and the android runtime work perfectly together. Now, in this imperfect world, not all sources are open, even though they should be. and therein the issue lies.
If you want to compile android from source and make sure it works on your phone, first you need to make sure you have the kernel with all the changes(patches) to it made by the vendor (chap who made the phone and bullied you into buying it) to get it working on your hardware.
If you dont have that, you have to do it yourself. Or wait for someone else to do it.
once you can compile android and get it working on your phone with all the itty bitty hardware working A-OK.. then you can browse through the source, make changes as per your individual requirements and compile it into a ROM.
see the changes to the OS are separate from the changes to the kernel. The kernel changes are for hardware-software interaction so they are phone SPECIFIC.
but changes to your custom android OS (ROM) can be "cherry-picked" from other ROM/gerrit/AOSP/CM/AOKP sources and put inside your own source tree to get included in your build.
so if you have all the device / kernel stuff from a working android distribution, you can take the source of another android distribution and swap the device stuff into it and see if it works.
hope this helps.
Click to expand...
Click to collapse
Thank you very very much for your explanation! It's a pity it's impossible to hit multiple times "Thanks".
I think I'm going to make a modified SystemUI.apk but you didn't tell the application launcher is also in this file. Did you just forget this or is this stored in another file/folder? And the lock screen? And I want also to replace the boot animation if it's possible.
If I take the source files of the SystemUI.apk of AOSP ICS, does this work on every phone running ICS? Included CM, AOKP and other (smaller) custom roms? And my last question: Since SystemUI.apk a apk file is, is it possible to edit these files through Eclipse and build it in Eclipse? Or do I get errors?
//Edit:
Still another question: How much work is it to, as example, port a modified Gingerbread SystemUI.apk to ICS? (Or vice versa)
WietsedeVries said:
Thank you very very much for your explanation! It's a pity it's impossible to hit multiple times "Thanks".
I think I'm going to make a modified SystemUI.apk but you didn't tell the application launcher is also in this file. Did you just forget this or is this stored in another file/folder? And the lock screen? And I want also to replace the boot animation if it's possible.
If I take the source files of the SystemUI.apk of AOSP ICS, does this work on every phone running ICS? Included CM, AOKP and other (smaller) custom roms? And my last question: Since SystemUI.apk a apk file is, is it possible to edit these files through Eclipse and build it in Eclipse? Or do I get errors?
//Edit:
Still another question: How much work is it to, as example, port a modified Gingerbread SystemUI.apk to ICS? (Or vice versa)
Click to expand...
Click to collapse
Only way is through exchanging the png files since porting the whole .apk is impossible.
Sent from my Jelly Beaned Ace
Thanks for the answer. And do you also know the answers of the other questions?
Sent from my GT-S5660 using xda app-developers app
WietsedeVries said:
If I take the source files of the SystemUI.apk of AOSP ICS, does this work on every phone running ICS? Included CM, AOKP and other (smaller) custom roms? And my last question: Since SystemUI.apk a apk file is, is it possible to edit these files through Eclipse and build it in Eclipse? Or do I get errors?
//Edit:
Still another question: How much work is it to, as example, port a modified Gingerbread SystemUI.apk to ICS? (Or vice versa)
Click to expand...
Click to collapse
There are two roads you can go now - one is use apktool to *decompile* apk the apk file that you've taken from your phone, it doesnt convert the app to java source code but java bytecode in .smali files (like an assembly version of the source) but you will have access to the resource files (xml, images etc..) so you can replace them and create some new themes.
http://forum.xda-developers.com/showthread.php?t=1814441
http://forum.xda-developers.com/showthread.php?t=1760133
And no - a GB systemUI.apk will *NOT* work on ICS. It is very probable that any changes you make through any of these methods can brick you phone. So make sure you have CWM and a nandroid backup.
If you want to add/edit functionality within the source code of systemUI.apk, you need to learn how to compile Android from Source. i would suggest getting hold of the CyanogenMod source tree for your device and playing around with it.
Ginger bread is CM7 and ICS is CM9.
http://forum.xda-developers.com/showthread.php?t=1552090
once you have the full source tree, you'll find a folder called android/frameworks/base/core/...something../systemui/..
this will contain the javasource code for your application. Here you can edit stuff to your hearts content!
Note that this cannot be compiled standalone by eclipse. The Android build system must be used to compile this (cuz its a system app).
a nice resource i used when i was doing the same thing :laugh:
http://iserveandroid.blogspot.in/2011/01/how-to-implement-your-own-status-bar.html
cheers and have fun.
There is currently a patch for true Tablet UI on the Nexus7 Development that has worked successfully. Link is here. The following is a quote from the original thread:
Intro
Goal of thread is to share details around how the trigger for Phone UI/Phablet UI/Tablet UI works, and provide a dpi independent patch for tablet ui. Hopefully this also eliminates the misinformation that changing lcd density is the only way to get Tablet UI.
What's "true" tablet UI vs what is called tablet UI in many roms? The Tablet UI actually defines how some apps work (e.g. dual-paned settings like in the screenshots below) vs the other solutions that simply draw the standard Nexus UI with tablet navigation/system bars.
The 'Triggers'
In 4.1.x, there are two files that need to be modified:
PhoneWindowManager.java, located in frameworks/base/policy/src/com/android/internal/policy/impl contains the code that determines which UI to present. During compile this is a part of android.policy.jar
WindowManagerService.java, located in frameworks/base/services/java/com/android/server/wm contains code that specifies the lowest DP settings and has the system select from either sw600 or sw720 presentations. It is a part of services.jar
Click to expand...
Click to collapse
Basically, I'd like to modify this to work on a 4.2.1 AOSP ROM on the Nexus10 (flashing the Nexus7 patch on the Nexus 10 leads to a bootloop). The OP shows what modifications can be made in his thread so I'm wondering how I can port this to a Nexus10 ROM. I've used APKTool to break down the "android.policy.jar" file and looked through the smali files hoping to simply edit the corresponding lines but I was unable to locate it. Apparently there's more to it than that. Any thoughts on how to create a flashable zip to patch these files?
brGabriel said:
There is currently a patch for true Tablet UI on the Nexus7 Development that has worked successfully. Link is here. The following is a quote from the original thread:
Basically, I'd like to modify this to work on a 4.2.1 AOSP ROM on the Nexus10 (flashing the Nexus7 patch on the Nexus 10 leads to a bootloop). The OP shows what modifications can be made in his thread so I'm wondering how I can port this to a Nexus10 ROM. I've used APKTool to break down the "android.policy.jar" file and looked through the smali files hoping to simply edit the corresponding lines but I was unable to locate it. Apparently there's more to it than that. Any thoughts on how to create a flashable zip to patch these files?
Click to expand...
Click to collapse
haha i saw your post to my rom thread and this is exactly what i tried to do!
the thing is when you decompile precompiled java code you get the assembly and actually have to edit the opcodes. i tried doing that and failed (bootloop). I was so frustrated because i spent like 6 hours for nothing and decided to learn how to build AOSP from scratch. When i succeeded i posted my rom
schnip said:
haha i saw your post to my rom thread and this is exactly what i tried to do!
the thing is when you decompile precompiled java code you get the assembly and actually have to edit the opcodes. i tried doing that and failed (bootloop). I was so frustrated because i spent like 6 hours for nothing and decided to learn how to build AOSP from scratch. When i succeeded i posted my rom
Click to expand...
Click to collapse
Haha, well it was a noob "shot in the dark" attempt on my part. Going to start looking into building from scratch so I can take care of business on my own instead of having to rely on others. I don't mean that in a negative sense, I'd like to be able to contribute to the community one day.
Anyway, thanks for your work, schnip!
I'd like to create a flashable zip of a full stock ROM with some really basic changes from the stock Nexus 4 4.4 factory image. I know the core of the question doesn't fit this forum section, so please bear with me and read to the end before telling me to take this to the N4 section.
I've been reading guides here on XDA on flashing and porting Android ROMs, as well as the official documentation, for a while today. Some of them are quite good and thorough. All of them seem to focus on AOSP or ROMs like CM being modified or built. There's one thing I'm left a bit unclear on which I would appreciate someone more knowledgeable clearing up for me.
How is it that I get from a factory image to a flashable zip, or from AOSP source to a flashable zip that's identical to the stock factory images Google releases?
I understand that I may need to compile this from source and I'm fairly comfortable compiling source code on Linux. What I'm not completely clear on his how close AOSP is to the stock Google factory binaries and exactly what changes would need to be made to bring it in-line with those releases other than hardware drivers.
This is initially just for my own purposes to have a flashable zip of stock Android the way I like it on my N4. The tweaks are low in number and scale. The LTE hack, the 4.4 tethering fix, and the GEL are the primary things I'd like to incorporate myself.
I'm sure someone has already done something similar to what I'd like but I'd also like to learn this so I'm not really interested in being pointed to ROMs which have already accomplished this. I do appreciate the thought though.
Is there a simple way of finding all proprietary/vendor files for porting CM or other AOSP based ROMs?
My phone is running Android 5.1 and I wanted to port CM12.1 to it but having trouble finding these proprietary files, similar devices use different files and I can't seem to understand how people who ported ROMs for them found their list of files for proprietary-blobs.txt