Related
First off, I'm brand new to Android development so please bear with me.
My only goal at this point is to add the ability to choose the notification LED color to the Android 2.2 stock mail app (on the Droid). I've searched all over the place and haven't found an existing solution for this yet.
It seems to me like it should be super easy to add this functionality to the stock mail app. I can already choose my sound and vibrate settings, why not the LED color? Toss in some notification.ledARGB = something (plus the few other lines of code to make it work), a list to choose the color and we're good to go.
My problem, though, is I have no idea where to begin to have access to the code of the stock mail app. I would guess it goes something like:
1. Download the apk
2. Somehow open the source
3. Make the changes I need
4. Turn it back into a useable apk
5. Swap out the existing apk with my new modified one on the phone
I really only care about making this work on my own phone, so I'm not worried about signing the apk with a public cert or anything. I'm rooted as well, so no worries there.
Anyone have any insight? If I basically have the right plan of attack, and advice on the specifics? If I'm totally wrong in my approach, any advice on what I should be doing would be greatly appreciated.
Thanks in advance for any help!
I think this app is a part of AOSP, so you don't have to decompile an apk - grab sources and build them.
Well, that certainly makes sense. Just did some digging, and I found a pile of info about getting the source, git, repo, etc.
Naturally I'm a windows user, so it looks like I'll need to get some linux up and running to actually do anything with the source code. Ubuntu is installing as we speak....
Any tips on what to do next for a newbie like me?
Should I follow all the directions to get Eclipse ready to develop on the linux box?
Do I just need to download the Email.git to do what I want?
What do I do with the Email.git once I've gotten it?
Just gonna give this a little bump. I've got my linux box all set up and i've got the entire android source downloaded. I'm not really sure where to go from here, though.
How do I just modify and compile the email app into an apk? Thanks for any forthcoming handholding, guys.
my last mytouch4 worked out just fine... this ine however is pissing me off
I have done everything i can think of
uninstall-reinstall-wipe cache in recovery and still wont work right. dont get it.. last one worked right out the gate.
nlarge said:
my last mytouch4 worked out just fine... this ine however is pissing me off
I have done everything i can think of
uninstall-reinstall-wipe cache in recovery and still wont work right. dont get it.. last one worked right out the gate.
Click to expand...
Click to collapse
All that ranting, but no information as to what is actually going on. Are you getting an error message? FC?
Still getting ads.....
AFAIK, adfree simply adds a hosts file with the add servers in it, in which case you are seeing adds because either the servers changed or there are new ad servers that haven't been added yet. Devs need incentive to do the work they do, so just be happy that you can even get good apps for free and deal with it.
jdkoren said:
AFAIK, adfree simply adds a hosts file with the add servers in it, in which case you are seeing adds because either the servers changed or there are new ad servers that haven't been added yet. Devs need icnentive to do the work they do, so just be happy that you can even get good apps for free and deal with it.
Click to expand...
Click to collapse
An app is only as good as it works. I have run into the same issue as the op recently. Also I'm getting real tired of reading these smart ass remarks at the end of posts here to just like yours. Its unnecessary!
hey.. try this:
http://forum.xda-developers.com/showthread.php?t=919040
The above methods seem to work for me. I've never used adfree btw...
There is something odd going on with hosts. I have the same problem as you that ads continue. I have traced mine to the fact that the hosts file is continually overlaid by the default blank one. It appears there is some component that continually scans this and wipes it.
I posted this problem a couple months ago but never got a response. The best I did was install GScript Lite and create a script to copy my saved off version of the ad-free hosts file back over the real one. It is not a good solution but the only one I have. I suppose the ultimate solution would be a different ROM. But that would just trade the problem I understand for an unknown number of ones I don't.
ethutch said:
There is something odd going on with hosts. I have the same problem as you that ads continue. I have traced mine to the fact that the hosts file is continually overlaid by the default blank one. It appears there is some component that continually scans this and wipes it.
I posted this problem a couple months ago but never got a response. The best I did was install GScript Lite and create a script to copy my saved off version of the ad-free hosts file back over the real one. It is not a good solution but the only one I have. I suppose the ultimate solution would be a different ROM. But that would just trade the problem I understand for an unknown number of ones I don't.
Click to expand...
Click to collapse
i dont use adfree
ive never had an ad using this hosts file
extract it from the zip, and put it in system/etc
enjoy
Has anyone tried enabling the AdFree option to symlink to /local/data (I think? forgot the exact path it gives in the app). I use that and have never experienced any problems with this on Ice Glacier.
It works for me, perhaps its a device specific problem.
SE7EN- said:
An app is only as good as it works. I have run into the same issue as the op recently. Also I'm getting real tired of reading these smart ass remarks at the end of posts here to just like yours. Its unnecessary!
Click to expand...
Click to collapse
While I somewhat agree with your post, I agree with jdkoren's more. All of the apps you are blocking ads for were free, free because of the ads that help fund the development of the apps. So I think he's just saying, if you can't block the ads, accept it, you have all those apps at no cost... Everything we experience, this forum, these custom ROMs, market apps, all took great amounts of time and effort, I think sometimes we lose sight of that when we think about open source projects.
I've seen a couple posts regarding getting Google Wallet to work (and hopefully I'm not being redundant with this post). I've had Google Wallet working on my own 2.3.5 source ROM for quite some time now and I figured I'd share what got it working for me. As a matter of disclosure, I do have the 4G, but I haven't seen anything in the code that would give reason for why this wouldn't work.
While I'm able to build a ROM, I for some reason, don't know how to put together a flashable update. Maybe somebody with a little more know-how can piece this together and try it out, or at least tell me I'm wrong.
Files needed from the GWK74 ROM:
system/etc/permissions/com.google.android.nfc_extras.xml
(I just added the permission entry to the existing com.android.nfc_extras.xml file instead to keep the clutter down).
system/framework/com.android.nfc_extras.jar
The version in the GWK74 ROM contains code that has yet to be released, since korg is down and all. The extra file has something to do with NFC emulation, but I've only glanced at it, so I really couldn't tell you what it does.
system/app/Wallet.apk
Obviously.
Here's the catch: The Wallet app requires permissions from Nfc.apk (NFCEE_ADMIN). By default, the Nfc.apk is signed with the "platform" key, but as long as these two files are signed with the same key, it will grant it the proper permissions to Wallet.apk no matter what key that may happen to be. Considering that Nfc.apk also requests other permissions from "platform" as well, certificate consistency would be advisable.
Hope this works out or at the very least, gets the ball rolling.
Hopefully, someone can make like a flashable zip for CM7 or at least let us know which files need to be copied to our GSM phones so we can extract those files and copy it to system
do you mind zipping up the files used and posting them here?
They're basically the stock files from GWK74 with Wallet.apk and Nfc.apk signed with the same key. My only concern is that since I've used a private key on my own ROM for a while now, I don't remember/know how many or which non-stock ROMs are signed with anything other than the testkeys or which key would be the best for (most) everyone. If the testkeys work universally, I could do that, but I'd hate for someone with differing platform keys getting upset that it's still doing the same FC as before.
For those familiar with using the Android Kitchen, it can do the signing and packaging with testkeys if you're willing to reflash. Might be an easier step for some to take if the command line method seems overwhelming.
As far as Google Wallet working on a GSM Nexus S. I believe there is more protection than it appears. I firmly believe Google has not only modified the NFC drivers and added NFC security to both the drivers and the Firmware. But I also think they added security to the rils and network checks.
How did I get to these conclusions? Well I actually ported the whole NS4G rom over to the GSM. The only things I really had to change were ril libs and the build.prop. Everything else is pretty similar between the two phones. NFC worked and I was able to start up Google Wallet, however, when attempting to add a card to Google Wallet, it kept loading for like 10 minutes until it gave an error. No real description of the error and logcats revealing nothing. Taking out my sim card, I was greeted with a message in Google Wallet that I should check my sim card and insert it if its not inserted. Why would Google Wallet even have anything to do with carriers even connected to wifi? There must be some other things added.
Then I went ahead and decided to revert to a backup of my CM7. I noticed NFC no longer would turn on, it kept giving me an error. Looking at a logcat it looked like it was trying to download and install firmware but failed. Other NS4G users have experienced this same error. Logcats show that it is downloading firmware but failing to be able to install it. My theory: Google added extra security to the firmware located directly onto the NFC chip itself. So now no ROMs (including the new 2.3.6) give me working NFC except for that 2.3.7 rom. I'm still working on trying to fix.
Now I am happy you posted this thread, because maybe if I backport these additions to a GSM rom I might be able to fix NFC. I'm not sure as of yet. I am going to attempt Odin next, but I can already guarantee Formatting System, Boot, Cache, Data did not resolve the issue.
They definitely added something to the firmware. After flashing GWK74 nfc no longer works on 2.3.5. If I flash back to GWK74 it works no problem.
Sent from my Nexus S 4G using xda premium
U could test that driver theory with a chip that hasnt gotten the 2.3.7 update.
apreichner said:
As far as Google Wallet working on a GSM Nexus S. I believe there is more protection than it appears. I firmly believe Google has not only modified the NFC drivers and added NFC security to both the drivers and the Firmware. But I also think they added security to the rils and network checks.
How did I get to these conclusions? Well I actually ported the whole NS4G rom over to the GSM. The only things I really had to change were ril libs and the build.prop. Everything else is pretty similar between the two phones. NFC worked and I was able to start up Google Wallet, however, when attempting to add a card to Google Wallet, it kept loading for like 10 minutes until it gave an error. No real description of the error and logcats revealing nothing. Taking out my sim card, I was greeted with a message in Google Wallet that I should check my sim card and insert it if its not inserted. Why would Google Wallet even have anything to do with carriers even connected to wifi? There must be some other things added.
Then I went ahead and decided to revert to a backup of my CM7. I noticed NFC no longer would turn on, it kept giving me an error. Looking at a logcat it looked like it was trying to download and install firmware but failed. Other NS4G users have experienced this same error. Logcats show that it is downloading firmware but failing to be able to install it. My theory: Google added extra security to the firmware located directly onto the NFC chip itself. So now no ROMs (including the new 2.3.6) give me working NFC except for that 2.3.7 rom. I'm still working on trying to fix.
Now I am happy you posted this thread, because maybe if I backport these additions to a GSM rom I might be able to fix NFC. I'm not sure as of yet. I am going to attempt Odin next, but I can already guarantee Formatting System, Boot, Cache, Data did not resolve the issue.
Click to expand...
Click to collapse
Thanks for chiming in. Appreciate the info
Hmm, that's odd because aside from those three files and the vendor binaries, everything else on my ROM is from the 2.3.5 source files (since I don't have a choice for source files, really). The first thing I tried when Wallet was giving me fits was to poke around the APKs to see if they were holding any additional files, but I didn't locate any in Wallet and the NFC app file is too small to hold any additional files (and doesn't, since I checked anyway). The 2.3.7 nfc_extras JAR file only contains three java files (compared to the two from 2.3.5) so I don't suspect anything warranting investigation.
It's hard to imagine Google going through so much trouble to block their own product on their own phone. Unfortunately, I don't have access to a non-Sprint Nexus S, so I cannot account for the SIM message you experienced, but the hardware vendor for the NFC component appears to be the same (NXP) for both phones and it just doesn't make sense for them to use two different components for the same model of nearly identical phones. I'll try using the libpn544_fw.so binary from the standard crespo and see what kind of (ill) effects I experience.
I did notice during my trial-and-error period that the error messages and the manner in which they would show up seemed to vary slightly. Adding the JAR file alleviated the persistent com.google.android.apps.walletnfcrel FC during startup and use. After that, the signing took care of the persistent 'insufficient system privileges' (or something to that effect) on startup.
I'd be interested in what is in your log readout. Personally, logcat gets visually overwhelming to me, so I just use ddms to filter out the other processes and error messages from obfuscating what I'm looking for. The thing that Wallet is trying to access is NFC permissions, which Nfc.apk appears to have sole (or at least primary) responsibility for. All of the protests coming from Wallet that I observed were related to its inability to be granted permissions from Nfc for NFCEE_ADMIN, which is specified in its AndroidManifest file as being under protectionLevel="signature", of which it is assigned to "platform" by default. That would explain why people with the stock ROM can get it to work, since it still retains the Google signature keys structure. I suspect most of the alternative ROMs are running some varying key structure, but that is just speculation on my part. I suppose modifying the AndroidManifest file to explicitly give permission to Wallet would also address that, but at the time, I considered that unnecessarily tedious.
I'm still betting on certificate-connected privileges being the primary culprit, but I'll give the NFC binary file a run and see what happens.
Update:
Ran with the libpn544_fw.so from crespo and Wallet initially FCed. I pulled the file through ADB first to make sure it was the one installed and it was, but after the FC, I pulled the file again and it was the regular one for crespo4g. So, unless I misread it or made a mistake somewhere, something is replacing the file. I pushed the original file back, ran it, and pulled it again and it seemed to stick, but I suspect it's running from cache. So basically, it appears that the binary from crespo is insufficient, as I got numerous errors in ddms as a result. I don't know if it has the same effect both ways though. Has anybody tried the crespo4g NXP binary yet with any luck?
Also, I do apologize for some misinformation earlier. The 2.3.7 NfcGoogle.apk does contain a libnfc_jni.so file, but it's already in system/lib, so I don't know if that has to do with anything relevant.
Need some help i get this error message when i push the files to newest Cm7 nightly based on 2.3.7. Any ideas?
XK72 said:
It's hard to imagine Google going through so much trouble to block their own product on their own phone.
Click to expand...
Click to collapse
Well keep in mind it's not just Google that's involved, but MasterCard, Citi, MoneyNet or whatever that service is that processes the transactions... they may have mandated that some extra security measures be taken to keep the initial rollout limited to a relatively small specific group.
david279 said:
Need some help i get this error message when i push the files to newest Cm7 nightly based on 2.3.7. Any ideas?
Click to expand...
Click to collapse
I encountered the same issue a while back. It's related to the signature keys on Wallet, which is signed with Google's key out of the box. If the rest of your build is signed with testkeys (which appears to be the case), you can resolve that by signing Wallet.apk with testkeys as well.
tobiasly said:
Well keep in mind it's not just Google that's involved, but MasterCard, Citi, MoneyNet or whatever that service is that processes the transactions... they may have mandated that some extra security measures be taken to keep the initial rollout limited to a relatively small specific group.
Click to expand...
Click to collapse
While Google Wallet is a proprietary application, and as such, Google or the forces that be could possibly be responsible for what's occurring and I wouldn't be able to discern whether or not that is true, I personally don't believe that is the reason behind what is happening.
(This is just as I understand it). There certainly are security measures in place for NFC, which the Android system is responsible for handling. The Wallet app is essentially an interface that is PIN secured on the user end and requests relevant permission from Nfc.apk that manages interaction with the NFC-related subset on its behalf. If anything, the credit card companies are concerned with unauthorized transmissions that could result in financial liability on their end. The fact that Wallet requires signature-protected permission authorization from Nfc to access the NFC element shows that Android is not leaving security duties up to the Wallet app alone.
I think the hindrances in getting this to work for everyone is that the people who could develop a fix probably don't have access to the Nexus S hardware variants. I started with the same or similar issues that people faced when trying to incorporate Wallet into their build and eventually got it to work on a 2.3.5 sourced build was the steps above, but I also don't own a standard Nexus S for me to test with, so I couldn't proclaim that it was a definitive fix. I was hoping, at the very least, that it might be contributive towards finding a fix for everyone.
XK72 said:
I encountered the same issue a while back. It's related to the signature keys on Wallet, which is signed with Google's key out of the box. If the rest of your build is signed with testkeys (which appears to be the case), you can resolve that by signing Wallet.apk with testkeys as well.
Click to expand...
Click to collapse
How do I sign apks? Can you send me a wallet apk signed with test keys?
Sent from my Nexus S 4G using xda premium
---------- Post added at 06:03 PM ---------- Previous post was at 05:39 PM ----------
Ok i found a app in the market for signing apks, zips, etc. but im getting the same error.
XK72 said:
While Google Wallet is a proprietary application, and as such, Google or the forces that be could possibly be responsible for what's occurring and I wouldn't be able to discern whether or not that is true, I personally don't believe that is the reason behind what is happening.
(This is just as I understand it). There certainly are security measures in place for NFC, which the Android system is responsible for handling. The Wallet app is essentially an interface that is PIN secured on the user end and requests relevant permission from Nfc.apk that manages interaction with the NFC-related subset on its behalf. If anything, the credit card companies are concerned with unauthorized transmissions that could result in financial liability on their end. The fact that Wallet requires signature-protected permission authorization from Nfc to access the NFC element shows that Android is not leaving security duties up to the Wallet app alone.
I think the hindrances in getting this to work for everyone is that the people who could develop a fix probably don't have access to the Nexus S hardware variants. I started with the same or similar issues that people faced when trying to incorporate Wallet into their build and eventually got it to work on a 2.3.5 sourced build was the steps above, but I also don't own a standard Nexus S for me to test with, so I couldn't proclaim that it was a definitive fix. I was hoping, at the very least, that it might be contributive towards finding a fix for everyone.
Click to expand...
Click to collapse
I will attempt to port it over. Good news is there's some 2.3.7 source available now to build with. I don't have much hope though because a full port didn't even work on a GSM device. Although newer libs might help.
Sent from my Nexus S using xda premium
apreichner said:
I will attempt to port it over. Good news is there's some 2.3.7 source available now to build with. I don't have much hope though because a full port didn't even work on a GSM device. Although newer libs might help.
Sent from my Nexus S using xda premium
Click to expand...
Click to collapse
Do you know where they're hosting the 2.3.7 source? I just realized that they released the 2.3.7 binaries for both crespo and crespo4g, so between those two, there really shouldn't be anything else getting in the way of making this work.
Here: http://forum.xda-developers.com/showthread.php?t=1284517
People are reporting that Wallet works just fine on I902x phones and stock rooted 2.3.6. I'm only one there unable to add prepaid card. Guess it's because my IMEI is generic, and i'm pretty sure that google is using IMEIs for authentication and similar processes...
One factor may be branch of code. In build numbers, the letters have meanings. First letter is Android version (G for Gingerbread). Second letter is branch. Usually this is R for Release. The build for NS4G is W. I don't know what this W branch is. Maybe special "Wallet" branch.
http://source.android.com/source/build-numbers.html
Sent from my Nexus S using XDA App
First of all, forgive me if this is not the right forum to ask this question, because I'm not sure what is.
Hi everyone,
So the company that provides the TV channels in my country (like the cable companies in the US) has a streaming service that streams most of these channels online to phones, tablets, computers.
The problem is that their app is, according to them "not supported on hacked devices". Just so we're clear, we're talking about Android here, and hacked = root/custom rom, which this stupid company considers illegal. In some devices, they check both root and custom rom, in some only one of them, and in some the app will work even if you have both. For example, on my Nexus 4 the app worked with stock rom that was rooted. Now that I am running a custom rom, trying to hide root using various apps does not work. So obviously the problem, with my device at least, is running the custom rom.
I'm currently learning Java & Android development and have decided to use the little knowledge that I have to try to find the lines of code responsible for this idiotic check.
I looked up many tools for decompiling apps and have finally found a good one, called JadX.
http://androidcracking.blogspot.co.i...ler.html#links
This decompiler is excellent, but gives me a scary amount of code files to look. Even so, trying to search all of them (JadX has that functionality) for the code that checks for root/custom rom has turned up nothing. I have also tried to search for the message they give me when I open the app (about hacked devices not working) but I found nothing, again.
One more thing - a developer that also tried to solve this problem said he traced the problem back to DxDrmDlcCore. I searched it, found it a some class, but not sure what to do now (delete the entire class and recompile?)
Can someone here direct me towards what I need to be looking for?
OR
Is the solution really simple, such as editing my build.prop? Someone suggested it once, but did not know what lines to edit.
If someone is ready to step up to the challenge, I can upload the apk.
Thank you!
This is incredibly ridiculous. Why is there a limit on how many messages I can send in a certain period of time? I would like to know if there is any way to remove it. I have searched relentlessly.
1. settings.db doesn't exist anymore and therefore cannot be changed to set a custom limit.
2. I'm rooted, have EX kernel and Pure Nexus 7.1.1 ROM. Neither support changing the limit natively.
Decimation001 said:
This is incredibly ridiculous. Why is there a limit on how many messages I can send in a certain period of time? I would like to know if there is any way to remove it. I have searched relentlessly.
1. settings.db doesn't exist anymore and therefore cannot be changed to set a custom limit.
2. I'm rooted, have EX kernel and Pure Nexus 7.1.1 ROM. Neither support changing the limit natively.
Click to expand...
Click to collapse
The limit is probably set by your carrier. If that's the case you won't be able to change it in the ROM or phone build prop.
jhs39 said:
The limit is probably set by your carrier. If that's the case you won't be able to change it in the ROM or phone build prop.
Click to expand...
Click to collapse
Is it in the build prop? There wasn't a limit on a different phone.
Decimation001 said:
Is it in the build prop? There wasn't a limit on a different phone.
Click to expand...
Click to collapse
The limit just started when you got the 6P? How long were you using the phone before the limit became an issue? Are you on stock or a custom ROM? Who is your phone carrier? Are you using a stock SMS Program or different one? Maybe someone will have an answer if you provide more information. What is the limit, by the way? Do you know? I know that the program Automate limits texts as a security precaution. Maybe a third party program is causing the issue. Have you tried booting into safe mode and seeing if the limit still exists?
jhs39 said:
The limit just started when you got the 6P? How long were you using the phone before the limit became an issue? Are you on stock or a custom ROM? Who is your phone carrier? Are you using a stock SMS Program or different one? Maybe someone will have an answer if you provide more information. What is the limit, by the way? Do you know? I know that the program Automate limits texts as a security precaution. Maybe a third party program is causing the issue. Have you tried booting into safe mode and seeing if the limit still exists?
Click to expand...
Click to collapse
The limit is on my 6P running Resurrection Remix 7.1.1 on francoKernel. NOT on my other Note5 which is 6.0.1 stock kernel and ROM. Both are/were on T-Mobile. Both use Textra. Not sure what the limit is.
Decimation001 said:
The limit is on my 6P running Resurrection Remix 7.1.1 on francoKernel. NOT on my other Note5 which is 6.0.1 stock kernel and ROM. Both are/were on T-Mobile. Both use Textra. Not sure what the limit is.
Click to expand...
Click to collapse
Maybe something went wrong when you installed your custom ROM or Kernel. I've never heard of a text message limit on the Nexus 6P. You get an error message when you try and send a text saying you have reached the limit and the text can't be sent? Or is it a size limit? Or a limit to the number of recipients you can send a message to? I've heard of limits on the latter two but not on total number of messages that can be sent. At least not in North America.
jhs39 said:
Maybe something went wrong when you installed your custom ROM or Kernel. I've never heard of a text message limit on the Nexus 6P. You get an error message when you try and send a text saying you have reached the limit and the text can't be sent? Or is it a size limit? Or a limit to the number of recipients you can send a message to? I've heard of limits on the latter two but not on total number of messages that can be sent. At least not in North America.
Click to expand...
Click to collapse
The limit was both on Pure Nexus and RR. It limits how many messages I can send to anyone within a certain amount of time. I can still press "accept" to send but it's really annoying and spams me.
That kind of sounds like you might have malware/adware installed on your phone. You might want to download something like Malwarebytes and do a scan of your phone.
The SMS limit is built into Android. Previous to N it was a setting that could be altered in the build.prop and an option to change it was baked into RR. With N the settings were moved into the framework (from what I could find it appears it the telephony section?) and the option to change the setting was not baked into the new ROMs.
I have made several posts requesting info on how to change this - but, no one has responded (either they don't know, don't care, or haven't seen my posts). I need this option for work so badly I'm willing to learn how to build my own ROM. But, not worth getting started if I don't know how to fix the one important thing I need changed.
shaneaus said:
The SMS limit is built into Android. Previous to N it was a setting that could be altered in the build.prop and an option to change it was baked into RR. With N the settings were moved into the framework (from what I could find it appears it the telephony section?) and the option to change the setting was not baked into the new ROMs.
I have made several posts requesting info on how to change this - but, no one has responded (either they don't know, don't care, or haven't seen my posts). I need this option for work so badly in selling to learn how to build my own ROM. But, not worth getting started if I don't know how to fix the one important thing I need changed.
Click to expand...
Click to collapse
If the limit is built into Android why is nobody else having the same problem as you? Do you do something with your SMS that the average user doesnt't? Are you using your SMS to send advertising to large numbers of people, for instance?
jhs39 said:
If the limit is built into Android why is nobody else having the same problem as you? Do you do something with your SMS that the average user doesnt't? Are you using your SMS to send advertising to large numbers of people, for instance?
Click to expand...
Click to collapse
I don't understand why you are even asking this... I appreciate you willingness to help out. But... If you can't help out - just don't respond. You have exhibited that you don't have any knowledge of the settings we are speaking of - AND, I explained the setting is now in the framework. So, unless you know of a way to modify the framework without building a custom ROM - then, please stop implying that we don't have an issue - just because you don't understand what the issue is...
Your first response "The limit is probably set by your carrier" was uneducated speculation.
Your second response included several questions the OP had answered in his original post - he stated he had researched the issue, was using a custom rom/kernel... Then, you followed that up by more speculation: "Maybe a third party program is causing the issue. ."
Your third response isn't helpful as you merely question the OP's knowledge that he even knows he has an issue: "I've never heard of a text message limit on the Nexus 6P." Basically, you just admit your ignorance of there being an issue: " I've heard of limits on the latter two but not on total number of messages that can be sent." Which would imply to most that you won't have any knowledge of how to fix said issue.
Your forth response is to suggest there is malware? Again implying that the OP has no idea about what they are speaking.
Finally, when I post and explain that the setting was once there and easily modified with a build.prop change and that the code was moved...
You again imply that we have some sort of 'phantom issue:' "why is nobody else having the same problem as you?"
If you don't know the answer why waste our time? Do a search and you could easily find another post or two here on XDA in which I explained my situation/problem...
Once again, if you can help - we will surely appreciate any assistance! But, if you don't KNOW how to help; please, don't continue to ask questions which suggest we don't know what we are talking about.
@Decimation001 - I did some research and inside the framework there are two sections related to "telephony" (which is where it appears the settings were moved). Seems they are ODEX files. Might be able to de-compile, make a correction, re-compile, replace in current ROM. I'll start looking into it over the next week or so.
I guess you can keep talking to yourself then.
I have got the same problem. I want to sent to silvester round about 140 SMS to my people and got the message because of the limit.
shaneaus said:
Once again, if you can help - we will surely appreciate any assistance! But, if you don't KNOW how to help; please, don't continue to ask questions which suggest we don't know what we are talking about.
@Decimation001 - I did some research and inside the framework there are two sections related to "telephony" (which is where it appears the settings were moved). Seems they are ODEX files. Might be able to de-compile, make a correction, re-compile, replace in current ROM. I'll start looking into it over the next week or so.
Click to expand...
Click to collapse
Can you give me the names of the files? I know how to compile and recompile so I'd be happy to try and make some modifications.
jhs39 said:
I guess you can keep talking to yourself then.
Click to expand...
Click to collapse
No need to get your feelings hurt. But, I'm not here to "just talk to people" or socialize. I'm here to attempt to solve an issue. If you can assist - then, I will be very grateful for any assistance!
@Decimation001:
Here is the old build.prop method (posted from a member on another Android forum:
"Note: If you move to Marshmallow this will not work anymore as the file "settings.db" is irrelevant under Android 6.0 (annoying but true)
You need:
Root
something like Root explorer and sqLite editor
Open this file: /data/data/com.android.providers.settings/databases/settings.db
Go to "global" subsection, then look for the following two entries
"sms_outgoing_check_max_count" and "sms_outgoing_check_interval_ms"
If they don't exist (by default they aren't there) then create them.
Set the first one to whatever you want (its the maximum number of texts you can send per timeframe (eg.1000)
Set the second one to whatever timeframe you are measuring in millisecond units (eg. 1800000)
My settings were
sms_outgoing_check_max_count 1000
sms_outgoing_check_interval_ms 1800000
This example limits my texts to 1000 messages every 30 minutes
Close file, making sure to save saving if requested to do so.
Reboot system. The new settings will override the Android internal ones.
Hacked "
However, I sent him a PM and he does not know how to make the change in the newer versions of Android. From research I did it appeared that Android moved this setting into the Framework under "Telephony" and you can see that in the structure here:
https://www.researchgate.net/figure...-Android-Telephony-system-architecture-from-6
I've been trying to look for the merge/change in the files here:
https://android.googlesource.com/platform/frameworks/opt/telephony/
I haven't found the specific change/code yet.
However, if you use Root Explorer in an installed ROM - you might find the relevant code by unpacking/searching here:
/system/framework/telephony-common.jar/classes.dex
/system/framework/telephony-ext.jar/classes.dex
I'll try to keep looking for the change in the source code - should have occurred during the transition from Android 5.0 to 6.0....
shaneaus said:
No need to get your feelings hurt. But, I'm not here to "just talk to people" or socialize. I'm here to attempt to solve an issue. If you can assist - then, I will be very grateful for any assistance!
@Decimation001:
Here is the old build.prop method (posted from a member on another Android forum:
"Note: If you move to Marshmallow this will not work anymore as the file "settings.db" is irrelevant under Android 6.0 (annoying but true)
You need:
Root
something like Root explorer and sqLite editor
Open this file: /data/data/com.android.providers.settings/databases/settings.db
Go to "global" subsection, then look for the following two entries
"sms_outgoing_check_max_count" and "sms_outgoing_check_interval_ms"
If they don't exist (by default they aren't there) then create them.
Set the first one to whatever you want (its the maximum number of texts you can send per timeframe (eg.1000)
Set the second one to whatever timeframe you are measuring in millisecond units (eg. 1800000)
My settings were
sms_outgoing_check_max_count 1000
sms_outgoing_check_interval_ms 1800000
This example limits my texts to 1000 messages every 30 minutes
Close file, making sure to save saving if requested to do so.
Reboot system. The new settings will override the Android internal ones.
Hacked "
However, I sent him a PM and he does not know how to make the change in the newer versions of Android. From research I did it appeared that Android moved this setting into the Framework under "Telephony" and you can see that in the structure here:
https://www.researchgate.net/figure...-Android-Telephony-system-architecture-from-6
I've been trying to look for the merge/change in the files here:
https://android.googlesource.com/platform/frameworks/opt/telephony/
I haven't found the specific change/code yet.
However, if you use Root Explorer in an installed ROM - you might find the relevant code by unpacking/searching here:
/system/framework/telephony-common.jar/classes.dex
/system/framework/telephony-ext.jar/classes.dex
I'll try to keep looking for the change in the source code - should have occurred during the transition from Android 5.0 to 6.0....
Click to expand...
Click to collapse
I found the files. It's SmsUsageMonitor.class in telephony-common.jar. It has the values:
Code:
this.mLimit.set(Settings.Global.getInt(this.mContext.getContentResolver(), "sms_outgoing_check_max_count", 30));
this.mPeriod.set(Settings.Global.getInt(this.mContext.getContentResolver(), "sms_outgoing_check_interval_ms", 60000));
Now the problem is recompiling and making it a jar again.
@shaneaus Dang dude, chill out...
Hungry hustler said:
@shaneaus Dang dude, chill out...
Click to expand...
Click to collapse
I am very "chill." Don't understand why you made the comment.
@Decimation001 That is awesome! It took me quite awhile to hunt down different forum threads to find out where the settings had been moved. I was all prepared to attempt to start learning how to compile/decompile those files! But, between working 70 hrs/wk, spending one night with my kids, one night with my girlfriend, and monitoring my home which is under construction - I just haven't had the time! My partner who shares responsibility for sending out the texts for the contract work we schedule is anxiously waiting on my finding a solution! I'm hoping you can re-compile the file!
I'm just concerned at this point that this would have to be done every single time a new version of a ROM is used... Wondering if it could be made into a flashable .zip file which would only change that line of code changing the 30 to 200 or 300....
In any case - is this something we could just extract the classes.dex file, use apktool to decompile, change "30" to "300", recompile, and push the altered .dex file back into place? I understand using "tools" isn't the best way to go - but, I won't have much time to devote to this for the next 4-6 months. So, if apktool will do the trick for now... I'm willing.
Decimation001 said:
I found the files. It's SmsUsageMonitor.class in telephony-common.jar. It has the values:
Code:
this.mLimit.set(Settings.Global.getInt(this.mContext.getContentResolver(), "sms_outgoing_check_max_count", 30));
this.mPeriod.set(Settings.Global.getInt(this.mContext.getContentResolver(), "sms_outgoing_check_interval_ms", 60000));
Now the problem is recompiling and making it a jar again.
Click to expand...
Click to collapse
Ok, I figured out how to decompile the "classes.dex" file using baksmali. However, I can't find the Telephony-common.jar file.
I have found similar code here: out/com/Android/internal/telephony/SmsUsageMonitor$SettingsObserver.smali
".line 248
const-string/jumbo v2, "sms_outgoing_check_max_count"
const/16 v3, 0x1e"
Also, in this file: SmsUsageMonitor$SettingsObserverHandler.smali
" .line 263
const-string/jumbo v1, "sms_outgoing_check_max_count""
But, I don't know how to modify it as it isn't in the format I'm accustomed to seeing... From what I read it is in a smali syntax and I don't know how to modify this code.
@Decimation001 - any ideas?
---------- Post added at 02:54 AM ---------- Previous post was at 02:17 AM ----------
Decimation001 said:
I found the files. It's SmsUsageMonitor.class in telephony-common.jar. It has the values:
Code:
this.mLimit.set(Settings.Global.getInt(this.mContext.getContentResolver(), "sms_outgoing_check_max_count", 30));
this.mPeriod.set(Settings.Global.getInt(this.mContext.getContentResolver(), "sms_outgoing_check_interval_ms", 60000));
Now the problem is recompiling and making it a jar again.
Click to expand...
Click to collapse
shaneaus said:
Ok, I figured out how to decompile the "classes.dex" file using baksmali. However, I can't find the Telephony-common.jar file.
I have found similar code here: out/com/Android/internal/telephony/SmsUsageMonitor$SettingsObserver.smali
".line 248
const-string/jumbo v2, "sms_outgoing_check_max_count"
const/16 v3, 0x1e"
Also, in this file: SmsUsageMonitor$SettingsObserverHandler.smali
" .line 263
const-string/jumbo v1, "sms_outgoing_check_max_count""
But, I don't know how to modify it as it isn't in the format I'm accustomed to seeing... From what I read it is in a smali syntax and I don't know how to modify this code.
@Decimation001 - any ideas?
Click to expand...
Click to collapse
Ok... Looks like if I change the hexadecimal "0x1e" (means 30) below to "0x12c" (means 300), save, recompile using baksmali, and re-insert into my ROM it should work?:
out/com/Android/internal/telephony/SmsUsageMonitor$SettingsObserver.smali
".line 248
const-string/jumbo v2, "sms_outgoing_check_max_count"
const/16 v3, 0x1e"
Ok. I think I did it. I extracted the "telephony-common.jar" file from system/framework. I used 7zip to open it and took the classes.dex file out. I placed the classes.dex file into my smali/baksmali folder, decomplied, changed the above line of code in the manner indicated, recompiled.... I opened telephony-common.jar back up (confirmed that classes.dex was not present), copied the newly updated classes.dex file into telephony-common.jar. I placed it into a folder on the device. Using the app Root Explorer I had two tabs open and deleted the original telephony-common.jar file and immediately copy/pasted the new one in it's place. Just to be sure it worked I extracted the classes.dex file again and decompiled it to confirm.
I'll test it out tomorrow with a mass text to all of my sub-contractors. If it works - I'll edit/post the detailed instructions on the first post in this thread.