Help and FAQ

NimbleApp can accept user credentials for your app when you do your initial upload, and will use those to auto-login to your app. Default fields are username/email and password. We also support adding custom login key/value pairs.

You can add or update credentials at any time by clicking the Settings icon, then the App Data section.

Yes, absolutely. We track and group uploads by package name.

It depends. If your app is not well optimized to start with and NimbleApp has detected many performance issues, you can get significant speedup, in some cases, more than 40%.

Our current product is designed to profile non-game apps.

Yes, NimbleApp can still detect performance issues in your app. One caveat is that you may not be able to optimize away these issues if they are problems of the app builder you use.

We run profiles on Android KitKat 4. Support for Android 5, Android 6 and above is in development. Issues detected for one version of Android are generally present when running on other versions of Android, so fixing an issue for one will usually resolve for other versions.

We use Nexus 5 devices for profiling, and plan to add more types. Performance issues identified on one device will generally be seen in other devices.

We provide tethered wired connections to devices in order to ensure that localized wireless issues do not impact performance measurements.

We use a heuristic to tell when an app finishes startup by detecting when (1) the main Activity has been displayed and (2) things like animated progress bars in the main Activity have stopped. Based on our experiments, this heuristic works in most cases.

To identify the main Activity, we run the app at least twice, wait for up to 30 seconds, and check the last Activity displayed. If this is consistent across multiple startups, it is designated the main Activity. Once identified, the app is started and measured multiple times, and the average is reported.

We also support customizing where startup measurement ends, for more details see our API Documentation

There are three different kinds of app startups:

• First Startup, which occurs when a user runs your app for the first time after a fresh installation of your app. During the first start, your app does some extra work, such as initializing SQLite.
• Cold Startup, which occurs when a user runs your app after she hasn’t used your app for a while. If an app is not used for a while, Android typically removes the app from the cache to save memory. Cold start is generally the most typical case, and affects UX the most.
• Warm Startup, which occurs when a user switches away from an app then switches back. Your app is still in Android’s cache, so it is typically fast.

A hung method is one that runs/blocks the UI thread for longer than 32ms. In Android, the UI thread is the main thread of execution for your app, and the only thread that can update UI. If a method call runs for too long in the UI thread, your app won't be responsive to any user action during the call. In addition, users will notice a "lag"/"gap"/"stutter"/"choppiness"/"jitter" — to maintain a 60 frames-per-second refresh rate supported by today's most devices, your app must finish drawing each frame withing ~16ms. We chose 32ms as the threshold for flagging a hung method because it corresponds to two dropped frames. On average, humans can detect lag as short as 22ms, and a fourth of the population can perceive lag between 2ms and 16ms Among the apps we analyzed we’ve found hung methods that run for over a second! A hung method may be caused by many reasons such as network I/O, expensive computation, and lock contention.

A hot method is one that consumes a large percentage of CPU time across all its invocations. It can steal CPU time from the UI thread or background thread that are doing work on behalf of the UI thread, therefore making your app less responsive.

Unlike other profilers, NimbleApp can integrate with your Continuous Integration process. NimbleApp analyzes your APK and reports back on issues like crashes, performance bottlenecks, and more. Even when you're working on something else, our automated Alerts will tell you when something has gone wrong with a build. And our platform allows multiple team members to collaborate on the same application.

We offer an open-source Gradle plugin which allows you to upload builds automatically from your CI server. Check out our CI integration help page for instructions on setting it up.

We will also offer a REST API in future offerings, Contact us if you want to know more.

• Our website is hosted in ISO 27001 and FISMA certified data centers managed by Amazon Web Services
• Physical access to data centers is strictly controlled both at the perimeter and at building ingress points
• Data centers employ onsite security staff, video surveillance, and intrusion detection systems
• Authorized staff must pass two-factor authentication a minimum of two times to access data center floors
• Data centers are housed in nondescript facilities
• Physical security verified by third-party auditors. For more information see http://aws.amazon.com/security/

• Security policies and procedures, regularly reviewed as part of the Amazon Web Services SSAE 16 Type II audit process
• Systems access logged and tracked for auditing purposes
• Regular system patching processes to provide ongoing protection from exploits
• Firewall to prohibit unauthorized system access
• Intrusion detection systems to provide an additional layer of protection against unauthorized system access

All access to the NimbleApp website is restricted to HTTPS encrypted connections. All apps are uploaded through HTTPS encrypted connections so that no one can eavesdrop on the network sockets. Once uploaded, apps are temporarily stored within the Amazon Simple Storage Service, part of the Amazon Web Services and subject to the same high security standards. Apps are deleted as soon as performance analysis succeeds.

User passwords are secured with BCrypt (more specifically, 10 rounds of salted and peppered BCrypt). They are never stored in the database in plaintext and are not readable by staff. Passwords do provide access to the NimbleApp website, however, and it is the responsibility of the end user to protect his password with care. NimbleApp also offers and recommends optional OAuth2 login integration with Google for users who would like additional authentication security and convenience.

NimbleApp never collects or stores passwords for external applications like Google and Slack. Integration with third-party apps is done via either OAuth or API keys.

Your input and feedback on our security as well as responsible disclosure is always appreciated. If you have a security concern, please email us at contact@nimbledroid.com.