Related
In regard to the latest update does anyone know specifics about what they changed?
Yeah they improved battery life, but what did they actually change?
Before the update I was lucky to make it 4 hours of listening to music on a charge.
Last night, after patching, I made it all the way thru a 9 hour shift while listening to Pandora, and still had 15% left.
Omg :O
It seems they may have tweaked that mediaserver. Normally it would rape the battery, often using 60% or more, while Pandora would only use 25%.
But this time it was only at 28%
Also, I noticed when I came home and plugged my phone into my computer via USB, the keyboard back light would turn off
When I unplugged it, back light came back on. (This was a pitch black room btw)
It doesn't do it with the wall charger, just USB.
I dont recall this happening before they tweaked the keyboard lights, anyone else notice this?
So I guess it would be nice to know specifics about what they changed with that too.
I don't know specifics, but I also noticed improvements with the mediaserver. I was having trouble with the battery draining rapidly for no good reason after running Pandora. So far so good after the patch. Also, gps lock fix.
Sent from my DROID4 using XDA
Generic Changelog: http://omgdroid.com/update-dont-forget-the-droid-4/
Oddly, they don't mention the gps I mentioned above, even though my location lock time has gone from "wait..." to instant.
Sent from my DROID4 using XDA
It appears no body knows, or has bothered to look
I guess the next question is how do I go about doing this.
Curiosity is killing me
Hey, here is the changelog from the soak test:
Comment:
Software Upgrade for the DROID 4 by Motorola
INTRODUCTION
We are pleased to announce the new software update for DROID 4 by Motorola. The software upgrade (Version 6.13.219.XT894.Verizon.en.US) includes numerous enhancements. Install today for peak performance.
For more information on Motorola updates and product support, visit us at www.motorola.com/mydroid4
WHO CAN USE THIS UPDATE
ALL Motorola DROID 4 users. After downloading and installing the software release, you will notice the following enhancements and improvements:
Applications & Widgets
+ Successfully receive Visual Voice Mail notifications.
+ Proper Visual Voice Mail messages will display when data has been disabled.
+ The Share application now directs users to the App page in Google Play.
+ Enhanced security in Verizon Apps.
Device Features
+ Enhanced loud call end and connect tones over Bluetooth®.
+ Power ON function has been fixed.
+ Improved battery performance.
+ Verizon Wireless requests have been bookmarked for keyboard quick key default settings.
+ Device now supports IPv6. As new internet addresses are introduced, you will be able to continue to browse and view web pages with this latest internet enhancement.
+ Improvements made to reduce touch screen lockups, device sluggishness and blank screen lockups.
+ Keypad backlight only launches when needed.
+ Successfully type on hardware keyboard in the App Tray without experiencing “Force Close” issues with the home screen.
Network Connectivity
+ 4G coverage indicator accurately displays data connectivity.
+ Improvements to Wi-Fi mobile hotspot connectivity.
Email, Messaging & Data
+ Improved text message delivery when using the Messaging application
MotoCast by Motorola
+ Improvements to MotoCast™ responsiveness.
+ MotoCast widget can be added to home screen.
+ Successfully view large music transfers from remote computers.
+ Thumbnails are visible in the timeline even if PCs are offline.
+ Thumbnails are quickly visible in mixed views.
Step-by-Step Instructions
For instructions on how to perform the download, please visit www.verizonwireless.com/droid4support.
Additional Information
There is no charge for this update other than the usual data connection charges. Subject to change without notice.
If you have difficulty with this update, visit us at www.motorola.com/mydroid4 or www.motorola.com/support, or to get help from other owners on our online community at https.//supportforums.motorola.com.
Certain features, services and applications are network dependent and may not be available in all areas; additional terms, conditions and/or charges may apply. Specific functionality and features with each software version of Android may vary. Contact your service provider for details.
MOTOROLA and the Stylized M Logo are trademarks or registered trademarks of Motorola Trademark Holdings, LLC. All other product and service names are the property of their respective owners. © 2012 Motorola Mobility Inc. All rights reserved.
© 2012 Motorola. DROID is a trademark of Lucasfilm Ltd. and its related companies. Used under license.
[HELP CENTER] How to prevent § handle wakelocks § save battery life[GUIDE] [β]
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Thread Purpose:
Information, help and support for those, who experiencing battery drain.
Some of the material was taken from respective BetterBatteryStats thread - Check it out, for the sake of information and correct explanation. I take no credit for this info and grateful for it's existance.
References and credits: @ahalford for all his hard work
& : Chasmodo - you know, who you are!
For the info & software: BetterBatteryStats creator & team
What is wakelock and why it may cause battery drain:
Wakelocks or to be more precise partial wakelocks is a pattern (in fact a class) than helps devs to make sure that important pieces of their code do not get interrupted.
Basically the phone has (simplified, kernel devs don't shoot) three states:
1. awake with screen on
2. awake
3. sleeping (that's you phone favorite state)
The transitions are from (1) to (2) and finally from (2) to (3). Now as long as you use your phone it's in (1) and does not leave that state as long as you keep using it interactively. If you stop using it the phone is aiming to go to (3) as fast as possible.
And here's where wakelocks are important: as our phones as smartphones they tend to do background processing. Some of this processing is important like e.g. making a phone call, listening to music or synchronizing your contacts.
As the phone wants to go from (2) to (3) and on the other hand you don't want to hang up while you are in a call the app keeps hold of a wakelock to prevent that transition. When you hang up the partial wakelock gets release and here we go (the phone goes to sleep).
So partial wakelocks is a tool and it's not something that we should forbid for obvious reasons. Now there are cases when the design on an app is not real life proven (conditions of poor of no coverage) and the wakelocks have negative effects because they are held unnecessarily or for too long.
How can we identify it?
BetterBatteryStats app identifies these wakelocks and using your expertise or the once from our users here you can understand what happens and find a strategy to change that for the better.
How can we eliminate it, if we found such?
The purpose of this thread - is support per situation, if solution has not been
found after reading FAQ & Tips section. You should provide BetterBatteryStats dump file, data about rom/kernel, (possibly) list of installed apps and describe your situation.
How to provide dump file:
Code:
[B]- Install the app and grant it root access.
- Plug/unplug the charger
- "Menu" - "More" - "Set Custom Ref." - creates a reference point
- Leave the phone with screen off for some time, 4 to 6 hours - this must be done so we can have uncluttered data as a basis for valid analysis
- Ensure you have the same wakelocks, that you've been about to report.
- Save a dump file - "Menu" - "More" - "Dump to file"
- It will look like - sdcard/BetterBatteryStats-2012-09-10_191252250.txt, for example
- Check that the chapters "Kernel wakelocks", "wakelocks" & "alarms"are populated.[/B]
I'm not posting the app FAQ on purpose - those, who can't handle it, can just provide a dump file. Those, who can understand or learn fast - don't need it
But. Brief explanation, about where to look at the wakelocks:
1.Set your reference as "Since unplugged" in the second line.
2. Then, in the first line: "Other" - look at the "Awake" vs "Screen on". If it differs a lot, continue with a drill-down.
3. First line - check under "Partial Wakelocks" and "Kernel wakelocks".
4. "Menu" - "More" - "Raw kernel wakelocks"
5. For more help: "Menu" - "Help" - "Getting started" or "How to".
6. Same web links:
Help:
http://asksven.github.com/BetterBatteryStats-Knowledge-Base/help.html
How to:
http://asksven.github.com/BetterBatteryStats-Knowledge-Base/howto.html
App Screenshots:
[/FONT]
Want to install Cyanogen or AOKP rom and have questions? Get here.
TYPICAL REASONS FOR WAKELOCKS & APP SUCKERS, KNOWN ISSUES:
- Any kind of messengers, social clients – like Skype, Facebook, Twitter, etc. Any of those, who want to be online, receive a push messages, sync every while. If it’s must to have them, disable it in accounts sync settings, and disable notifications in each app’s setting.
- “Energy savers” – Green Power, Timeriffic, etc. They mess with the system power policy, if you choose to enable/disable wi-fi, gps, data, Bluetooth, etc. Especially, Samsung’s one is known as problematic.
- “Soft-buttons”, so called “power button savers” – like ScreenOff & Lock and such. Related to previous group. Let the hardware do the job.
- Task killers - If it kills some services in the middle of their action, it will cause’em start all over again or even stuck, and eat your precious battery resources. If you have to use it (like in case with JB 4.1 memory leak issue, do it manually).
- Your sound settings – screen vibro & sounds on tap, haptic feedback – disable it.
- Media Scan – process, that will run after each fresh install & reboot. Typically takes about 10-15 minutes, runs on high CPU frequency. If stuck more than this, causes no Deep Sleep (can be seen in CPU Spy app) – you have an issue with Media Scan. It can stuck on large files directory – nothing to do here, unless you can reduce files number. Another case – problematic memory cluster, and there is only solution to back your data, format your storages, and start over.
- Startup - Check it – do you really need this entire long startup list? Throw some; it will only make the system act better.
- Accounts sync – again: Minimize your list. Drill down every account setting, Google especially: Picasa, Google Disc, G+, etc.
- App settings – always drill down your app settings – it may be some nasty hidden setting, that enables your app to be in constant action. No concrete advise, treat each app individually.
TIPS:
- Always perform clean install! Backup your stuff – App2zip (free on market) app, Titanium, whatever – spend some time for formats and setting up your settings, you will only have profit on this.
- Don’t judge your battery consumption right after new rom/kernel install. Especially in the first hour, while Media Scan is busy with scanning your storage. System needs some time to settle.
- It is highly suggested, after you installed all apps and made your configurations, to reboot recovery and clean your cache & dalvick.
- If you’re installing custom kernel and any .zip flashable files, don’t do it in the same time with rom flashing. Flash the rom, reboot system, let it settle, then reboot recovery again, flash your kernel/mods, let it settle again.
- WI-FI sleep policy: leave it on “Always”. Note’s wi-fi chip consumes nearly zero energy, and it would be much healthier to leave it on.
- WI-FI home network: if you’re on dynamic IP, set to maximum your DHCP lease time in router setting, and bind your device to the MAC address. Also, fix your WI-FI channel and frequency both on device and router.
- *Don’t mess with Fast Dormancy app, if you don’t have dormancy related wakelocks, or if you don’t know your cell operator dormancy setting! And, on JB 4.1 it’s sometimes more preferable to leave it on, than to deal with some weird wakelocks, that may appear. Another case – if your operator setting for dormancy is “off”, app won’t discover it, and, actually, you may enable it instead of disabling it.
Wakelocks - XDA Wiki - take a look at it, may be very useful.
AlarmManager
Author(s): sven, credits to andy2na @xda-dev
Ranking: n/a
Speaking Name: Alarm Manager
Rationale: AlarmManager provides access to the system alarm services. These allow you to schedule an application to be run at some point in the future. When an alarm goes off, the Intent that had been registered for it is broadcast by the system, automatically starting the target application if it is not already running. Registered alarms are retained while the device is asleep (and can optionally wake the device up if they go off during that time), but will be cleared if it is turned off and rebooted. The Alarm Manager holds a CPU wake lock as long as the alarm receiver's onReceive() method is executing. This guarantees that the phone will not sleep until you have finished handling the broadcast. Once onReceive() returns, the Alarm Manager releases this wake lock. This means that the phone will in some cases sleep as soon as your onReceive() method completes.
Know actions: AlarmManager itself is not generating partial wakelocks but the applications (intents) that were set to be called when an alarm goes off do. Alarms can be listed through the menu "Actions - Alarms".
Here is a comprehensive guide to analyse Alarms: In order to find those Intents run the command dumpsys alarm.
This will dump all the alarm events so you can see what is invoking AlarmManager as a wakelock. From there you can find the culprits that have a lot of wakeups. In some instances, you cant do anything about it (Android System), but in others, you can uninstall or disable notifications. Hope this helps in solving your excessive AlarmManager problems.
Scroll to the " Alarm Stats" near the bottom, it should look like this:
com.levelup.beautifulwidgets
246776ms running, 10 wakeups
10 alarms: act=com.levelup.beautifulwidgets.ACTION_UPDATEWEATHER flg=0x4
1583 alarms: act=com.levelup.beautifulwidgets.ACTION_UPDATECLOCK flg=0x4
com.motorola.blur.datamanager.app
22ms running, 0 wakeups
1 alarms: act=com.motorola.blur.datamanager.app.checkin.timeout flg=0x4 cmp=com.motorola.blur.datamanager.app/.DataManagerCheckinService
ccc71.bmw
130743ms running, 1585 wakeups
1585 alarms: flg=0x4
com.motorola.kpilogger
2156ms running, 0 wakeups
13 alarms: act=com.motorola.kpilogger.START_LOG flg=0x4
com.gau.go.launcherex
528ms running, 10 wakeups
6 alarms: act=com.jiubang.intent.action.AUTO_CHECK_UPDATE flg=0x4
4 alarms: act=com.jiubang.intent.action.SCAN_APPS flg=0x4
As you can see, in my case, the services that have invoked AlarmManager seem to be BeautifulWidgets (to update the clock everytime the minute changes - 1583 alarms: act=com.levelup.beautifulwidgets.ACTION_UPDATECLOC K flg=0x4)
Battery Monitor Widget (obviously to pull the mW of the battery) - 130743ms running, 1585 wakeups
You could also reduce the amount of AlarmManager events by simply turning off Wireless location, Signing out of Google Talk, and turning off notifications or updates in apps you dont really use.
TLDR: AlarmManager is a universal process that MANY apps use to update time, push you notifications, etc. In most cases, it is a necessity; in other cases, you should really check it out and disable/uninstall things that have invoked it too much.
Known conditions of occurence:
Related wakelocks:
References:
http://forum.xda-developers.com/showpost.php?p=17207454&postcount=861
http://developer.android.com/reference/android/app/AlarmManager.html
AudioOut_1
Author(s): xda
Ranking: n/a
Speaking Name: AudioOut_1
Rationale: AudioOut is used to play notification and system sounds.
Know actions: From the home screen... Menu -> Sounds -> uncheck "Touch Sounds", uncheck "Screen lock Sounds"
Known conditions of occurence: Each time the screen is touched or locked.
AudioOut_3
User's experience
ConnectivityService
Author(s): sven
Ranking: n/a
Speaking Name: ConnectivityService
Rationale: Service responsible for tracking data connection / apn, establish and maintain connections. This wakelock is held during transition between data connections.
Know actions: May be conditioned by using a different radio/modem or bad coverage, may be reduced by forcing 2G.
Known conditions of occurence:
Related wakelocks:
References:http://grepcode.com/file/repository.../ConnectivityService.java#ConnectivityService
deleted_wake_locks
Author(s): sven, credits to Tritonio_GR @xda-dev
Ranking: n/a
Speaking Name: deleted_wake_locks
Rationale: In the API available to android drivers it is advised to call wake_lock_destroy before freeing the memory of the wakelock struct that they created. This is done above all on shutdown, but also in a few situations where a driver is unloaded dynamically from the kernel. Whenever it happens, the destroyed wakelocks disappear from the list but their stats are added up to this pseudo-wakelock to the deleted_wake_locks. This allows knowing that a set of old wakelocks had a combined set of stats that this entry shows. The stats of this entry do not increase unless additional real wakelocks that have non-zero stats are destroyed.
Know actions: Since this is merely an entry that combines the activity of all the kernel wake locks that no longer exist, there's nothing that can be directly done to reduce this entry. The best course of action is to identify the wake locks that generate activity and that are later deleted, before that happens and they end up showing in a combined way on this entry.
Known conditions of occurence:
The Wifi driver is one known source for kernel wakelocks that are destroyed whenever the driver is unloaded (when Wifi is disabled manually or as part of the turn-off policy). Wakelocks such as wlan_rx_wake and wlan_wake, when the driver is unloaded, will no longer show up in the list and their stats be added to the deleted_wake_lock previous values.
Related wakelocks:
References: http://forum.xda-developers.com/showpost.php?p=27227201&postcount=5644 http://forum.xda-developers.com/showpost.php?p=28915936&postcount=6671 http://www.netmite.com/android/mydr...k.chttp://elinux.org/Android_Power_Management
GTALK_ASYNC_CONN_com.google.android.gsf.gtalkservice.AndroidEndpoint
Author(s): credits to lmihaila @xda-dev
Ranking: n/a
Speaking Name: AndroidEndpoint
Rationale: This wakelock has been found to occur under certain non reproducible conditions, showing high wakelock counts and in certain cases high wake times. As the reasons are not exactly known there is no garanty that this wakelock does not occur for other yet unknown reasons.
Know actions: In one case (see ref) this wakelock was successfully removed by changing the proxy / re-creating an APN definition and leaving the proxy blank for that APN. The "faulty" proxy was predefined for the provider Orange but it is not excluded that proxies from other providers show the same effect.
Known conditions of occurence:
Conditions are unclear, to be confirmed
Related wakelocks: Other GTALK_ASYNC_CONN partial wakelocks
References: http://forum.xda-developers.com/showpost.php?p=22786143&postcount=3416
network-location
Author(s): sven
Ranking: n/a
Speaking Name: Network Location
Rationale: The network location service is responsible for providing coarse grained location information to requesting applications.
The frequency of updates (and of wakelocks) is related to the precision requested by the application (max. time between updates, precision in meters).
Examples of app requesting coarse grained location: weather widgets, latitude, most social tools, google+
Know actions: Actions to reduce wakelocks:
• Find the responsible app: look for all network-location wakelocks and check for the responsible apps on the second line of the list
• Check the settings of the app to see if the precision can be changed
• Use the benefits of Wifi based location (stable location minimizing the update frequencies)
• Look for alternative apps with a better design
Known conditions of occurence: Poorly designed apps with too high requirements on precision will drive the Network Location Service up.
Unstable network conditions (frequent handovers between towers) may trigger location updates.
In some cases updating the radio/modem has effect on the network location: the location is based on the tower information delivered by the RIL.
Related wakelocks: LocationManagerService, NetworkLocationLocator, WifiService, GpsLocationProvider, network-location-cell-update
References:
http://developer.android.com/guide/topics/location/obtaining-user-location.html
http://developer.android.com/reference/android/location/LocationManager.html
PowerManagerService
Author(s): sven, credits to Entropy512 @xda-dev
Ranking: n/a
Speaking Name: PowerManagerService
Rationale: This kernel wakelock is a placeholder for all partial wakelocks being held in userland.
Know actions: Use "Partial Wakelocks" to drill down the applications / services causing wakelocks.
Known conditions of occurence:
Some devices show userland wakelocks as a total named PowerManagerService
suspend_backoff
Author(s): sven, credits to Tungstwenty @xda-dev
Ranking: n/a
Speaking Name: suspend_backoff
Rationale: suspend_backoff is triggered whenever there's a rapid succession of sleep-wakeup-sleep transitions in a short period of time (10 occurrences within x ms IIRC). When that happens, SB makes sure the device is continuously awake for a bit instead of alternating a lot. The KWL count indicator could give a hint about the source of those continuous wakes, but not a definite answer because it doesn't show their time distribution.
Know actions:
Known conditions of occurence:
In relation with Chrome: http://forum.xda-developers.com/showpost.php?p=28676218&postcount=24 In relation with Wifi turning on/off when the screen goes on/off
Related wakelocks:
References:
http://forum.xda-developers.com/showpost.php?p=28836538&postcount=6603
svnet
Author(s): sven, credits to Entropy512 @xda-dev
Ranking: n/a
Speaking Name: svnet
Rationale: basic radio management (Galaxy S/S II specific)
Know actions: No direct actions known, may be conditioned by using a different radio/modem
svnet dormancy
Author(s): sven, credits to Entropy512 @xda-dev
Ranking: n/a
Speaking Name: svnet-dormancy / multipdp (those are synonyms, depending on android version)
Rationale: svnet-dormancy is a kernel wakelock related to cell data transfers - Fast dormancy or not, you get a 6 second wakelock any time the radio transfers data
Know actions: Change the duration of the wakelock (use at your own risk). Reduce the wakelock by reducing the amount / number of data traffic requests
Known conditions of occurence:
Caused by data traffic
Sync
Author(s): sven
Ranking: n/a
Speaking Name: Account Sync Service
Rationale: The sync service is responsible for syncing all the accounts from "Settings" - "accounts and sync". A wakelock is held while the sync process is running.
The more items are getting synced and the more often the sync occurs the higher the wakelock time will be.
Potentially the wakelock time is prone to raise in case of bad data connectivity.
Examples of accounts are: twitter, google+, linkedin, google mail
Know actions: Actions to reduce wakelocks:
• Remove any unwanted accounts
• Check the settings and remove any unwated options (contact sync)
• Check the frequency of the sync and see if you really need it as defined
Known conditions of occurence: Under bad data connectivity conditions, with poorly designed Sync providers
Related wakelocks: none
References: A known bug related to gmail: http://code.google.com/p/android/issues/detail?id=9307
SyncLoopWakeLock
Author(s): sven
Ranking: n/a
Speaking Name: SyncLoopWakeLock (Account Sync)
Rationale: SyncLoopWakeLock is the wakelock used by the Android SyncManager (android.content.SyncManager) and was introduced starting in 4.01. The sync service is responsible for syncing all the accounts from "Settings" - "accounts and sync". A wakelock is held while the sync process is running.
The more items are getting synced and the more often the sync occurs the higher the wakelock time will be.
Potentially the wakelock time is prone to raise in case of bad data connectivity.
Examples of accounts are: twitter, google+, linkedin, google mail
Know actions: Actions to reduce wakelocks:
• Remove any unwanted accounts
• Check the settings and remove any unwated options (contact sync)
• Check the frequency of the sync and see if you really need it as defined
Known conditions of occurence: This wakelock is held by the SyncManager while handling sync actions (method handle()). Previously this wakelock was known as sync. Under bad data connectivity conditions, with poorly designed Sync providers this wakelock is held longer.
Related wakelocks: sync
References: https://github.com/asksven/BetterBatteryStats-Knowledge-Base/wiki/sync
Sources: New implementation:http://grepcode.com/file/repository...droid/content/SyncManager.java#SyncManagerOld implementation (sync):http://grepcode.com/file/repository.../SyncManager.java#SyncManager.0SYNC_WAKE_LOCK
vbus_present
Author(s): sven, credits to Entropy512 @xda-dev
Ranking: n/a
Speaking Name: vbus_present
Rationale: vbus_present is a kernel wakelock that is held when the charger is connected.
Know actions: No action required.
Known conditions of occurence:
When plugged in to charger / charging USB port
wlan_rx
Author(s): sven, credits to Entropy512 @xda-dev
Ranking: n/a
Speaking Name: wlan_rx
Rationale: Wifi chip received a packet from somewhere - On a Galaxy S II, lots of these combined with the fact that the device takes 650 msec to resume from suspend and 150 to go back to sleep means that occasional wifi packets coming in will skyrocket Android OS usage. As an extreme example, run the following from a Linux box when wifi sleep policy is "never" and watch your deep sleep percentages plummet, your battery drain, and Android OS skyrocket: ping -i 5 <wifi IP address of phone>
Know actions: Use a sniffer to determine the cause of the traffic.
Known conditions of occurence:
Related wakelocks: wlan_wake References:
wlan_wake
Author(s): sven, credits to Entropy512 @xda-dev
Ranking: n/a
Speaking Name: wlan_wake
Rationale: wifi chip woke the CPU (Usually this fires and leads to a wlan_rx wakelock).
Know actions: Use a sniffer to determine the cause of the traffic.
Known conditions of occurence:
Related wakelocks: wlan_rx References:
***NEW***L2_HSIC:
HISC is the interface that connected the main Soc processor ( Also called Applciation Processor AP) to the modem ( 3G or 4G if there are two modems separately )
HSIC is uses the standard USB core library. And it is standard given by usb.org. The HSIC by itself consumes very less power and is one of the very power efficient and space efficient ways of interconnecting chips. Currently common to Qualcomm and Sammy Exynos architectures.
The reason seeing too many HSIC wake lock and other wake ups is due to the fact that the HSIC interface is waken up by modem (resulting modem scenarios are also so many) .
Also one important reason is EFS sync.
A concept : that the new modem architectures doesn't support a flash storage.(Saves lot of cost to manufacturer) .So every time modem needs to store something , it wakes up hisc interface and ask the AP (Main processor) to store it for him in his flash.
So this CP storing via AP is a fairy frequent activity even during suspend/deep sleep mode. Remember modem is periodically awake to do "Cell Update message" all the time.
I see the concern over this L2_hsic wake lock. I can say at this point that it is quite natural activity. and a necessary evil for smooth working of your modem( network 2g,3g,4g ) subsystem.
Every company including Sammy have some kind of power optimization done in the HSIC. So they taking care of this we considering fairy high battery drainer issue. .
If it is too high, modem/network can be blamed , if too many frequent network ( too many cell re-selection activity due to low RF reception) changes force the modem to do more activity, thus waking AP to do the work of storing its data over HSIC.
Remember: there is no app, that behaves in same way on different system. While it can drain on CM, it can be rock solid on the TW, and vice-versa. So, don't take those examples too serious and don't run to uninstall your apps just for preventive maintenance. Act per need.
So, as listed above, our Top Chart leader is Media Scan:
- Media Scan – process, that will run after each fresh install & reboot. Typically takes about 10-15 minutes, runs on high CPU frequency. If stuck more than this, causes no Deep Sleep (can be seen in CPU Spy app) – you have an issue with Media Scan. It can stuck on large files directory – nothing to do here, unless you can reduce files number. Another case – problematic memory cluster, and there is only solution to back up your data, format your storages, and start over.
Stopping the process won't help much, as on next reboot it will resume. Suggestion - charge the battery to 100% before Media Scan starts to rebel, and let it finish.
Another case - stopping any download (browser, market) in the middle. Media scan can possibly stuck until next reboot.
- Media Scan stuck:
1. You probably have some corrupted files, on which it stuck. Backup, start to restore to the step it was OK, to find the culprit
2. Folder with many files - likely to stuck or to spend a lots of time to scan it. Do the math. If you have to have this folder (likely to be a cache folder) - disable your media scan.
3. I/O scheduler - CFQ sometimes being reported as taking longer time to media scan to complete. Try NOOP.
4.And, of course, sometimes it won't work without formatting emmc and starting over.
- Google apps/services:
(in edit)
- Google Plus - there were cases, when this app, with auto-sync left, was just hanging in the memory and caused drain.
- Google Currents - depends on system, but there were also cases, when the service left active on CPU resource after it was even completely killed in task manager.
- Google Location service - if you choose to update your location by GPS only, expect wakelock, when GPS can't lock on a stellite. Second case - if location being updated from internet, and your mobile data is in bad state (poor signal, etc.). And, of course, it depends on apps, who require location update, and there are a lot of such. Whenever you don't need it - disable your locations service in Settings.
- Google Maps - brightest example of wakelock, caused by requiring your location. If you want to run Google Maps, disable the Location services, and disable Maps in start-up.
- "The Holy Trinity" - Skype, Facebook, WhatsApp. Just be sure to kill the app and & services, when you don't need it.
- Same applies for a clients of a kind: Viber, Twitter, etc.
- “Energy savers” – Green Power, Timeriffic, etc. They mess with the system power policy, if you choose to enable/disable wi-fi, gps, data, Bluetooth, etc. Especially, Samsung’s one (power policy) is known as problematic.
- “Soft-buttons”, so called “power button savers” – like ScreenOff & Lock and such. Related to previous group. Let the hardware do the job.
- Task killers - If it kills some services in the middle of their action, it will cause’em start all over again or even stuck, and eat your precious battery resources. If you have to use it (like in case with JB 4.1 memory leak issue, do it manually).
-Sopcast - very likely to stuck in memory, and to cause multi_pdp wakelock. Worse, it may keep consuming your precious data. Suggestion: reboot right after you ended using Sopcast.
- *new* - Weak network signal. Pretty understable, but still - weak network signal can cause some weird wakelocks. Especially, when you're on autosync on with mobile data, and the signal is weak, you will get "*sync*com.google.android.apps...." wakleock, "genie.widget" is you're syncing "new&weather" thing, RILJ is very likely, etc.
...
Amazing!! will save lot of threads/questions about battery drain.
It will be great if you can look at frequent questions about battery drain in Q&A and can include in Q&A of your thread.
Thanks, hopefully we'll build our database on the current and upcoming requests.
This should be a sticky.
Sent from my gnote as always Rooted & Deodexed Stock 4.0.4 XXLRQ HydraCore v4 STD
Well and comprehensively written, ahalford. Now let's wait for the first customers.
Well, I actually expected you to sleep, sir
Thanks, and I'm continuing with edit. Like I said, many things to be added later, as it always happens.
So, we started to collect our suspicious apps in post #4.
Please, don't hesitate to share your knowledge regarding such mVsuckers.
Thanx for your efforts mate...great work! :good:
Mike
This guide should be stickied
Sent from my GT-N7000 using xda app-developers app
Very Nice Guide. Thanks.
Sent from my GT-N7000 using Tapatalk 2
No one with problems? First client?...
:silly:
i don't know if my problem related or not... but here it is
as far i remember.... since the first time i installed official note ICS i'm facing a massive battery drain when wifi is on
i tried a lot of ROMs (Asylum at least two versions, Rocket three versions, Alliance , Liquidsmooth & black, CM9 official & Anidroid, PA & more)
its like draining 4-5% per hour without using, for example today i left the phone after one hour of use on 71% battery at 3 PM... now it's 7:17 PM and it's on 53% of battery.. thats 18% in 4 hours with maximum 10 minutes screen on
i'm running RR v11... before i tried to set wifi sleep policy to never(with other ROM) & the drain was gone with it
any suggestions on the files i need to upload if you could help..??
smarda7a said:
any suggestions on the files i need to upload if you could help..??
Click to expand...
Click to collapse
Start with dump file - it is exactly described in the OP (1st post) - How to provide a dump file.
Before this - look at posts #2 & #4 and try to apply the possible.
smarda7a said:
i don't know if my problem related or not... but here it is
as far i remember.... since the first time i installed official note ICS i'm facing a massive battery drain when wifi is on
i tried a lot of ROMs (Asylum at least two versions, Rocket three versions, Alliance , Liquidsmooth & black, CM9 official & Anidroid, PA & more)
its like draining 4-5% per hour without using, for example today i left the phone after one hour of use on 71% battery at 3 PM... now it's 7:17 PM and it's on 53% of battery.. thats 18% in 4 hours with maximum 10 minutes screen on
i'm running RR v11... before i tried to set wifi sleep policy to never(with other ROM) & the drain was gone with it
any suggestions on the files i need to upload if you could help..??
Click to expand...
Click to collapse
1. Install BetterBatteryStats if you don't have it already
2. Charge your Note, set 'Custom Reference Point' in BBS
3. Don't change your normal setup, but don't touch your phone for at least 4-5 hours (overnight perhaps)
4. After that start BBS, hit menu and choose 'dump to file'
5. Locate the dump file in root folder of one of your SD cards
6. Come back here and attach the dump file to your post
7. You'll get help
No deep sleep at all on PA and CM10
Thank you in advance for your time and attention!
After official ICS ROM (no probleme at all) I flashed HydraCore kernel and paranoidandroid from Utacka and here is my problem: my SGN is not use Deep Sleep - it is unused CPU state according to CPU Spy (see screenshot). Was trying to change kernel to official CM, was trying to flash CM10 ROM - no chance to make my Note go to deep sleep.
Here is the dump of BBS stats.
Thabk you in advance for any help!
200mpx said:
Thank you in advance for your time and attention!
After official ICS ROM (no probleme at all) I flashed HydraCore kernel and paranoidandroid from Utacka and here is my problem: my SGN is not use Deep Sleep - it is unused CPU state according to CPU Spy (see screenshot). Was trying to change kernel to official CM, was trying to flash CM10 ROM - no chance to make my Note go to deep sleep.
Here is the dump of BBS stats.
Thabk you in advance for any help!
Click to expand...
Click to collapse
Thanks for your submission:
Try the following steps:
1.Disable network location service in Settings - both by gps and by network
2. Disable all of screen sound & haptic feedback
3.Uninstall Aqua mail
4.Enter flight mode
5.Reboot to recovery, wipe cache & dalvick
6. Boot back to normal, exit flight mode, leave the phone for an hour.
И подчистите автозагрузку слегка...
Report back for the further escalation.
Android 4.4.3 KitKat may well be just days away from making an appearance on the Nexus 5 and Nexus 7.
Source
here is the list of Android 4.4.3 fixes:
1. The fixes to camera include mm-qcamera-daemon crash and camera focus in regular and HDR modes.
2. Power Manager wakelock fix.
3. Multiple Bluetooth fixes and FCC compliance fix.
4. Fix for the random reboot and the reportedly elusive 'app shortcuts' from the launcher after update.
5. Wi-Fi auto connect problem and USB debugging security fix.
6. A fix to address the issues faced by users who are stuck in the activation screen.
7. Data connection dropout problem fix.
8. Missed call LED problem fix and subtitle fix.
9. Data usage graph and Internet telephony fix.
10. There are several undefined fixes to MMS, Email/Exchange, Calendar, Contacts, DSP, IPv6, VPN and the others.
Hi,
Already posted: First Android 4.4.3 Details...
mods should close
I am developing a new Pebble watch app to display which street food trucks are currently open for business and its current location for a given city.I will be using an API that currently collects this information for food trucks in 9 different cities.
I backed the Pebble kickstarter project and I have since written several watch apps, mostly in the transportation area, including one for various bus systems and the BART train. I wrote the apps for myself, but they have also been proven to be useful to thousands of other users.
I also wrote several watch face style apps that aggregated open sourced watch face apps, which enables users to have over 40 ACTIVE watch faces (not in the locker) that will only use up 3 of the 8 watch face slots.
Outside of Pebble, I have been working full time as a senior software engineer for many years and I am very into starting with a well-thought-out design and using the agile process and test first. Anyone monitoring my checkins will see how I will build and unit test each portion of the app. I've had several weeks to work out the design, so I'm ready to start the coding for tomorrow's official start.
Update: The API now supports 14 cities. I have enabled only the 13 cities that actually have trucks signed up for the service that are reporting their schedules. This is more than the 9 cities originally promised by my pitch.
iOS users can download the latest pbw from the downloads section of this project. See my reply below for instructions. Android users can download the latest app from the Pebble App Store.
source code link: http://github.com/mikebikemusic/FoodTrucks
XDA:DevDB Information
Food Trucks, ROM for the Pebble
Contributors
pebblemike
Version Information
Status: Stable
Current Stable Version: 1.0
Stable Release Date: 2014-09-03
Current Beta Version: 0.3
Beta Release Date: 2014-08-21
Created 2014-08-14
Last Updated 2014-09-04
What cities are you supporting? I just moved to Austin and could use a method for navigating the 10,000,000 trucks here.
mcongrove said:
What cities are you supporting? I just moved to Austin and could use a method for navigating the 10,000,000 trucks here.
Click to expand...
Click to collapse
Unfortunately, the API I will use does not yet support Austin or for that matter, the SF Bay Area where I live. The cities in the current API are Boston and Tallahassee in the US and Vancouver, Victoria, Ottawa, Edmonton, Halifax, Calgary and Toronto in Canada.
Like you, the first thing I asked the API developer when I contacted him was when he would cover Oakland. He is very interested in expanding. In fact, 3 of the cities on the above list are new. He said it takes some time to contact and get the truck drivers to buy into reporting their schedules into his app, but it's very easy, so once they start doing it, the information returned by the API is quite good. Better than the other APIs I considered.
Mike
UI Design
It's 10:01 Fri Aug 16 on my pebble as I start writing this...
Documenting and sorting out my mental design of the Food Trucks app UI. A lot of it is based on providing a similar UI to what I used for my BART app.
UI: On Pebble screen, 3 views:
1. Startup text to alert user if Pebble app is not responding, which, if responding gets replaced with
2. Menu of Food truck names and their locations, truncated, and when one is selected,
3. Scrolling text. Full details of the selected truck, including full name, location, ending time and other details such as phone #, type of food, etc.
Configuration screen: Shows list of supported cities. User picks one. Choice is remembered across Pebble runs and reboots.
Task Breakdown
Prototyping phase:
API example output is captured and JSON is analyzed. Use jsbin to write the necessary loops to iterate across trucks.
Filter out the unwanted data and extract the data needed for the menu and the details.
Decide on the format of the JSON to be sent to the Pebble watch.
Decide on the message sequencing between the watch and the javascript.
Code and debug the text layer in the main window to be used during startup.
Code the App Message interface in C. Use the text layer as a debugging screen.
Code the javascript so it sends mock menu data for a sunny day use case in the filtered format expected to be sent when the real data is connected.
Debug the C to Javascript interface.
Evaluate reliability and check for memory leaks.
Code the menu layer into the main window and display the received data in the menu.
Code the Scrolling Text Layer as a separate window pushed onto the main window.
Code the Javascript mock data for the details format.
Debug the interface and check for memory leaks.
Integration coding and testing:
Using Javascript prototype code from task 1 above, write the API call, analyze the incoming JSON and transform it to the expected data for the tested interface.
Debug using live data.
Write the configuration html and javascript.
Mock up edge and exception data cases and fix bugs.
Design icon and marketing materials.
If time permits, replace static arrays with malloc/free data.
Check and fix any memory leaks.
Release first version.
pebblemike said:
Prototyping phase:
API example output is captured and JSON is analyzed. Use jsbin to write the necessary loops to iterate across trucks.
Filter out the unwanted data and extract the data needed for the menu and the details.
Decide on the format of the JSON to be sent to the Pebble watch.
Decide on the message sequencing between the watch and the javascript.
Code and debug the text layer in the main window to be used during startup.
Code the App Message interface in C. Use the text layer as a debugging screen.
Code the javascript so it sends mock menu data for a sunny day use case in the filtered format expected to be sent when the real data is connected.
Debug the C to Javascript interface.
Evaluate reliability and check for memory leaks.
Code the menu layer into the main window and display the received data in the menu.
Code the Scrolling Text Layer as a separate window pushed onto the main window.
Code the Javascript mock data for the details format.
Debug the interface and check for memory leaks.
Integration coding and testing:
Using Javascript prototype code from task 1 above, write the API call, analyze the incoming JSON and transform it to the expected data for the tested interface.
Debug using live data.
Write the configuration html and javascript.
Mock up edge and exception data cases and fix bugs.
Design icon and marketing materials.
If time permits, replace static arrays with malloc/free data.
Check and fix any memory leaks.
Release first version.
Click to expand...
Click to collapse
In an ideal world, I would do the development in more or less the above order. But, as pointed out in the email sent to the 20 finalists there are early deadlines. I want to make this app available to all Pebble owners. This project won't need a companion app for Android or iOS, so I don't have to worry about Whitelisting. However, I will need to bundle the JS with a working API call by the end of next week. To that end, my goal is to start working on integration coding tasks 1, 2, 3, and 5 by Thursday, so I can post a beta on Friday.
This prompted me to consider what else I can accelerate. I decided to give the new CloudPebble Graphical UI Editor a try and see if it will build what I planned to do for prototyping tasks 5, 10 and 11. I may end up writing two applications. one that I can rapidly write and test code with, and the other where I assemble the tested code into the UI.
Update: I tried CloudPebble Graphical UI Editor, but it does not yet allow me to make either a SimpleMenuLayer or a ScrollLayer. It will be easier for me to build this myself.
bundle early, bundle often
FWIW - as I understand it, you don't need the javascript finalized (though that's certainly very good) - but you do need to have *a* bundled version of your javascript in place before they collect. It seems silly, but I've just published a barebones version of my app w/ javascript enabled that warns, specifically, that it's only published for javascript bundling. (Then again, the whole javascript pre-approval process in the walled garden that is IOS is pretty silly, IMO)
I don't think you technically need to make it public, you just need a published/ready version, but I went ahead and did so because I'm a paranoid type, and my free time is too limited to chance it. Once any version of your javascript has been published, I gather the updates in the future are made available on the order of minutes not weeks.
cynorg said:
FWIW - as I understand it, you don't need the javascript finalized (though that's certainly very good) - but you do need to have *a* bundled version of your javascript in place before they collect. It seems silly, but I've just published a barebones version of my app w/ javascript enabled that warns, specifically, that it's only published for javascript bundling. (Then again, the whole javascript pre-approval process in the walled garden that is IOS is pretty silly, IMO)
I don't think you technically need to make it public, you just need a published/ready version, but I went ahead and did so because I'm a paranoid type, and my free time is too limited to chance it. Once any version of your javascript has been published, I gather the updates in the future are made available on the order of minutes not weeks.
Click to expand...
Click to collapse
That's good to know, John,
Since the first 3 tasks of my prototype will get me to usable JS code for my integrated app, I'm not too concerned, even if it gets bundled and distributed.
But I thought that published/ready meant that Android uses would be able to download it immediately. I wouldn't want to publish anything that didn't work.
Mike
UPDATE:
Hey, everybody. Cherie just posted: "Submit your JS changes before 8/19/2014 11:59AM PST"
Progress Updates
Aug 15 2pm - Prototype task 5 is done. Github repository created. Stub checked in.
Aug 15 2:20pm - Prototype task 1 is done. jsonanalysis.js checked in.
Aug 15 3:00pm - Prototype task 2 is done. jsonanalysis.js updated.
Aug 15 4:00pm - Prototype task 3 is done. jsonanalysis.js updated.
Aug 15 7:00pm - Prototype task 4 is done. 3 unit tests passed. main.c updated.
That's it for today.
Aug 16 8:00am - Added assertions to debug and exercise app message sequencing, refactored unit tests. main.c checked in. Unit test output:
I realized that task 6 depends on task 7 so, I'm starting 7 first.
Aug 16 8:30am - Prototype task 7 is done.
Aug 16 10:30am - Prototype task 8 is coded, but has timing issue
Aug 16 4:00pm - Prototype task 9 is done. I decided that the memory leak "Still allocated <42949" is bogus because the only allocations were 1 window and 1 text layer and both got deallocated. (removing either destroy results in a reasonable 2 digit number leak). I then implemented and am satisfied with Prototype task 10 being done.
Aug 17 8:30am - Did task 12 before task 11. Both needed to work at the same time anyway. Code checked in.
I am declaring the Prototype phase complete and moving on to integration. Will change my status from Testing to Alpha.
Aug 17 9:30am - Integration tasks 1 and 2 went smoothly. Real data looks like I expected.
Aug 17 noon - Integration task 3 is working, but I have to go off to play music with friends. Will try to put together what I need to publish a beta on the Pebble App Store either tonight or tomorrow.
Aug 17 10:40pm - Put together enough of integration task 5 that I could publish the app as a beta. Because of the all the unit testing, there should not be too many bugs. However, I will continue to build a lot of edge tests, add one more icon that shows up on the watch, and fix any bugs I find through my additional tests or get reported. Your comments, suggestions and bug reports are welcome. I also need to update my website.
Aug 19 9:30am - Found and fixed several bugs. Published a more stable 0.2 beta. See release notes.
Aug 19 10:00pm - Started coding integration task 4. What I'm doing for that is expanding on the function testRequestSceduleFor(city) in the javascript. Since I don't want to ship all this test code with the app, I created a test branch where I will put the additional code. Fixes will merged into master. I'll be testing handling of very long string sizes and very large number of trucks. I already know the C program will fail because I'll be sending more data than the fixed sizes I put in. Since I have time, I will convert to malloc/free to fix these failures.
Aug 21 7:30am - Completed all tasks except for releasing a 1.0 version and updating my website. API now has Checked source code of 0.3 into github. I consider this a release candidate.
Aug 22 7:00am - Website is now updated with this app. Banner for the app store was updated to 10 cities. Here are screen shots of the food truck icon on the pebble, the startup screen and the no food trucks are open yet message.
Aug 27 7:00am - Updated configuration from 10 cities to 13 cities. More will be added as truck data becomes live.
Sept 3 9:30pm - Bumped version number to 1.0 after giving a number of iOS users a chance to download and use the app. Finalized the marketing materials to match the number of cities supported.
AppMessage timing issue
I've just implemented the AppMessage code for my app which requires a rapid sequence of requests and responses that is always kicked off from the javascript side. It's working fine when all my logging is in place, so I disabled the log messages and now it gets stuck after the first round-trip message. The message sequencing for the test is as follows:
JS: send count of 30 to C
C: request item 0 to JS
JS: returns item 0 to C
C: request item 1, then both sides go idle. JS does not get the message.
I found that if I add a psleep(100) before each request in the C code, it will get farther, but will eventually stop at a different item number, for example:
Not sure why yet. The send / receive code in the C program is a slight variant of the todo list demo app in the 2.0 sdk, also similar to what's in the weather and quotes apps in the 2.2 sdk.
Code as it stands is checked into github.com/mikebikemusic/FoodTrucks
I'll probably figure it out while out doing errands today.
====================================================
Update: Searching through the pebble forums, I found a few others who had similar problems. One of whom said his solution was in the todo list demo app, without explaining what his fix was, which didn't help me much. There was mention in several places about waiting for an ACK, but never an example. I updated my SDK to 2.4.1, but the demo apps all looked pretty much like mine. So, I re-read the app_message API looking for a way to set a callback for an ACK and noticed that app_message_outbox_begin can return,APP_MSG_BUSY. I then coded a retry/timeout using psleep, and lo and behold, the code is now working. Looking back at the 3 SDK samples they will all do the same dumb thing: throw away the request if it can't be sent immediately.
A little experimentation and measurement and I found that sometimes the wait between outgoing messages to the JS can be up to 1 second. I coded up a stress test that ran for a number of minutes and kept running even through an incoming phone call conversation. I caught this screenshot right before stopping it (over 20,000 round trips without stopping):
Bogus memory leak report
I started to see the following during testing of starting and stopping my app:
[PHONE] pebble-app.js:?: JS: starting app: 19177E4B-72D9-4B0C-B9D3-497C77488971 Food Trucks
[PHONE] pebble-app.js:?: app is ready: 1
[INFO] ocess_manager.c:291: Heap Usage for App <Food Truck: Total Size <13348B> Used <5692B> Still allocated <0B>
[PHONE] pebble-app.js:?: JS: stopping app: 19177E4B-72D9-4B0C-B9D3-497C77488971 Food Trucks
[PHONE] pebble-app.js:?: JS: starting app: 19177E4B-72D9-4B0C-B9D3-497C77488971 Food Trucks
[PHONE] pebble-app.js:?: app is ready: 1
[INFO] ocess_manager.c:291: Heap Usage for App <Food Truck: Total Size <13348B> Used <5248B> Still allocated <42949
[PHONE] pebble-app.js:?: JS: stopping app: 19177E4B-72D9-4B0C-B9D3-497C77488971 Food Trucks
[PHONE] pebble-app.js:?: JS: starting app: 19177E4B-72D9-4B0C-B9D3-497C77488971 Food Trucks
[PHONE] pebble-app.js:?: app is ready: 1
[INFO] ocess_manager.c:291: Heap Usage for App <Food Truck: Total Size <13348B> Used <5692B> Still allocated <0B>
[PHONE] pebble-app.js:?: JS: stopping app: 19177E4B-72D9-4B0C-B9D3-497C77488971 Food Trucks
[PHONE] pebble-app.js:?: JS: starting app: 19177E4B-72D9-4B0C-B9D3-497C77488971 Food Trucks
[PHONE] pebble-app.js:?: app is ready: 1
[INFO] ocess_manager.c:291: Heap Usage for App <Food Truck: Total Size <13348B> Used <5692B> Still allocated <0B>
[PHONE] pebble-app.js:?: JS: stopping app: 19177E4B-72D9-4B0C-B9D3-497C77488971 Food Trucks
Since only 24kb is available, 42949 makes no sense. It reports no leaks if my code also creates/destroys the scrolling window. It's almost as if I need to do a minimum amount of memory allocation before the leak detector works properly.
Release Notes
0.1 Aug 17 10 pm Published first beta to allow a working pebble-js-app.js to be bundled and to solicit user beta testing.
0.2 Aug 19 9:30 am Watch icon added. Changed startup message. Pre-build scroll window and its layers at startup. Bug fixes: Prevent multiple scroll windows when repeating select button quickly. Reset scroll to top when selecting details. Clear prior city's list when switching cities.
0.3 Aug 21 7:30 am Built javascript driven testing of C app. Used it to debug malloc/free code. The Javascript tests exercise the app with unrealistically large strings and large numbers of trucks coming from the API. In examining the API, I found that the developer added 5 new cities, so I added them also to the configuration screen. I will be doing live testing for all the cities before publishing an official 1.0 release.
Update: Aug 21 7:30 pm Of the 5 new cities I tested, only 1 had active trucks, so I removed the other 4 from the drop down. Fortunately, this is a simple server-side fix to hide the others until they are ready.
malloc/free challenge/solution
I ran into a little snag (which I eventually solved) during the conversion from using a fixed size array for the menu titles and subtitles to allocating them on the fly with malloc/free. I wanted to change the pointer directly in the menu_items.title without having to allocate a separate array of pointers. Problem was that title and subtitle are declared const, so free(menu_items.title) gets a compiler error.
I discovered that reinterpret_cast<> and const_cast<> are not supported by the compiler. Eventually I tried a simple (void *) cast, which did the trick. Then I refactored the code so that one bottleneck method took care of the free function and updating the pointer. I'm pretty proud of that code change. It's aware of the two string pointers that are not malloc'ed and provides an interface that prevents accidental leaks when my code dynamically changes the menu list.
Comments about developing using cloudpebble.com
I started writing pebble apps using cloudpebble soon after it first came out. I didn't have to install a dev system at home and I could make a quick bug fix at work, if necessary. I've since installed the development tools at home and used that primarily. I decided to give cloudpebble a second look for this competition. It's progressed a lot, but there are still some things on my wish list.
I find it a bit inconvenient when I have compile errors that I cannot see unless I open a second browser window to view source and errors side by side. A single button to flip back and forth between the compile logs and the current source code would really help.
Cloudpebble does not allow me to check in files unrelated to compilation, such as the configuration html. At one point, I tried to commit new code and I got an error (with no error message, just the word error). I figured out it was because of updates I had done to files unrelated to the compilation, but the only choice I had might have replaced all the new code I wrote with the previous commit. So I made a backup of my changes, updated the project and pasted back the changes.
Finally, as I had mentioned at the start of the challenge, the new code generation feature did not help me because I needed layers that were not supported yet. I ended up creating those layers while I was trying to track down the false memory leak report. I like doing that because now, if the app runs out of memory due to too many trucks in the menu, it won't fail to create the scroll layer for those that made it into the menu. Hmm, I need to put together a test case for that...
Feedback Anyone?
Android users can download my app from the Pebble store.
iOS users can get an advance copy here. The easiest way to load on iOS is to put the pbw file on your dropbox and, from dropbox, select the file and Open In Pebble.
Use the Reviews, Feature Requests, and Bug Reports tabs at the top of this development page. Also, search for "Food" in the Pebble store to find my app and tap the heart button on it. I see 5 already!
Adding another city
Looks like several more city's data has come online. I've added Hamilton (Near Toronto), Surrey, and Kitchener-Waterloo to the configuration. The other new city, Columbus, Ohio just has a few trucks using streetfoodapp.com. Only 2 of the 20 trucks registered with streetfoodapp.com in Columbus are promoting themselves this way.
If you live in Columbus, Surrey, or Kitchener-Waterloo that list just a few trucks, go tell your favorite food truck vendors to start publishing their schedule on streetfoodapp.com. If you live in a city not supported, click here to request your city
Feature creep vs planned development
It may seem like I've stopped working on my app now that it's feature complete and stable, but that's not entirely true. Yes, I've requested and am awaiting feedback from users, and I'm especially interested in seeing what happens when iOS users can see the app on their app store. That should happen any day now, since I met the Aug 19 deadline for JS bundling. I needed to publish another bug fix 2 days later, and one of the fixes I planned would have required a minor change to my JS. That JS fix was for an edge case that could only occur with the artifical data I supplied as a unit test that had a string size much larger than any in real data. If I updated my JS, iOS users would be delayed getting the other C code fixes. So, I chose to ship 0.3 with the original JS. It is interesting to note that when I reverted my JS manually, and published it, the dev-portal considered it a different version, so I pulled that release and reverted the JS to what I checked in to github. It turned out to be a whitespace difference. So, word of caution, the JS is compared byte by byte (or maybe a checksum).
Meanwhile, I have considered a few improvements. And I've experimented with one of them, which required further JS changes. The change will eventually go to the master branch, but rather than providing an improvement that nobody really cares or needs, I'd rather wait for feedback and act on that first, rather than announce future planned improvements. As features creep in, it's easy for the app to become more complex to use.
I'll give you one example. I'm on the west coast and when I look at the times reported for the Boston food trucks, the times are off by 3 hours. Should I fix it? Some would say, of course. But think about it. Are the real users who use this app going to be in a different time zone when they need to go out to lunch and open my app? Extremely unlikely. Both JS and the pebble watch API fall flat on their face when it comes to determining time zone differences, both dealing only with local time. I know how to compute that offset by calling another TZ API like I did for my Any Time Zone app. What I chose to do instead was contact the Food Truck API developer suggesting he provide all API users with a TZ offset in the data response. He has agreed to do so in a future API version. This is how planned development should work.
Mike
1.0 released
I posted my 1.0 build last night. It is available in both the Android and iOS Pebble App Stores for download.
Stagefright is very serious issue on android devices not known to many android users.
Currently I am using CM12 Nightlies on my N5.
I read about Stagefright sometime back and found that my phone has been sending and receiving thousands of SMS and MMS. So i blocked all access to CM12 Messaging app using Privacy Guard. Privacy Guard is one reason why i love CM12, loved slimrom too...
Attached are screenshots of my Messaging app and a report by Stagefright Detector.
1. How android phones are really hacked by simple SMS/MMS
2. More about Stagefright
3. XDA on Stagefright
Did google really fix this and did CM do anything about this??? I believe majority of the testing is done on N5 and other nexus devices.
this is frightening!!!
How many of you have been exposed to this???
Lordificated said:
Did google really fix this and did CM do anything about this??? I believe majority of the testing is done on N5 and other nexus devices.
Click to expand...
Click to collapse
Yes, it did. With official release of Marshmallow (build MRA58K), all CVE's, that Stagefright Detector is checking, are fixed, and device is not vulnerable. Your issue is on CM side, not Google's.
First of all, blocking MMS access on Messaging will only prevent a small portion of the exploit. Stagefright is a large library, it basically plays *every* media file (based on my knowledge). This includes stuff that browser plays (for example : webm video, like YouTube) all of these are handled by Stagefright and FFmpeg library.
But, the good thing is, the library is not exploited widely. This means there's no wide range attack (based on reports online). No need to worry, the issue is internally fixed on Google side, if you can update to latest CM nightly release the issue might be fixed.
Srandista said:
Yes, it did. With official release of Marshmallow (build MRA58K), all CVE's, that Stagefright Detector is checking, are fixed, and device is not vulnerable. Your issue is on CM side, not Google's.
Click to expand...
Click to collapse
I guess they did, on Android M...
as you said, Stagefright detector says there are no vulnerable CVEs on my N5...
Moved from CM to Stock 6.0... But I am not sure if I love the App Permissions settings of 6.0 over the Privacy Guard in CM12...
still :good:
F4uzan said:
First of all, blocking MMS access on Messaging will only prevent a small portion of the exploit. Stagefright is a large library, it basically plays *every* media file (based on my knowledge). This includes stuff that browser plays (for example : webm video, like YouTube) all of these are handled by Stagefright and FFmpeg library.
But, the good thing is, the library is not exploited widely. This means there's no wide range attack (based on reports online). No need to worry, the issue is internally fixed on Google side, if you can update to latest CM nightly release the issue might be fixed.
Click to expand...
Click to collapse
yes, i read the same about Stagefright... being a large library used for almost all media access, most of the apps we use triggers Stagefright... but as you said, now that nobody knows the extend of vulnerabilities of Stagefright, we can only prepare for what we know!