Related
As an experiment I am trying to rebuild some standard android applications and replace them in system/app on the G1. I have been through all the steps to get the source code and build for the dream platform and have built the various .apk files of interest (e.g. AlarmClock.apk, Browser.apk etc)
To put the files on the device I delete the old .apk and .odex files and copy my newly built .apk file on to the device. However when I try to run the application it crashes with the following message.
The application Alarm Clock (process com.android.alarmclock) has stopped unexpectedly. Please try again.
I know that replacing the applications like this is possible, because the AutoRotating Browser build works fine when copies over in this manner.
I'm using JF1.31 (RC8)
My initial reaction was that I was not signing the applications properly but having read some posts I think the default built .apk should have the right key already in it.
Another theory I have is that perhaps the applications from the head of the source tree are not compatible with the RC8 (or RC30) Android OS releases. Can anyone tell me how to get the source tree which corresponds to this baseline, I've done some reading around but cannot figure it out. I presume I need to do a repo init -u git://android.git.kernel.org/platofrm/manifest.git -b BASELINE but I can't figure out what BASELINE should be.
Many thanks in advance for any help you can give me!!!
There are some branches in android sources:
master
cupcake
release-1.0
Apps from the first two will not run on default G1, you need to reinstall a whole system. I think by default, following google docs you'll get master. So you need to download a release-1.0 sources.
I may be wrong, but that is what I'm see from my experience.
Thanks for that, I'll get the 1.0 branch downloaded and have a go with that.
Cheers for your help!
I was also trying to recompile some of the built-in apps, specifically the browser, but I can't even get it to build. I get a bunch of import errors, stating that it can't find some of the android libraries, such as android.net.http.AndroidHttpClient, android.os.AsyncTask, etc. I've got the android.jar from the SDK in my build path, and it finds some of them, such as android.webkit.URLUtil.
Can anyone shed some light on what I need to do to get it to see the missing libraries? Thanks.
UndeadCretin said:
Thanks for that, I'll get the 1.0 branch downloaded and have a go with that.
Cheers for your help!
Click to expand...
Click to collapse
There are around a dozen build breaks in release-1.0... all of them are due to missing header #includes in various .c and .h files. So, when it doesn't work, don't give up. Fix the breaks and everything will build properly.
Are you resigning the .apk files? Cuz you have to do that for them to work correctly.
Koush said:
There are around a dozen build breaks in release-1.0... all of them are due to missing header #includes in various .c and .h files. So, when it doesn't work, don't give up. Fix the breaks and everything will build properly.
Click to expand...
Click to collapse
Yep I fixed these problems but I have now hit upon the following problem:
(unknown): error 17: Field android.hardware.SensorManager.LIGHT_NO_MOON has changed value from 0.0010f to 0.001f
******************************
You have tried to change the API from what has been previously released in
an SDK. Please fix the errors listed above.
******************************
I've been in and modified SensorManager back to 0.0010f and that let me build get further but I hit the same error again later in the build.
Given that release-1.0 should be a stable branch is it normal to get all these build issues?
Managed to fix the java issue by modifying public_api.xml. Then hit several more C++ problems which I fixed and finally I can build the lot!
Just tried building the AlarmClock application and running on the G1 and it works fine. Thanks everyone for your help!
>Managed to fix the java issue by modifying public_api.xml. Then hit several more C++ problems which I fixed and finally I can build the lot!
Can you write, what did you fix?
^ Agreed, let us know which files need modifying and what needs doing, i've been trying to get my release-1.0 build root working too!
Alternatively, UndeadCretin, could you build the firmware (release-1.0) with a modified framework-res i can send you?
Ok, I managed to compile it without any editing of xml.
Just added stdlib, string, vector headers to dozen of cpp/h.
worry said:
>Managed to fix the java issue by modifying public_api.xml. Then hit several more C++ problems which I fixed and finally I can build the lot!
Can you write, what did you fix?
Click to expand...
Click to collapse
To fix the java issue, I modified frameworks/base/core/java/android/hardware/SensorManager to change the LIGHT_NO_MOON value to 0.0010f (from 0.001f) and in out/target/common/obj/PACKAGING I modified the <field name="LIGHT_NO_MOON" to have value-"0.0010f">
After this there were several other c++ files which were missing relevant includes. I'm afraid I didn't keep a note of these so cannot provide much detail but mostly they were missing one of the following
#include "stdlib.h"
#include "string.h"
#include "stdio.h"
I think one file needed the following include
#include <string>
and there were a couple of other files that needed other includes. The best way to find these is to google for the function name that isn't building and you should be able to find the appropriate include (that's how I did it).
Hope that helps a bit!
were you able to repo sync after adding the local_manifest.xml?
ximonx said:
were you able to repo sync after adding the local_manifest.xml?
Click to expand...
Click to collapse
I did try that previously but it didn't work. I don't think the relevant files for the dream build are available in the release-1.0 branch. This wasn't a problem for me since I'm only interested in building the applications which work fine with the generic build.
I would like to do the same for the mms application. Could you give me the steps or a link how to do it? I mean do I need the whole sources from android platform to do it? How can I just compile one application?
Phlogiston said:
I would like to do the same for the mms application. Could you give me the steps or a link how to do it? I mean do I need the whole sources from android platform to do it? How can I just compile one application?
Click to expand...
Click to collapse
I downloaded the whole Android source (the release-1.0 branch) and compiled the lot. It may be possible to just build the individual application but I do not know how. It is not vital to build for the dream platform if you only care about the applications since they will work fine with the generic build.
So the basic steps to start are:
Get yourself a Linux or Mac OS platform (I use Ubuntu running in VMWare on my XP box).
Follow the instructions here: http://source.android.com/download but when you come to repo init add the flag -b release-1.0
Fix various build problems
When recompiling individual apps to replace system apps is there a way of just building a single application or does the entire thing need making?
ximonx said:
When recompiling individual apps to replace system apps is there a way of just building a single application or does the entire thing need making?
Click to expand...
Click to collapse
My experience is that you have to do the whole thing if you are building from source. There is one way I know of to get around this, which is to use baksmali and smali.
Just to be clear, making the entire thing = build from source root?
ximonx said:
Just to be clear, making the entire thing = build from source root?
Click to expand...
Click to collapse
If you are asking me--yes, that's what I mean. Make sure to build for dream-open as the target (it's generic by default).
Hi,
Usually on linux, there is a kernel loading modules at boot-time framework, cf. modules.conf.
No longer present in android.
When typing lsmod, there is two modules loaded by default : tntfs, and bcm4329 (and voodoo_sound
if you have it).
I'm trying to figure out what is the standard procedure on android : I've noticed on the
init.rc that the tntfs.ko is loaded, but can't figure out when bcm4329.ko is loaded.
Any idea ?
Moreover, I know that voodoo controller is able to load his own kernel module (voodoo-sound)
at boot-time. Anyone knows how the voodoo dev did that ?
My current idea is to modify init.rc to source a new file - let's say init.rc.local - to keep my custom mod. It'll
allow minimal changes when updating+root : just copy the init.rc.local and change the init.rc...
Sounds like we're recreating linux boot framework. lol.
This is something I've done on the HTC Incredible and the Droid 1 in the past, but in honeycomb, this is different, not very obvious yet:
Rather than try to emulate whatever Redhat or Ubuntu has done, which usually doesn't work, I either would use the line where tntfs.ko is insmod'd in /init.ventana.rc (sorry, think that's the filename), and add in the modules you want to add right there. Make sure to save the original file so you'll have a shot at fixing it if you make a mess.
The other thing is just to find some developer that appears to know what they're doing, and download their ROM, like Roach. I just downloaded his prime 1.6 ROM and unpacked it, then noticed immediately that he's got this in there:
/system/etc/init.d/01init{stuff},
Well that seems pretty important, so I did a grep 'init.d' * -R from the / level, and could only see little of importance, not any shell file like initrc pointing to it, just that busybox is linked to it, etc.
I figured it's worth a shot to create the same file structure on the stock ROM (/system/etc/init.d/0X{name} and see if it executes :: Start it with the usual #!/system/bin/sh
# load some modules
/system/bin/inmod /system/lib/modules/cifs.ko (or whatever)
and see what happened, if anything.
Better yet, I'd just send a message to Roach or some other ROM developer and ask.
Good luck -
altsyst said:
Hi,
Usually on linux, there is a kernel loading modules at boot-time framework, cf. modules.conf.
No longer present in android.
When typing lsmod, there is two modules loaded by default : tntfs, and bcm4329 (and voodoo_sound
if you have it).
I'm trying to figure out what is the standard procedure on android : I've noticed on the
init.rc that the tntfs.ko is loaded, but can't figure out when bcm4329.ko is loaded.
Any idea ?
Moreover, I know that voodoo controller is able to load his own kernel module (voodoo-sound)
at boot-time. Anyone knows how the voodoo dev did that ?
My current idea is to modify init.rc to source a new file - let's say init.rc.local - to keep my custom mod. It'll
allow minimal changes when updating+root : just copy the init.rc.local and change the init.rc...
Sounds like we're recreating linux boot framework. lol.
Click to expand...
Click to collapse
Tested.
Does not work, because modified room probably calling busybox run-parts.
Anyway I've found a hack, I'm posting it on general section.
This is my revision of the Flashy tool, look below for the original thread and an explanation what it's meant for.
Don't know if it's worth the effort, but made a repo at github aswell, here is the link, any feedback is much appreciated.
For commiters, pls keep the master branch clean to "stable" builds, for commiting while development the workinprogress branch is ment for.
Changelog is below.
Will split it up to source changes and tool changes soon.
theq86 said:
Hello devs,
I made a tool to quickly flash image files to the device. it uses fastboot and adb as backends, but offers a UI to do the work. This is not only a handy GUI tool, but a full object oriented library for the .NET Framework, which the tool builds upon. You can use the wrapper library to access the most important adb and fastboot commands from within any .NET program, thus building new real applications instead of batch files. it is up to you if you want a console application, a gui or even a windows or webservice, as long as you program in a .NET environment.
Flashy is just an example what is possible to do. You can use it to flash any file to your device without having to employ the console or write fastboot commands.
Recent changes:
* added splashscreen flashing capabilities to the library and the flashtool
If you found bugs or have improvement ideas, feel free to write in this thread.
Attachments:
1) the handy Flashy-Tool
2) The .NET Wrapper's source code. Public domain, feel free to download, change, compile, sell for a million bucks or print out for your grandma
3) The Flash Tool's source code, also PD
Click to expand...
Click to collapse
Original Thread
Changelog:
v2.0.2_ alpha
Workers administrate themselvs now
Library documented (can be extended)
Gui partialy documented
fixed fastboot output
splited timouts for fastboot and adb (finetuning needed)
added readline method to base of adb and fastboot
changed return type of execute methods, stream isn't returned anymore, readline replaces it
some minor changes
v2.0.1_ alpha
Windows & Mono support (Unix/Linux/MacOs)
Redesigned most parts of the library and gui (still something left)
Cleaned up sourcecode
Added adb shell support with custom commands (atm no preset, you have to type them yourself)
Added logcat support with custom filters (atm no preset, you have to type them yourself)
Custom path to adb (atm not split up in two paths for adb and fastboot) can be set
Check if adb and fastboot are present inside the directory, otherwise fastboot is disabled
Possibility to disable fastboot at the gui
Deleted most of the Messageboxes, using textbox at the mainwindow instead
Synchrone and Asynchrone (atm buggy, maybe using another approach for it) processing at the library, Gui asynchrone (library is still used synchrone for stability, but uses the output stream directly [works fluid with logcat])
Choosen adb-path is stored for following starts
and everything else i missed, sry it's late and i'm tired^^
reserved for future
did somebody already flash any spashscreen to DS?
docertabum said:
did somebody already flash any spashscreen to DS?
Click to expand...
Click to collapse
Yes did it now, but had a little bug, the gui tried to execute the command with adb instead of fastboot, my fault, shouldn't change (or copy and paste) code as late as i did yesterday, sry.
Added the fixed version.
Unfortunately there is no output of the progress shown atm (even if the same stream is used as with adb) but it works, have tried it myself (you need an nb file like usual when you try to flash a splash with fastboot, will also look if i can change this [convert it internal]), will take a look at it later, now it's first time to go home^^
Tectas said:
Got a little finding for you, the gui itself isn't that big impact, but i really like the library to setup your own Applications, even if it wouldn't be that much effort to build one yourself, it's nice to have.
In the op isn't mono mentioned, but it should work as well, will test it later.
Hope you enjoy it.
Original Thread
Added changelog, binarys and source of my revised version, hope you enjoy it
Click to expand...
Click to collapse
eheh... Always wanted to learn C# or derivatives. Maybe this is the incentive I needed. Terrific work, thanks mate!
Cheers
lowveld said:
eheh... Always wanted to learn C# or derivatives. Maybe this is the incentive I needed. Terrific work, thanks mate!
Cheers
Click to expand...
Click to collapse
If you want to, I can create a git repo for it
If it's pushed further like I want to, it will grow up to an allround tool.
Ah, but missed to document the source yet, will catch up later
Swifted from my Desire S far away from my PC
New version is up, enjoy it
Swifted from my Desire S far away from my PC
Added github repo, latest binary zip is also uploaded to it (but no changes since yesterday yet).
Just to keep you updated:
Been working on full async support for the library, it's not finished yet, (but not much is left).
Implemented it with almost the same pattern as in the GUI and just as a side node, in future it will always run async, if you use sync mode, it just fakes it by not starting more then one async process at the same time.
If someone wants to take a look at the current source, the workinprogress branch on github is at the current state.
Next I will take a look at is, more fastboot commands and goldcard creation (thx to the voters).
Fastboot is easy to implement and will come soon, the goldcard will take some time, because I need to figure out how I can generate the image.
Additional to this I will give the mainwindow a small beauty cure (I don't like the radio buttons^^) and will implement the interactive shell (to be honest, I already integrated the possibility in the lib, but haven't tested it yet [yes that's what I voted for ]).
And the last thing on my schedule is (except of bugfixes, if needed) the ability to store from the user flashed images or nb files, that he can choose them from a list if he needs one of them once more (i.e. Boot.img after a romupdate)(first step to recovery feature ).
Other things will also come for sure, but that's enough by now I think^^
If someone else wants something else, or got something that may should be on the list too, pls tell me.
Swifted from my Desire S far away from my PC
I finally found a fix for wired tethering in Linux
A few of you may know that, for some reason, USB tethering with Linux stopped working after the update to Gingerbread. It still works with Windows, but Linux shows a 'bad crc' error in dmesg when USB tethering is activated. But someone figured out a fix, which I finally found and tested. I can confirm that it works with CM7 beta 2 using the built-in tethering option (and I am using it to write this post). The website where I found the patch did not mention what rom it was tested with, but since the patch is for a Linux module on the computer, it most likely won't matter.
Here is the website where I found the instructions - note that you will need to download the patch file, and make sure you have the Linux kernel source (that should be standard, but if you get an error about missing files...). Finally, be sure to pay attention to the punctuation used - code portions containing `uname -r` and M=`pwd` are NOT using the single quote - they are using the symbol located with the ~ (tilde) symbol, and this is extremely important. Anything contained in those symbols will be replaced with their output before execution of the command that contains them - similar to the use of parentheses in algebra.
The command uname -r returns the current kernel revision number, which is used to dynamically direct the commands to the most current source code.
`pwd` resolves to the Present Working Directory
If you prefer a more automated method, I have created a script that follows the commands from the above website, and packaged it with the patch file. Just extract both files into $HOME/Downloads (your Download directory in your home path), and run ./linux-rndis-patcher.sh - you may need to sudo chmod 0755 linux-rndis-patcher.sh first
I hope others find this as useful as I have. I take no credit - my contribution, the script, is a basic copy-and-paste job (tested and confirmed to work on the originating computer).
Update: the process works for the newer 3.2.0 kernel included in Linux 12.04, with slight modifications to match an updated directory structure in the source package. I updated my linux installation only to find that the old problem had returned. I am attaching a copy of the updated script - you can run it (make sure the patch file is in the correct directory) or simply use it as a command list.
Also, I should point out that this does not patch your kernel - it builds a patched stand alone module that can be used to override the built in version. This means it is easy enough to revert the process - more information is contained in the ubuntu wiki linked to from the site where I found the original information
Dude you are awesome, thank you for this!
Sent from my SPH-D700 using xda premium
Minor Correction
Well, I just realized that the script for 3.2 kernels didn't upload, but I can't get to my computer to fix that right now... so in the meantime, anyone who has upgraded to the 3.2 kernel can edit the 3.0 script
Two paths explicitly link to 3.0 directories, the just need to be changed to 3.2
Also, the path within the source code tree has changed - I will edit this post with the correct path momentarily, so stay tuned...
EDIT: I'm not sure what I was thinking about the path, but everything should be fine once both instances of "linux-source-3.0.0..." are edited to "...source-3.2.0"
Oh, and I renamed the patch file, so be sure to use the correct filename based on whether you download directly from the source or use the copy in my upload (identical aside from the filename)
Sent from my SPH-D700 using XDA
To clarify the bug here, the problem is that the Samsung Gingerbread USB gadget stack misspecifies a USB CDC union descriptor configuration that doesn't match what the device actually uses in RNDIS mode.
Windows, apparently, either ignores or doesn't care about the misconfiguration. Linux, while it's capable of detecting RNDIS interfaces in the absence of a CDC union description entirely, is "too strict" when the configuration is misspecified. So this patch makes Linux less strict in this regard.
So in short, the actual bug is in the device's kernel. But since RNDIS behavior is pretty much defined as "whatever Windows tolerates", it's reasonable and prudent to fix it on Linux USB hosts as well.
In any event, there's a few patches floating around for custom kernels to fix this problem on the device side, which is preferable as we don't really want to have to patch every Linux machine out there to deal with this issue. The one that we implemented for the CM9 kernel is here, and should've been included in our CM9 builds since alpha3 I believe.
Too true, I just haven't gotten around to figuring out how to patch the CM7 kernel yet so this works for me. Thanks for explaining the bug, so others will be aware that this is a workaround, not really a fix... I'll change the thread title, now that I think about it
Sent from my SPH-D700 using XDA
Yeah, there's a few changes in the CM9 kernel that need to be backported to CM7. Tortel is working on that now actually, so hopefully the next CM7 release will include the RNDIS fix among others.
SplashInjector​splash injector is a tool created by me based on the work done by @makers_mark . it is a basic command line interface but it gets the job done. it supports all oneplus devices so far except the oneplus x :crying: i can add support once someone gets me the logo.bin file from that device. The tool is pretty simple its based on the work here https://forum.xda-developers.com/oneplus-3/themes/mod-splash-screen-image-injector-t3441999 this is where i got this all from. i know it can be kinda hacky and only supports unix systems i think you can get it working by using git bash on windows. In its current state it can decode and encode all oneplus logo.bins (Including the OnePlus 5!) it can also pack flashable zips for you automatically. all you need to do is run the decode option edit the file you want in the output folder. Then you can run the encode command and it will pack it all back up. Then package it with the package command. Once again major credit to @makers_mark he did all the leg work. i just made it a little more friendly. lmk if there is any issues you find
Telegram: @ethanbanker if you need anything contact me here.
Now lets get to it
follow the instructions here located here
https://github.com/ethanbanker2428/SplashInjector
Updates:
1.52: Ok guys im not a windows expert...i barely use it so the tool does support windows now but it cant package files. it does give you all the tools and files you need to package one tho. you can use a tool such as this https://forum.xda-developers.com/android/software-hacking/tool-6-feb-android-flashable-zip-t3551772 this update also includes a completely revamped system. lmk about any bugs you find. for windows you need to install and use GIT bash. i also added a update function to easily update the tool. its simple but it works. heres my git again for you guys https://github.com/ethanbanker2428/SplashInjector
WARNING I AM NOT RESPONSIBLE FOR ANYTHING YOU DO. DO THIS AT YOUR OWN RISK
Works great dude thanks