-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Overhead due to disconnected Service #3
Comments
I totally agree that the handling of pSetMan/checking the service/responding to problem needs to be improved. For this first pass, I was more concerned with adding deny-on-fail functionality, knowing that I'd need to clean it up. The basic structure I was thinking is this: switch (privacyOutcome) { The reason the 'pSetMan == null' check is necessary is because reflection can be used to destroy the pSetMan object. Is that pretty similar to what you were thinking? |
Just have a look at my new patches. You can find my solution in the class: PrivacySettingsManager.java |
Sorry, I'm not sure where your new patches are. I don't see them in Github, and the first post of the XDA thread doesn't seem to have a modified version. |
Fix long press home button for recent apps
Also: * add a second history section that logs * log mesg as text instead of number * dump Sync Status as a table Sample log: Recent Sync History #1 : 2012-10-11 15:06:11 USER 0.4s aagmtest1@gmail.com/com.google u0 com.android.calendar com.google.android.calendar #2 : 2012-10-11 15:06:11 USER 0.1s aagmtest1@gmail.com/com.google u0 subscribedfeeds android.uid.system:1000 mesg=parse-error #3 : 2012-10-11 15:06:11 USER 0.0s aagmtest1@gmail.com/com.google u0 com.google.android.apps.uploader.PicasaUploadProvider android.uid.system:1000 #4 : 2012-10-11 15:06:10 USER 0.1s aagmtest1@gmail.com/com.google u0 com.google.android.gms.plus.action android.uid.system:1000 Recent Sync History Extras #1 : 2012-10-11 15:06:11 USER aagmtest1@gmail.com/com.google u0 com.android.calendar Bundle[{feed=aagmtest1@gmail.com, force=true, ignore_settings=true, ignore_backoff=true}] #2 : 2012-10-11 15:06:11 USER aagmtest1@gmail.com/com.google u0 subscribedfeeds Bundle[{ignore_backoff=true, force=true, ignore_settings=true}] #3 : 2012-10-11 15:06:11 USER aagmtest1@gmail.com/com.google u0 com.google.android.apps.uploader.PicasaUploadProvider Bundle[{ignore_backoff=true, force=true, ignore_settings=true}] #4 : 2012-10-11 15:06:10 USER aagmtest1@gmail.com/com.google u0 com.google.android.gms.plus.action Bundle[{ignore_backoff=true, force=true, ignore_settings=true}] Sync Status Account aagmtest1@gmail.com u0 com.google ======================================================================= Authority Syncable Enabled Delay Loc Poll Per Serv User Tot Time Last Sync Periodic ------------------------------------------------------------------------------------------------------------------------------------------------------------- com.google.android.apps.currents 1 true 0 2 1 2 1 6 0:35 PERIODIC SUCCESS 86400 2012-10-12 14:59:40 2012-10-13 14:58:13 com.google.android.music.MusicContent 1 true 0 0 1 2 1 4 0:09 PERIODIC SUCCESS 86400 2012-10-12 14:59:18 2012-10-13 14:58:13 com.google.android.gms.plus.action 1 true 0 0 1 1 1 3 0:00 PERIODIC SUCCESS 86400 2012-10-12 14:59:15 2012-10-13 14:58:13 com.google.android.apps.magazines 1 true 0 1 1 2 1 5 0:14 PERIODIC SUCCESS 86400 2012-10-12 14:59:00 2012-10-13 14:58:13 Change-Id: Iffeb825e4b4f6217940a39b0dd71e06856f08f3f
Hey,
good to know that you recognized it that the service sometimes is disconnecting itself. First, the pSetMan won't be "null" at any time, so you don't have to check if it is available or not (i did it in the past, just to be sure :-D). Second, you've added so much code in ALL privacy related classes for checking these two things. Why you don't implemented an central "reconnector" which will solve this directly inside the privacySettingsManager? I've done it in this way and you need only 2 methods.
Tested with hammering and flooding and it works like a charm. In my opion, it is a better way because you now you get a stable connection whenever you want to interact with the service.
What do you think about? Less work and more central implementation or do you prefer your solution?
The text was updated successfully, but these errors were encountered: