Hi,
I'm trying to build the default Email app from source.
Using the CM10.2 as base: https://github.com/CyanogenMod/android_packages_apps_Email
I used some patches, which I successfully applied, as this is the main reason of doing this whole thing
At first I tried using apktool but that didn't work out.
Currently I'm struggling with importing the necessary libs in eclipse (adt-bundle-windows-x86_64-20130917; target API 18 aka 4.3.x).
First issue is that even though I am using Google APIs i'm still missing com.google.common. Without google APIs i'm missing the whole com.google...
apparently the app has it's own libs com.android.emailcommon which are provided with the application.
I had to add emailcommon/src in the buildpath because the rest of the app was referencing it.
Problem here is under com.android.emailcommon.service.EmailServiceProxy: IEmailService cannot be resolved to a type. I'm seeing though that IEmailService.aidl exists so why isn't it seeing that interface?
I'd be gratefull for any help here.
Thanks!
bump
please help
any some hint would be nice!
bump?
Related
Hi guys,
I was wanting to look at the default sms app to see how it works and possibly look into modifying parts. I've googled high and low and still havent found the source, does anyone know how I would get it just for the sms app?
Any help is much appreciated.
Sorry, can't post links, but here is some source for you.
Code:
public void sendSMS(String phoneNumber, String message)
{
SmsManager sms = SmsManager.getDefault();
Pendingetent pi = Pendingetent.getActivity(this, 0, new Intent(this, SMS.class), 0);
sms.sendTextMessage(phoneNumber, null, message, pi, null);
}
Don't forget to set manifest permissions for "SEND_SMS" and "RECEIVE_SMS" if required.
Code:
<manifest>
...
<uses-permission android:name="android.permission.SEND_SMS">
</uses-permission>
...
</manifest>
Thanks, much appreciated. How come you are not able to post links? would it be possible to PM them to me? Thanks again.
http://android.git.kernel.org/?p=platform/packages/apps/Mms.git;a=summary
I had this exact same thought yesterday.
I was thinking that I could easily take the stock SMS app and modify it to include what I consider an annoyingly missing feature, marking a message or thread unread. How hard could it be? Just add a new item to a context menu and then some SQL that will mark the message unread.
Well, apparently it is kinda hard.
Here's what I did:
I got the source for the SMS app by typing this:
git clone git://android.git.kernel.org/platform/packages/apps/Mms.git
Then I went to Eclipse, created a new Android project and said "from existing source" and pointed it to this folder I'd just checked out of the repository.
FAIL.
Tons of red Xs in Eclipse. Tons of references it couldn't find. I started digging through the repo to see if I could find the things it wanted and started adding those to the project, but one thing just lead to another missing dependency and after adding half a dozen other apps I just gave up.
Maybe I need the entire framework or something? In that case, I have no idea how to set up the project and how to build just that app based on the stock app.
I know this can be done. People have branched other stock apps (the launcher, the email client, etc.) and released their own enhanced versions. But I just couldn't figure out how to get started -- I couldn't even build an UNMODIFIED version.
If anyone can point me in the right directions, that would be quite helpful.
Thanks!
Sorry for pushing a somewhat dated thread, but this topic is very interessting for me as well since all Messaging apps currently kind of suck and I really like the minimalistic approach of the default app but it lacks basic features.
Any new ideas?
A link to the best source I could find:
http://grepcode.com/file/repository...pps/4.0.3_r1/com/android/mms/MmsApp.java?av=f
Questions or Problems Should Not Be Posted in the Development Forum
Please Post in the Correct Forums & Read the Forum Rules
Moving to Q&A
okay thank you
Anyone knows where to get the source?
Any help would be greatly appreciated!
Found it!
https://github.com/android/platform_packages_apps_mms
edit: Weird problem. Lots of errors with missing classes/methods even though I can find those classes in online repos with the same API level (4.0.3). Importing those classes is not an option since a lot of new dependencies would be missing.
I know that the source is MMS for 4.0.4 but I find a lot of sources with the needed classes in the 4.0.3 framework. How is that possible?
edit2: Just found out that Google introduced their own Javadoc where they can hide experimental methods/classes for certain APIs but still use them in their stock apps. Now I only have to find a way to trick the system
I'm not a developer myself, but I had one create me some software to output apks for live wallpapers using video. Still had some bugs in the resulting apks but didn't seem like was going to get any further in getting them resolved so I just ended the project figuring that I can probably get someone else to fix it later.
So right now I'm wondering, would sending the apk (that came from my software) to another developer be enough for them to locate the bugs and optimize the individual apk. Which whatever actions were needed will be noted and have either them or someone else implement them into my current software. (I'm assuming the source code is in the apk itself)
I like many other have been experiencing Force closes on Google Play Music, Movies, and YouTube after the latest updates on ICS based roms. I have seen people report experiencing this problem on Stock, Liquid, AOKP, and CM9 on various devices. I myself have wiped data and even tried it on a completely fresh rom install from what I could tell there were no files on my SD card generated from previous versions of Google Play Music that would cause the problem. On my regular rom I uninstalled and wiped any existence of the old version multiple times. When I place the widget on my home screen it'll shuffle and play through my locally stored music on my sd card (not pinned music actually music I copied my self). It seems to be wanting to display an element but that it doesn't exist so it crashes.
I reported the crash inside the Stack trace it includes the error:
java.lang.RuntimeException: Unable to start activity ComponentInfo{com.google.android.music.activitymanagement.TopLevelActivity}: android.view.InflateException: Binary XML file line #6: Error inflating class android.app.MediaRouteButton
Here is a logcat for the Google Play Music FC as well http://pastebin.com/VP2cSmN1 It seems to be the same exact bug that causes YouTube to crash although the Play Movies is a slightly different but similar bug from what I can tell.
I think more people are needed so that this bug is noticed and fixed. I created a thread on the Google Support forums here I encourage everyone that is having this problem to make a post so that it is noticed and fixed.
https://productforums.google.com/forum/#!msg/mobile/a6u2tK6a49g/-Juju-8C9vQJ
Please post in this thread if you are having this problem or if you have a solution to the problem. Now obviously the easiest solution would be for Google to update all the apps with a fix but possibly the problem could lie with the individual custom roms. Any information that anyone has on these issues would be welcome and needed to get this problem fixed.
EDIT: Here is the old Google Play Music APK to downgrade. http://forum.xda-developers.com/showthread.php?t=1533816
EDIT: After a little research I found this in the documentation for Android and apparently it's a class that is only found in Jelly Bean which brings me to the question why is it trying to use it on an ICS rom?
http://developer.android.com/reference/android/app/MediaRouteButton.html
EDIT: Raeled found out if you remove the res/layout-v16 folder from the apk file the apps no longer force close. The Movies app had an additional res/menu-v16 folder I had to remove. Keep in mind I don't know what side effects this will have on the apps but so far from what I have seen they work fine however I haven't rented any movies. Also because these are modified with an APKTool the signature was broken so you will have to uninstall your older versions to use them and I don't think you will be able to install any updates from the Google Play Store since the signature won't match. Anyways at least a solution until Google can fix the problem or our custom rom developers can find what causes the apps to want to use the Level 16 API.
EDIT: If you're a rom developer you can fix this problem in your rom by applying this change and recompiling from source. Explanations of why you need to do this can be found below.
https://github.com/aospX/platform_build/commit/a34ffcecc7c237ac9c9e263984f6a74d3a7c3831
I'm on AOKP and having the same issue. Would very much appreciate a fix :fingers-crossed:
Thanks for posting hopefully we get more attention to this issue!
I am using EOS ICS (4.0.4) on my Xoom 3G and aospx ICS on my Desire HD and was experiencing the FC's on both of them.
Have been doing some experimenting on altering the APK to get it to work on my device. I've been using APKTool to remove the "\res\layout-v16" folder from the APK. That seemed to do the trick and the modified app seemed to run fine on both the devices.
This raises the question for me why "layout-v16" would get used at all in the first place as my limited Android knowledge tells me it should not be used on API 15 (4.0.4).
I'm not completely sure what this all means but to me it looks like the devices are telling the apps that it is running on Jelly Bean while it is actually not.
Would you be able to post your modified apk files?
EDIT: I was able to do it however if you know how to do it without breaking signatures so that they can just update over the other apps that would be great.
Altering the APK without breaking the sign should not be possible. Even if it was we'd probably need to "fix" every new version anyways.
I have been looking in the android documentation and the resource should indeed not be used according to the specs on the Android development website.
To test further i have created a simple APK file (attached) that will print out the current API level. It also has to "res\layout" and a "res\layout-v16". When i run it on my device it will (just like music apk) select the v16 resource while the API level is 15. When i ask the API level using code it correctly reports 15.
Also changed folder to "res\layout-v17" quick just for a test but then the devices didn't pick this resource. So it will correctly skip API 17 content
So it seems the system does know it's API 15 but will still get API 16 resources.
If the case is that the problem is in the custom roms and the official ICS roms do not have this problem i think the change that Google is gonna fix this is pretty low.
Raeled said:
Altering the APK without breaking the sign should not be possible. Even if it was we'd probably need to "fix" every new version anyways.
I have been looking in the android documentation and the resource should indeed not be used according to the specs on the Android development website.
To test further i have created a simple APK file (attached) that will print out the current API level. It also has to "res\layout" and a "res\layout-v16". When i run it on my device it will (just like music apk) select the v16 resource while the API level is 15. When i ask the API level using code it correctly reports 15.
Also changed folder to "res\layout-v17" quick just for a test but then the devices didn't pick this resource. So it will correctly skip API 17 content
So it seems the system does know it's API 15 but will still get API 16 resources.
If the case is that the problem is in the custom roms and the official ICS roms do not have this problem i think the change that Google is gonna fix this is pretty low.
Click to expand...
Click to collapse
Yeah basically the Google Guy basically said our custom rom people need to fix it which is probably true however in my mind they could just as easily make a separate ICS APK like they have a separate APK for Gingerbread not a hard thing to do. But I hope that you're able to find the root of this problem I don't really have enough experience with this to know how to solve it in the rom. But you are saying that if there is API 16 material in the Apps it will pick it up and use it no matter what app it is?
I've used the android SDK to create 2 ICS Virtual devices. (4.0: API 14 and 4.0.3: API 15). These devices resolved the resources as they where supposed to do. After that i installed the Google Play Music app on them and also those worked perfectly fine.
The change that google is gonna fix this is next to none. The APK is not in error here. If they do this fix then they'd be saying that the specs are "more like guidelines"
And yes, this problem will spread to every app that will use API 16 only functionality in an API 16 only resource.
Yeah I've pretty much come to the conclusion that there is something wrong with the actual roms that need to be fixed by our developers! Just the root of the problem needs to be found.
The following are speculations as i messed up my Xoom by testing it. So use caution when trying to do what i did.
After some exploration in the Android source i found that the resource manager (the component that is responsible for loading the "res\layout", a.o.) is initialized not by using the "Build.Version.SDK_INT" (this has the correct value of 15), but by another property "Build.Version.RESOURCES_SDK_INT". This can be found in the source at: "\core\java\android\content\pm\PackageParser.java" (line 497 & 712).
Moving to source at "\core\java\android\os\Build.java" (line 120) we find out that "RESOURCES_SDK_INT" is based on "SDK_INT" but adds +1 if "CODENAME" is not equal to the value "RES". A few lines up we see that codename is read from the "ro.build.version.codename" key in the "build.prop" file. In the roms i use this value is "AOSP" so this means the resource sdk version gets +1 and will start to prefer Jelly Bean resources.
I tried to modify my "build.prop" file but this caused my xoom to not get past the boot animation. So once more: be carefull
doesn't this mean it should be 15 instead of aosp? This other rom theirs has the value of REL they claim not to have the same issue we are having but I can't confirm this.
Oh by changing this for whatever reason it thought apps weren't there and decided to wipe a bunch of the app data... I just backed up the system so that was awesome!
Sent from my ThunderBolt using Tapatalk 2
Link_of_Hyrule said:
doesn't this mean it should be 15 instead of aosp?
Sent from my ThunderBolt using Tapatalk 2
Click to expand...
Click to collapse
The "ro.build.platform.codename" is automatically set by the flag PLATFORM_VERSION_CODENAME in build/core/version_defaults.mk when compiling from source..Which =AOSP stands for development build and REL is release build. But by changing PLATFORM_VERSION_CODENAME := REL this does in fact fix this issue as Raeled suspected (tested by installing latest Google Play Music and latest YouTube, both work fine now.. )..
https://github.com/aospX/platform_build/commit/a34ffcecc7c237ac9c9e263984f6a74d3a7c3831
thanks Raeled
But it requires recompiling the entire rom from source?
existz said:
The "ro.build.platform.codename" is automatically set by the flag PLATFORM_VERSION_CODENAME in build/core/version_defaults.mk when compiling from source..Which =AOSP stands for development build and REL is release build. But by changing PLATFORM_VERSION_CODENAME := REL this does in fact fix this issue as Raeled suspected (tested by installing latest Google Play Music and latest YouTube, both work fine now.. )..
https://github.com/aospX/platform_build/commit/a34ffcecc7c237ac9c9e263984f6a74d3a7c3831
thanks Raeled
Click to expand...
Click to collapse
So this means that your next rom build is going to be possible to use the google music and youtube app from the market without any problems?!?!
Link_of_Hyrule said:
But it requires recompiling the entire rom from source?
Click to expand...
Click to collapse
Correct..it seems that once compiled with =AOSP, all the system packages check this and if it doesn't return as a development platform (=AOSP) it crashes..this is why just changing it in build prop does not work..So the whole rom needs recompiled with =REL.
onesolo said:
So this means that your next rom build is going to be possible to use the google music and youtube app from the market without any problems?!?!
Click to expand...
Click to collapse
Yes, changes are already pushed to git and will be in next release.
Sent from my Inspire 4G using xda app-developers app
Well your devices are lucky to have a dev actively working on fixing this it seems us Mecha users will have to wait for a dev to come along and release a new build or new ICS rom with the fix.
EDIT: Finally got it fixed in the up coming build
can u please update to the latest yt version?
Bump
Sent from my MZ601 using XDA Premium HD app
Youtube app (v4.1.23) & Google Play Music (v4.3.615.481147):
Thanks raeld can you put up the latest version 4.1.47 to please?
Firstly I would like to apologise if I am asking my question in the wrong area. If so then I am happy for a moderator to move to the correct location.
I have some understanding of how to decompile apps, modify and then recompile. All my work is done using APKTool via a command line and a test keystore that I found in a tutorial. I've even recently learnt how to create my own keystore using the Java Keytool. The vast majority of the time I am able to accomplish what I want, by this I mean making small amendments to the code (.xml & .smali) to suit my preference - usually little things such as correcting typos. I am however struggling with Google apps, such as Messenger, Hangouts etc. The process I am carrying out is correct, the app even installs correctly on my Android device. However upon launching the app it will then just crash.
My question is, do Google prevent their apps from being reverse engineered using special tools? I there something else I should be taking into consideration when dealing with Google apps?
Any help is greatly appreciated.
Thank you
Hey all,
There's an app I need help updating to either api 24/26 . The app which is meant to interface with the Joyetech Ocular/Ocular C, which is on Google Play,
https://play.google.com/store/apps/details?id=com.zijing.joyetech
The problem is, the devs of the app hasn't updated it since api 22, and after sending emails to the devs on multiple channels, there's no response.
Looking at the logcat of an app's activity, the Android app derives keys using the SHA1PRNG algorithm from the Crypto provider, and as of Android N, apps must start using a real key derivation function.
My issue is that:
1: I'm very mediocre at things like this. (Decompile, import into Eclipse, edit as needed, then recompile.)
2: My laptop doesn't have enough space to install Eclipse.
Would anyone with more knowledge on this subject be willing to update this apk for me?