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).
About the time when further existence of Cyanogenmod was endangered because of Google's legal claims, there happened to be a post from the author of Cyanogenmod:
Since I don't work with any of these closed source applications directly, what I intend to do is simply ship the next version of CyanogenMod as a "bare bones" ROM. You'll be able to make calls, MMS, take photos, etc. In order to get our beloved Google sync and applications back, you'll need to make a backup first. I'm working on an application that will do this for you.
Click to expand...
Click to collapse
The current state is that (supposedly) Cyanogenmod build does not contain any Google apps, BUT in fact to install Cyanogen you should first flash a development image from HTC (DRC83 or so) that contains them, and atop of this Cyanogenmod.
My question is, will the current Cyanogenmod build work without the HTC "base" files, in the way it is described in the message quoted above?
I own a Magic 32A. Could I just flash the latest Cyanogenmod update.zip (and another update.zip with appropriate kernel)?
I DO NOT want any proprietary apps on my phone.
(It will suffice if I have a web browser and a basic contact list application, without syncing.)
If anyone knowledgeable in the affairs of "update.zip" format reads this, I would also like to know if the Cyanogenmod's update.zip does only write some files to existing filesystems, or does it first erase/create new filesystems in some areas of flash memory? And what does the update.zip from HTC do (this one is certainly supposed to erase the root filesystem of the device!)? Would applying just the Cyanogenmod's update.zip leave the HTC files in place if they are already there, and how can I clean the root filesystem?
Not sure if that's how it works. Why don't you just remove the apps after?
If you really want Android without Google Apps, you can also compile from the source Android. That will give you basic functionality (phone, contacts, email) without Google Apps on it. You just need to checkout donut branch, instead of eclair's, since eclair is still on development.
Check: source.android.com and follow the documentation to checkout and compile for dream and sapphire
xaueious said:
Why don't you just remove the apps after?
Click to expand...
Click to collapse
The Google's libraries seem to be hiding in every corner, so that's not really clean.
@dferreira
Right, but it is probably some hassle (and I would duplicate some work of the people who publish their images here), also the download would take a long time with my internet connection. Why do it, if it's already done? A stock Android build from AOSP must be hanging somewhere around... but I haven't seen it yet. All the donut images I've seen on this forum had some silly modifications and were prepared to work with Google packages.
(Or is the source prepared nicely enough to work right if it compiles successfully and is put on the device? How do you put the build in an update.zip to allow flashing to a consumer device with a custom recovery image, but without engineering SPL?)
Donut branch should compile and work without a hitch. Even eclair works out-of-the-box, without camera working and 3D acceleration.
The compiled result will be recovery.img, boot.img, system.img, userdata.img... I've flashed them using fastboot Unless you know how to make a update.zip out of these, you should be all set. The update.zip only works if signed with the right certificates for non-engineering SPL devices.
The update.zip only works if signed with the right certificates for non-engineering SPL devices.
Click to expand...
Click to collapse
I wonder how do some folks from this forum do it then?
I doubt they have relations with google employees!
Do you know which kernel trees are compatible with the 3.22.20.17 radio firmware that is found in stock Magic devices?
AOSP has a kernel project and HTC has put some kernel sources at developer.htc.com, but there's only something called "HTC Magic Kernel Source Code" - no mention for which model.
Well, actually, i might do with some of the kernels that lie around the forum, but do they have any special requirements for initrd and modules, that would require modifying the flash images you get from building the Donut branch?
Seems to me that kernel is in the boot.img. You flashed it and everything works. You have not touched the radio firmware. Correct or not?
kguciek said:
I wonder how do some folks from this forum do it then?
I doubt they have relations with google employees!
Do you know which kernel trees are compatible with the 3.22.20.17 radio firmware that is found in stock Magic devices?
AOSP has a kernel project and HTC has put some kernel sources at developer.htc.com, but there's only something called "HTC Magic Kernel Source Code" - no mention for which model.
Well, actually, i might do with some of the kernels that lie around the forum, but do they have any special requirements for initrd and modules, that would require modifying the flash images you get from building the Donut branch?
Seems to me that kernel is in the boot.img. You flashed it and everything works. You have not touched the radio firmware. Correct or not?
Click to expand...
Click to collapse
Yes, the kernel is in boot.img, and it is the AOSP kernel that comes with the source code There is no radio firmware on AOSP.
update.zip is made by issuing make otapackage.
Hi buddy i thought about something like that few weeks ago and i think MarsDroid has already made some version of Android(Very lite MarsDroid SPL 7) fully without Google apps, so try it..
OK, I've built an image from donut source, coupled it with a kernel from a CyanogenMod port, and it works flawlessly on my phone!
I've uploaded the images to RapidShare, should anyone need them Links are at my website (guciek.net/en/stuff/android_builds).
kguciek said:
My question is, will the current Cyanogenmod build work without the HTC "base" files, in the way it is described in the message quoted above?
I own a Magic 32A. Could I just flash the latest Cyanogenmod update.zip (and another update.zip with appropriate kernel)?
I DO NOT want any proprietary apps on my phone.
(It will suffice if I have a web browser and a basic contact list application, without syncing.)
Click to expand...
Click to collapse
Yes, it works fine if you don't flash the 'defanged' update image first.
unfnknblvbl said:
Yes, it works fine if you don't flash the 'defanged' update image first.
Click to expand...
Click to collapse
But it wouldn't erase the whole system partition, so there could still be some files left.
Now that I realised I can flash images from recovery even without engineering SPL, it seems a safer and cleaner way.
Also, I like to have a second ext2 partition on SD card that is only accessible from a computer, and I wasn't able to do this with CyanogenMod, which instantly filled it with apps2sd data, swap files etc...
kguciek said:
But it wouldn't erase the whole system partition, so there could still be some files left.
Click to expand...
Click to collapse
No, that's why you wipe from recovery before installing.
unfnknblvbl said:
No, that's why you wipe from recovery before installing.
Click to expand...
Click to collapse
Actually wiping only erases the data partition, not the system one.
fastboot erase system -w
carz12 said:
fastboot erase system -w
Click to expand...
Click to collapse
Right, but it isn't possible for users with unmodified SPLs.
Actually, you can just flash a image of an empty yaffs filesystem to system partition (it's just a few blocks at most).
Im in the process of compiling android 4.2 for the skyrocket right now. i wanted to share the changes i needed to make to get it to keep compiling. i am not currently done with the compiling process right now but i have made a few changes that others can use to get them along the way as well. if you have any other changes i have not listed here PLEASE LET ME KNOW so i can add them to this google drive doc and always have it up to date. if there also is something you think should be in there PLEASE LET ME KNOW! i would like to collaborate with some people to get this built quick. we did an awesome job with jellybean and i have hope we can get this going quick.
Here is the google drive doc i have with the changes needed to get this compiling.
Google Drive Doc to build Android AOSP 4.2
if i come across any issues that i cannot solve i will be asking on this thread so please be checking back every once in a while if you are an experienced dev.
i have already made a few changes to the doc. im trying to make this as easy as possible to build.
i got it to completely build without any errors. http://d-h.st/Dvo
it does not boot though. and i dont know why. im going to need some help on this one.
im guessing maybe it has something to do with the ramdisk
sk8erwitskil said:
i got it to completely build without any errors. http://d-h.st/Dvo
it does not boot though. and i dont know why. im going to need some help on this one.
im guessing maybe it has something to do with the ramdisk
Click to expand...
Click to collapse
so i diff'd the init.rc of the skyrocket cm10 and the init.rc and of the stock nexus4 system image from the android website and theyre exactly the same. so im guessing its not the init.rc. i tried copying over adbd and init from the n4 ramdisk but it gets stuck at the samsung logo.
edit: ignore that. i was looking at the same file. lol. this is what comes from no sleep
sk8erwitskil said:
i got it to completely build without any errors. http://d-h.st/Dvo
it does not boot though. and i dont know why. im going to need some help on this one.
im guessing maybe it has something to do with the ramdisk
Click to expand...
Click to collapse
thanks for sharing your efforts, ill be downloading the source over night and tackling this in the morning, with this ill have a head start on it, appreciate sharing your work.
sk8erwitskil said:
so i diff'd the init.rc of the skyrocket cm10 and the init.rc and of the stock nexus4 system image from the android website and theyre exactly the same. so im guessing its not the init.rc. i tried copying over adbd and init from the n4 ramdisk but it gets stuck at the samsung logo.
edit: ignore that. i was looking at the same file. lol. this is what comes from no sleep
Click to expand...
Click to collapse
the issue is most definitely in the ramdisk. im 99% sure. so if anyone with ramdisk knowledge wants to help it would be very appreciated. i only know a little bit about what it should look like. the BOOTCLASSPATH needs to be changed and some permissions have been changed in 4.2 but besides that im lost. the init.rc that it builds is completely wrong. i think we would be best off taking the cm10 one and editing it.
sk8erwitskil said:
the issue is most definitely in the ramdisk. im 99% sure. so if anyone with ramdisk knowledge wants to help it would be very appreciated. i only know a little bit about what it should look like. the BOOTCLASSPATH needs to be changed and some permissions have been changed in 4.2 but besides that im lost. the init.rc that it builds is completely wrong. i think we would be best off taking the cm10 one and editing it.
Click to expand...
Click to collapse
which kernel modules did you use? since you added the kernel during the build?
gs2usr said:
which kernel modules did you use? since you added the kernel during the build?
Click to expand...
Click to collapse
i didnt manually add any modules. i thought those get added from the vendor/samsung/skyrocket folder.
sk8erwitskil said:
i didnt manually add any modules. i thought those get added from the vendor/samsung/skyrocket folder.
Click to expand...
Click to collapse
if the make file was not building you a kernel, then it shouldnt make you any modules, could you check if you have anything on dir system/lib/modules
gs2usr said:
if the make file was not building you a kernel, then it shouldnt make you any modules, could you check if you have anything on dir system/lib/modules
Click to expand...
Click to collapse
haha wow i totally missed that. it didnt add any modules. imma add the ones from cm10 to the zip and re-install and see if it works.
sk8erwitskil said:
haha wow i totally missed that. it didnt add any modules. imma add the ones from cm10 to the zip and re-install and see if it works.
Click to expand...
Click to collapse
added the modules and it still gets stuck in a boot loop
sk8erwitskil said:
haha wow i totally missed that. it didnt add any modules. imma add the ones from cm10 to the zip and re-install and see if it works.
Click to expand...
Click to collapse
Sounds good, keep us informed
Sent from my SAMSUNG-SGH-I727 using Tapatalk 2
just going through the overlays you removed. In the msm8660 overlays, you could keep
Code:
<string name="config_datause_iface">rmnet_sdio0</string>
as that is in the config.xml in AOSP, but is set to rmnet0 by default.
Also for the location provider, in AOSP, the default is:
Code:
[COLOR="RoyalBlue"]<!-- Package name(s) containing location provider support.
These packages can contain services implementing location providers,
such as the Geocode Provider, Network Location Provider, and
Fused Location Provider. They will each be searched for
service components implementing these providers.
It is strongly recommended that the packages explicitly named
below are on the system image, so that they will not map to
a 3rd party application.
The location framework also has support for installation
of new location providers at run-time. The new package does not
have to be explicitly listed here, however it must have a signature
that matches the signature of at least one package on this list.
-->[/COLOR]
<string-array name="config_locationProviderPackageNames" translatable="false">
[COLOR="RoyalBlue"]<!-- The standard AOSP fused location provider -->[/COLOR]
<item>com.android.location.fused</item>
but in CM10, it's this:
Code:
[COLOR="RoyalBlue"] <!-- Component name of the service providing network location support. -->[/COLOR]
<string name="config_networkLocationProvider">com.google.android.location.NetworkLocationProvider</string>
[COLOR="RoyalBlue"] <!-- Component name of the service providing geocoder API support. -->[/COLOR]
<string name="config_geocodeProvider">com.google.android.location.GeocodeProvider</string>
Also, in the celox-common overlays for Phone, all of those configs are in AOSP, so I'm not sure why they would need to be removed.
Doubt that any of this matters in terms of you not being able to boot, but I just thought I would make a note.
the fix for the kernel being added is here:
ifeq ($(TARGET_PREBUILT_KERNEL),)
LOCAL_KERNEL := device/samsung/skyrocket/kernel
else
LOCAL_KERNEL := $(TARGET_PREBUILT_KERNEL)
endif
PRODUCT_COPY_FILES += \
$(LOCAL_KERNEL):kernel
add to device.mk
sk8erwitskil said:
added the modules and it still gets stuck in a boot loop
Click to expand...
Click to collapse
Oh well, was worth a shot. Anyways should be added to the list, I probably wont be of much help until I have the source downloaded, but keep up the good work
Sent from my SAMSUNG-SGH-I727 using Tapatalk 2
gs2usr said:
Oh well, was worth a shot. Anyways should be added to the list, I probably wont be of much help until I have the source downloaded, but keep up the good work
Sent from my SAMSUNG-SGH-I727 using Tapatalk 2
Click to expand...
Click to collapse
i made some changes to device.mk to add the kernel to the out directory. hopefully it adds the modules as well. ill see once its done compiling again.
m4570d0n said:
just going through the overlays you removed. In the msm8660 overlays, you could keep
Code:
<string name="config_datause_iface">rmnet_sdio0</string>
as that is in the config.xml in AOSP, but is set to rmnet0 by default.
Also for the location provider, in AOSP, the default is:
Code:
[COLOR="RoyalBlue"]<!-- Package name(s) containing location provider support.
These packages can contain services implementing location providers,
such as the Geocode Provider, Network Location Provider, and
Fused Location Provider. They will each be searched for
service components implementing these providers.
It is strongly recommended that the packages explicitly named
below are on the system image, so that they will not map to
a 3rd party application.
The location framework also has support for installation
of new location providers at run-time. The new package does not
have to be explicitly listed here, however it must have a signature
that matches the signature of at least one package on this list.
-->[/COLOR]
<string-array name="config_locationProviderPackageNames" translatable="false">
[COLOR="RoyalBlue"]<!-- The standard AOSP fused location provider -->[/COLOR]
<item>com.android.location.fused</item>
but in CM10, it's this:
Code:
[COLOR="RoyalBlue"] <!-- Component name of the service providing network location support. -->[/COLOR]
<string name="config_networkLocationProvider">com.google.android.location.NetworkLocationProvider</string>
[COLOR="RoyalBlue"] <!-- Component name of the service providing geocoder API support. -->[/COLOR]
<string name="config_geocodeProvider">com.google.android.location.GeocodeProvider</string>
Also, in the celox-common overlays for Phone, all of those configs are in AOSP, so I'm not sure why they would need to be removed.
Doubt that any of this matters in terms of you not being able to boot, but I just thought I would make a note.
Click to expand...
Click to collapse
Thanks I'll add that to the doc tomorrow
Sent from my SAMSUNG-SGH-I727 using xda app-developers app
Hopefully you get this up &running. But you should soon, having Gs2 helping you out. Can't wait till this is complete so I can check it out. :good:
im trying to get aosp to compile the kernel like cm does. i added build/core/tasks/kernel.mk but it gets stuck on
Code:
out/target/product/skyrocket/obj/KERNEL_OBJ does not exist
when i check that folder does exist. for some reason its not recognizing it.
sk8erwitskil said:
im trying to get aosp to compile the kernel like cm does. i added build/core/tasks/kernel.mk but it gets stuck on
Code:
out/target/product/skyrocket/obj/KERNEL_OBJ does not exist
when i check that folder does exist. for some reason its not recognizing it.
Click to expand...
Click to collapse
if i just do that prebuilt kernel option then it doesnt add any modules. not sure how to fix that.
Quick Camera Fix #1
Installation:
1. Download CM13 based ROM made by transi1
2. Open and replace files from temp_camera_fix_from_BEANSTALK_6.20.zip to the ROM of your choice respectively (flashing doesn't work)
3. Flash ROM, GApps etc.
4. After installation of ROM, install Open Camera or other 3rd party camera app
DOWNLOAD #1
temp_camera_fix_from_BEANSTALK_6.20.zip
Description:
This is basically a 3.0.72+ kernel from BeanStalk 6.20
IT WAS TESTED ON: RR 5.7.3, Bliss ROM
USING TWRP 3.0.2-1 WITHOUT TEMP_TOUCH_FIX
DOWNLOAD #2
temp_camera_fix_from_RR_5.6.5.zip
Description:
This is basically a 3.0.72+ kernel from RR 5.6.5
DOWNLOAD #3
temp_camera_fix_from_AICP_11.0.zip
Description:
This is basically a 3.0.72+ kernel from AICP 11.0
Want to support development? You can consider donating, my email is [email protected]. I spent countless of hours with this
NOTE: Fix from BeanStalk 6.20 is updated (deep sleep issue fixed).
-------------------------------------------------------------------------------------------------------------------------------------------------
Quick Camera Fix #2
FLASHABLE ZIP
-------------------------------------------------------------------------------------------------------------------------------------------------
NOUGAT EMOJI FLASHABLE ZIP
-------------------------------------------------------------------------------------------------------------------------------------------------
OMNISWITCH FLASHABLE ZIP
-------------------------------------------------------------------------------------------------------------------------------------------------
THREAD CLOSED
Interesting workaround. If it works, it's even more evident that we're dealing with the 3.0.101+ kernel. I'm still planning on going through with that kernel backtracking to see which version or commit started this mess, and once I find it, report it so we can hopefully work through this. IIRC, those files were compiled against the 3.0.72+ kernel, so they might be a little old. Can someone try out the patch and see how it affects stability?
monster1612 said:
Interesting workaround. If it works, it's even more evident that we're dealing with the 3.0.101+ kernel. I'm still planning on going through with that kernel backtracking to see which version or commit started this mess, and once I find it, report it so we can hopefully work through this. IIRC, those files were compiled against the 3.0.72+ kernel, so they might be a little old. Can someone try out the patch and see how it affects stability?
Click to expand...
Click to collapse
2016/02/20 is the date of creation of last AICP. So, we need to find commits since that date and before.
alexander_32 said:
2016/02/20 is the date of creation of last AICP. So, we need to find commits since that date and before.
Click to expand...
Click to collapse
I already forked the repos prior to the post-3.0.72+ commits. I'll link in the manifest file I created if you're interested in building against them.
monster1612 said:
I already forked the repos prior to the post-3.0.72+ commits. I'll link in the manifest file I created if you're interested in building against them.
Click to expand...
Click to collapse
Yes, bring it, please.
alexander_32 said:
Yes, bring it, please.
Click to expand...
Click to collapse
Here's the manifest file for building against those repos. I'm going to backtrack through the commits by forking the original repos at different points in time. Obviously, the old repos I forked before the 3.0.101+ commits are going to stay as they are for the time being until the issue is pinpointed and fixed once and for all. After that, I plan on deleting the manifest file and repos. Make sure that you run repo sync --force-sync on your build tree after replacing the manifest file and make clean to revert the kernel, or you'll still have remnants of 3.0.101+ lurking in the builds.
monster1612 said:
Here's the manifest file for building against those repos. I'm going to backtrack through the commits by forking the original repos at different points in time. Obviously, the old repos I forked before the 3.0.101+ commits are going to stay as they are for the time being until the issue is pinpointed and fixed once and for all. After that, I plan on deleting the manifest file and repos. Make sure that you run repo sync --force-sync on your build tree after replacing the manifest file and make clean to revert the kernel, or you'll still have remnants of 3.0.101+ lurking in the builds.
Click to expand...
Click to collapse
Thanks.
Like I said to @alexander_32, I tried reverting the u-boot.bin commits that Transi made a couple months back for the aicp build. It booted, ran really slow, and OpenCamera still saw the camera module as being in use. Using the current boot binary things run nice and fast again. The build I ran off last night testing a couple more things also did not have any effect on camera...
electrikjesus said:
Like I said to @alexander_32, I tried reverting the u-boot.bin commits that Transi made a couple months back for the aicp build. It booted, ran really slow, and OpenCamera still saw the camera module as being in use. Using the current boot binary things run nice and fast again. The build I ran off last night testing a couple more things also did not have any effect on camera...
Click to expand...
Click to collapse
Probably it something else. Did you check my method by the way?
electrikjesus said:
Like I said to @alexander_32, I tried reverting the u-boot.bin commits that Transi made a couple months back for the aicp build. It booted, ran really slow, and OpenCamera still saw the camera module as being in use. Using the current boot binary things run nice and fast again. The build I ran off last night testing a couple more things also did not have any effect on camera...
Click to expand...
Click to collapse
What'd you happen to test with last night's build? Also, was it my u-boot commit that caused the problems or before that?
monster1612 said:
What'd you happen to test with last night's build? Also, was it my u-boot commit that caused the problems or before that?
Click to expand...
Click to collapse
I tested a couple of camera specific build tags in bowser common and tate. They didn't work. When I get a chance later on, I plan on diving into it again.
@alexander_32: Not sure why, but I can't boot using this with the rom you posted here. It stays on the boot logo indefinitely. After a clean install and making sure it boots fine once, I'm manually flashing the boot.img in the zip and copying the contents of the modules dir while fixing permissions afterwards. Is that all there is to it or am I missing something?
r3t3ch said:
@alexander_32: Not sure why, but I can't boot using this with the rom you posted here. It stays on the boot logo indefinitely. After a clean install and making sure it boots fine once, I'm manually flashing the boot.img in the zip and copying the contents of the modules dir while fixing permissions afterwards. Is that all there is to it or am I missing something?
Click to expand...
Click to collapse
You just extracting all files from camera fix, then update cm13.0 flashable zip with files from camera fix and flash flashable zip. It worked on Temasek's CM13. I'll do more researches and inform about results.
alexander_32 said:
You just extracting all files from camera fix, then update cm13.0 flashable zip with files from camera fix and flash flashable zip. It worked on Temasek's CM13. I'll do more researches and inform about results.
Click to expand...
Click to collapse
Ah, I read the OP wrong and wasn't merging into the rom zip but manually into existing installation. Though even now, I still can't boot after trying it with plain cm13, beanstalk, or temasek. I'm using twrp 2.8.7.0 with cache and data both f2fs if that makes any difference.
Has anyone else had success so far and if so with which roms?
r3t3ch said:
Ah, I read the OP wrong and wasn't merging into the rom zip but manually into existing installation. Though even now, I still can't boot after trying it with plain cm13, beanstalk, or temasek. I'm using twrp 2.8.7.0 with cache and data both f2fs if that makes any difference.
Has anyone else had success so far and if so with which roms?
Click to expand...
Click to collapse
I guess now I understand what happened. I flashed my fix first, then did factory reset and flashed changed zip. I'll test it and inform what happened
CONFIRMED: It's 3.0.72+ kernel.
http://i66.tinypic.com/33mwkyw.png
http://i64.tinypic.com/33u8qow.png
CONFIRMED: PAC ROM MM works!
http://i66.tinypic.com/2n8v5uf.png
CONFIRMED: Cyanogenmod works!
http://i64.tinypic.com/2eunbz9.png
CONFIRMED: BeanStalk works! (Solution was a kernel from RR 5.6.5 with blue logo)
http://i67.tinypic.com/107rwx2.png
alexander_32 said:
UNBELIEVABLE! It works on Temasek only! But I'm not done yet. Need some time to think.
Confirmed: It's 3.0.72+ kernel.
http://i66.tinypic.com/33mwkyw.png
http://i64.tinypic.com/33u8qow.png
I'll update this thread with more information.
Click to expand...
Click to collapse
I'm thinking it doesn't work on transi's RR or CM13 builds because he disabled the camera with some commits that he hasn't pushed to GitHub. Either way, those builds are built with 3.0.101+, and the patches you brought in are from 3.0.72+. It would make sense if they didn't boot after patching (especially if you flash the boot.img). What happens if you just replace the files in /system and leave the boot image intact?
monster1612 said:
I'm thinking it doesn't work on transi's RR or CM13 builds because he disabled the camera with some commits that he hasn't pushed to GitHub. Either way, those builds are built with 3.0.101+, and the patches you brought in are from 3.0.72+. It would make sense if they didn't boot after patching (especially if you flash the boot.img). What happens if you just replace the files in /system and leave the boot image intact?
Click to expand...
Click to collapse
My builds work with 3.0.101+ as well, but Temasek's works and BeanStalk doesn't (with 3.0.72+). Yes, I'll try it.
monster1612 said:
I'm thinking it doesn't work on transi's RR or CM13 builds because he disabled the camera with some commits that he hasn't pushed to GitHub. Either way, those builds are built with 3.0.101+, and the patches you brought in are from 3.0.72+. It would make sense if they didn't boot after patching (especially if you flash the boot.img). What happens if you just replace the files in /system and leave the boot image intact?
Click to expand...
Click to collapse
I tried that yesterday, and it results in never getting to the boot animation, so the kernel never loads.
5 from 7 for today. A new link https://www.androidfilehost.com/?fid=24591000424949408
I have an old Samsung phone running on Marshmallow. I want to build android and flash it on the old phone. Many take Google Pixel to show how to do it and say it’s not possible to do it on non-Google device. Is there a way to get around it?
KrishnaD3V said:
I have an old Samsung phone running on Marshmallow. I want to build android and flash it on the old phone. Many take Google Pixel to show how to do it and say it’s not possible to do it on non-Google device. Is there a way to get around it?
Click to expand...
Click to collapse
Sure. Here's some reading material on how to build a custom Android operating system. https://www.androidauthority.com/build-custom-android-rom-720453/
If it all seems too much, you could instead install a custom Android operating system prebuilt by others. One such example is LineageOS which has its own website and installation instructions.
You will have to first determine the exact model and sub-variant of your Samsung phone.
Then determine whether it is network carrier unlocked.
Then determine whether the bootloader is allowed to be unlocked (allow oem unlocking).
LineageOS Downloads
download.lineageos.org
Thanks for the reply
Do you know how to obtain proprietary binaries for a device?
KrishnaD3V said:
Thanks for the reply
Do you know how to obtain proprietary binaries for a device?
Click to expand...
Click to collapse
Depends on the the exact device model? (Go to settings =>About phone) (or in the dialler, type *#0*# then tap on 'version'). Then search the XDA forum for that device, then spend some time scrolling through the posts to find the info you're searching for. https://forum.xda-developers.com/c/samsung.11975/
*#0*# doesn’t give any option for version. So I thought to see in settings. What ‘version’ should I look for?
Go to settings =>About phone
Look for a code which which looks similar to SM-GTI9100
KrishnaD3V said:
Thanks for the reply
Do you know how to obtain proprietary binaries for a device?
Click to expand...
Click to collapse
Either extract them from phone's Stock ROM file, or pull them out of phone.
zpunout said:
Go to settings =>About phone
Look for a code which which looks similar to SM-GTI9100
Click to expand...
Click to collapse
It’s SM-A800I running android 6.0.1 . And it’s not on the list that you sent. What can I do?
jwoegerbauer said:
Either extract them from phone's Stock ROM file, or pull them out of phone.
Click to expand...
Click to collapse
I do have the stock rom file but I can’t find guide on how to do so. I found a video where person extracts it from lineage os. Is the process going to be the same? And by the way does it matter which version of stock rom I have because the phone came with android 5 and I updated it to 6 with official update.
KrishnaD3V said:
It’s SM-A800I running android 6.0.1 . And it’s not on the list that you sent. What can I do?
Click to expand...
Click to collapse
Yeah, there's not much development on that device, I read somewhere that Samsung supposedly never released the source code. It is hard to search for, but I did find this link: https://forum.xda-developers.com/t/...al-cyanogenmod-13-for-galaxy-a800f-i.3344081/
I did find out that the nickname of your SM-A800I model is "a8hplte" which might help you in search engines.
Looks like a dead end to me though.
KrishnaD3V said:
I do have the stock rom file but I can’t find guide on how to do so. I found a video where person extracts it from lineage os. Is the process going to be the same? And by the way does it matter which version of stock rom I have because the phone came with android 5 and I updated it to 6 with official update.
Click to expand...
Click to collapse
The so-called binary blobs are kinds of hardware drivers, you can't simply extract them of a Custom ROM, you have to extract them from a phone's original Stock ROM, as I told you this already earlier.
These binary blobs typically are found under /vendor/lib(64), some also under /system, /etc and /bin.
Most of the blobs are executable files or libraries, run as independent services on phone's boot.
jwoegerbauer said:
The so-called binary blobs are kinds of hardware drivers, you can't simply extract them of a Custom ROM, you have to extract them from a phone's original Stock ROM, as I told you this already earlier.
These binary blobs typically are found under /vendor/lib(64), some also under /system, /etc and /bin.
Most of the blobs are executable files or libraries, run as independent services on phone's boot.
Click to expand...
Click to collapse
Thanks for the info
zpunout said:
Yeah, there's not much development on that device, I read somewhere that Samsung supposedly never released the source code. It is hard to search for, but I did find this link: https://forum.xda-developers.com/t/...al-cyanogenmod-13-for-galaxy-a800f-i.3344081/
I did find out that the nickname of your SM-A800I model is "a8hplte" which might help you in search engines.
Looks like a dead end to me though.
Click to expand...
Click to collapse
Not so beginner friendly I guess . I try my luck extracting the blobs as described by
jwoegerbauer.