The “simplest” way to configure how much memory Gradle will use is to configure the heap for the JVM process it spawns by passing args with org.gradle.jvmargs in gradle.properties (either in the project root or in your user’s .gradle directory which overrides the former):
# Set a maximum heap size of 4 gigabytes
org.gradle.jvmargs=-Xmx4g
There are caveats to this though. If you want to configure Gradle for machines with tighter memory constraints (like a container based CI environment), or to take advantage of a beefier dev machine there a few more possible tweaks you’ll want to be aware of:
org.gradle.jvmargs JVM args. It’s good to keep in mind that if you configure Gradle to use a specific heap size, then you could actually end up using double that during compilation of a mixed Java/Kotlin project.kotlin.compiler.execution.strategy=in-process as part of gradle.properties (useful for CI configuration) and its heap can also be configured.maxHeapSize property in the test block of a build.gradle or in unitTests.all in android > testOptions. Remember that this heap size is additional (Gradle spawns a specific worker process for tests) to the already spawned Gradle processes handling compilation and other tasks. If you configure a heap size of T for tests and D for your standard Gradle daemon, then your peak heap memory will be T + D (or T + D * 2 if you haven’t disabled the extra Kotlin daemon).Gradle can also handle tasks in parallel. This is useful for multi-module projects where modules are able to be built/tested in parallel as long they don’t have dependencies on each other. You can enable this feature by adding org.gradle.parallel=true to gradle.properties. There is again, a few things you should keep in mind when doing this:
org.gradle.jvmargs.org.gradle.workers.max, but this should default to the number of CPUs.maxParallelForks (again in test or unitTests.all For Android) to a number greater than 1. The caveat here is that this will spawn new processes instead of threads, so you need to have the capacity to handle maxHeapSize multiplied by maxParallelForks in addition to the Gradle daemon’s heap.I’ve personally found that build tasks often benefits from a boost in heap size, but that most test runs (unless there is some underlying memory leak) are pretty happy with the default 512mb heap size. You can also think about using different gradle.properties for different tasks (subbing them in and out with a script) or passing configuration as args on the command line. This isn’t as useful on dev machines, but can work well on CI where you often end up with a pipelined set of tasks (pull down dependencies, then build, then test for instance). With this approach, you could have different memory configurations for different tasks - you can prioritize compilation memory for compilation tasks and prioritize test memory for test tasks.
It’s also important to point out that the heap does not make up the total memory footprint of a JVM process: there’s the “Metaspace” for storing loaded classes, each thread has its own “Thread Stack” etc. This means that depending on your project, your Gradle tasks might consume noticeably more memory than you’d expect from your heap configurations. Ultimately, playing with the values and seeing what gives you the best results for your project is something you’ll need to spend time on. Using tools like VisualVM to analyze appropriate heap sizes for the different heaps, as well as tools like Activity Monitor on macOS (or the equivalents in other OSs) to check how large the actual processes get in memory will be really important here. Hopefully there’s enough info in this post to make that process a little less mysterious!
]]>Since Compose was announced in 2019, I’ve maintained a “healthy” (I’d argue) skepticism - we all know how willing to kill its darlings Google can be, and I’d seen the pain caused by Angular 1 to 2 rewrites. I was, and I still am working on a very mature and very large app, so any migration would need to wait until we saw Compose mature anyway.
This January, I took some time to play around with some toy apps for myself and decided to finally give it a go. What follows is what made me happy, and what made me sad.
@Preview feature is amazing, although it’s not quite clear why it couldn’t have worked for standard Android views, and I’m salty that they haven’t ported it over.foundation package Composables (like BasicText etc.) and CompositionLocal for theming.AndroidComposeTestRule. That said…
ComposeTestRule to interact with Composables in tests (you can’t use Espresso) which means that the tests are locked in to the implementation somewhat, and you’re always going to have to change tests when migrating to Compose. The only alternative to avoiding these costs/risks would be to use UIAutomator.Unit and “emit” views (as opposed to returning some kind of Composable super type) feels uncomfortable to me.Exception is thrown) while running a task in the background using WorkManager. I realised I had no idea, so decided to investigate.
After playing around with the debugger and a few choice placements of throw RuntimeException(), I’ve managed to conclude a couple of things:
Worker#doWork are caught by WorkManager and then logged as errors, but the exception does not cause your app to crash. This is possible to see from testing, but is also clear from the underlying code.Result.failure: any work that depend on this work as part of a chain will not run, and periodic work won’t run again until the next scheduled time. For example, if the work is scheduled to run every 15 minutes, it will try again in 15 minutes after an exception.This is good news for the stability statistics of your app, but does mean that it’s easy to completely miss that your background tasks are failing due to unexpected exceptions - you wouldn’t see them in development unless you’re paying close attention the logs and they wouldn’t appear automatically in crash logs (like Crashlytics for example).
Surprisingly, I couldn’t find any documentation on this, but it seems to me like it’d be good practice to wrap your Worker#doWork implementations in a try-catch so you can handle exceptions like so:
class MyWorker(context: Context, workerParams: WorkerParameters) :
Worker(context, workerParams) {
override fun doWork(): Result {
return try {
// do your thing
Result.success()
} catch (t: Throwable) {
// handle or log exception
Result.failure()
}
}
}
You could also return Result.retry() from the catch branch if you want work that “explodes” like this to be retried with whatever backoff policy you have configured for it rather than not run again (or wait till the next scheduled time for periodic work).
android:enableOnBackInvokedCallback manifest flag). They’ve flip-flopped on this before, so I wouldn’t be surprised if it ends up behind a developer setting again in Android 15’s final release.ActivityController) that weren’t possible using AndroidX’s ActivityScenario. For my own benefit as much as anyone else’s, I wanted to go a bit deeper into exploring the different scenarios in which an Activity is recreated in Android, and how to simulate those using Robolectric so that you can test your Activity’s behaviour during them. I’m not going to be concerning myself with scenarios where the app is restarted fresh like from a “Force Stop” or a power cycle.
It’s worth noting that you can hopefully avoid needing to care about these scenarios by doing good things like avoiding static/application state, adhering to the tenants of unidirectional data flow and never making any mistakes. If you’re a mere human however, understanding these scenarios and protecting against bugs that they might cause is probably important. It’s also worth noting that, with some noted exceptions, I haven’t found a lot of solid documentation on any of this, so feel free to shout at/correct me about anything you read here that is incorrect.
As far as I’m aware, there are 2 distinct Activity recreation scenarios:
In this post, I’ll attempt to document these scenarios (along with a nasty twist on them) and give examples of how they can be simulated using Robolectric.
A third scenario we can refer to as “System recreated Activity” (without recreating the process) is possible to simulate with the “Don’t keep activities” developer setting. This setting destroys every Activity after it is no longer visible (like when another is created on top). This is potentially a useful way to test how robust your Activities are when put through recreation, but it’s important to point out that this scenario should never happen outside of when the setting is enabled. This was answered pretty definitively in this Stack Overflow question (with links to answers from the Android team themselves).
As far as I’ve seen, this is the only Activity recreation scenario that’s been well documented and can be easily tested using AndroidX Test with instrumentation or local tests. The basic premise here is that when something Android thinks of as “configuration” (like screen size, orientation, dark/light mode etc) changes at the system level, Activity object will be recreated with that new configuration. Before this happens, the system calls Activity#onSaveInstanceState which creates a Bundle that will eventually be passed to Activity#onCreate for the new instance of the Activity. That “saved instances state” Bundle can therefore be used to persist state between configurations. On top of that there’s two pretty big things to keep in mind:
ViewModelProvider) making them a good place to keep state that should stick around between rotations etc.DialogFragment instances) will be recreated as part of your super.onCreate call. This is useful for doing things like keeping dialogs on screen between configuration changes, but it can cause problems if your code doesn’t take into account setting things up for these recreated Fragments. A prime example of this that you’ll need to have any custom FragmentFactory setup taken care of before super.onCreate so that Fragments can be recreated.Here’s how to simulate this scenario using Robolectric:
val activityController = Robolectric.buildActivity(MyActivity::class.java)
.setup()
activityController.recreate()
As I said before, you can also use AndroidX Test for this:
val activityScenario = ActivityScenario.launch(MyActivity::class.java)
activityScenario.recreate()
As mentioned earlier, Android will occasionally destroy app processes in the background to reclaim memory. This probably happens more than you realize according to dontkillmyapp.com. When this happens, the app’s process and current back stack is destroyed (with corresponding Activity#onSaveInstanceState calls) and then both are recreated when the user navigates back to the app. Because the back stack is recreated, we do again get to keep our saved instance state Bundle and our Fragments, but we’ll lose ViewModels and any “process” level state (Java static or state we’ve attached to the Android Application). You can force this behaviour to happen whenever you switch between apps (the one now in the background will be destroyed) using the “Background process limit” setting in Developer settings.
I’m unable to provide a one-size-fits-all solution to simulating this scenario as what state needs to be reset or initializers that need to be run to simulate the process restart will be different for every app. Here’s an example that you can bring your own resetProcess implementation along to however:
val initial = Robolectric.buildActivity(MyActivity::class.java)
.setup()
val outState = Bundle()
initial.saveInstanceState(outState)
.pause()
.stop()
.destroy()
resetProcess()
val recreated = Robolectric.buildActivity(MyActivity::class.java)
.setup(outState)
It’s probably obvious, but still worth pointing out that implementing a realistic version of resetProcess is always going to be challenging as you might not be aware of every piece of static state in your app. I’d definitely suggest putting your app through this scenario manually in an emulator or a test device to discover any problematic state you might have.
You forgot about Activity#startActivityForResult right? Although it shouldn’t cause you any problems during configuration changes, it can add some real headaches to the system recreates process scenario. Imagine that MyActivity from our examples starts another Activity ResultActivity for result. Android could destroy the whole process if the user navigates away. When ResultActivity returns the result after this, onActivityResult will be called after MyActivity#onCreate is called during recreation which might get you in trouble if you’re loading state you expected to have ready already or if you have something important in Activity#onResume. Again, we can fortunately simulate this with some (arguably far nastier) Robolectric:
val initial = Robolectric.buildActivity(MyActivity::class.java)
.setup()
// Action to start `ResultActivity` for result
val outState = Bundle()
initial.saveInstanceState(outState)
.pause()
.stop()
.destroy()
resetProcess()
val recreated = Robolectric.buildActivity(MyActivity::class.java, this.intent)
.create(outState)
.start()
.restoreInstanceState(outState)
.postCreate(outState)
val startedActivityForResult = shadowOf(initial.get())
.nextStartedActivityForResult
shadowOf(recreated.get()).receiveResult(
startedActivityForResult.intent,
resultCode,
result
)
recreated.resume()
.visible()
.topActivityResumed(true)
Here we have to manually execute the lifecycle steps that ActivityController#setup was handling for us so that we can simulate the result being received (via ShadowActivity#receiveResult) between postCreate and onResume.
As far as I’m aware, the lifecycle steps and their ordering would be the same here if you opted to use the new Activity Results API instead of using the now deprecated startActivityForResult/onActivityResult directly (which you should if you can).
We’re at a point where we need a fairly noisy amount of code to simulate these scenarios, and in practice these tests would be very hard to read. I’ve wrapped all this up in an extension for ActivityController to make my (and hopefully your) life a little easier:
inline fun <reified A : Activity> ActivityController<A>.recreateWithProcessRestore(
resultCode: Int? = null,
result: Intent? = null,
noinline resetProcess: (() -> Unit)? = null
): ActivityController<A> {
// Destroy activity with saved instance state
val outState = Bundle()
this.saveInstanceState(outState).pause().stop().destroy()
// Reset process if needed
if (resetProcess != null) {
resetProcess()
}
// Recreate with saved instance state
val recreated = Robolectric.buildActivity(A::class.java, this.intent)
.create(outState)
.start()
.restoreInstanceState(outState)
.postCreate(outState)
// Return result
if (resultCode != null) {
val startedActivityForResult = shadowOf(this.get())
.nextStartedActivityForResult
shadowOf(recreated.get()).receiveResult(
startedActivityForResult.intent,
resultCode,
result
)
}
// Resume activity
return recreated.resume()
.visible()
.topActivityResumed(true)
}
There was probably a way to do this without reified, but what fun would that be?
And to finish, a poem:
This is the way the world ends
This is the way the world ends
This is the way the world ends
Not with a bang but a cheer for dark theme.
I finally got “Bow, East” onto streaming services. I originally put the release up on Bandcamp last year and then discovered that Spotify, Apple Music etc will not except a single track release where the track and release title don’t match. I did what anyone would do - huffed.
I then spent almost a year spinning my wheels about if I should give in and rename the track, or add a silent track, or split the single track or any other of a thousand alternatives. I ended up biting the bullet and splitting the single track into three which does fit pretty well given the composition has three “movements”. Anyway, links to the release on different streaming services can be found here.
I ended up getting very into Saint-Petersburg’s Black Metal act Somn after loving their half of the split they did with Wowod. Their first album is definitely worth a spin:
Collect v2023.1 launched at the end of the month. I spent a chunk of the release cycle adding selectable geo shapes. This will likely be hugely useful for folks, but building out these kinds of features can be a little mind-numbing as Collect supports three different mapping engines (Google, OSM and Mapbox). See previous posts for shenanigans around that. I’m currently “on strike” from maps work until I feel less burnt by it.
I also ended up working on a couple of other projects this month:
Before leaving the US, I spent a great night out being a pretend somm for my bestie and all round good guy Colin Deeb in Oakland’s Slug Bar (which I’d heavily recommend). My choices for the night were:
I guess there was only so long that I was going to stick to my “only local wines” rule.
We spent the end of March (and a good portion of April) in Lyon, so I ended up drinking a ton of Gamay. More on that next time.
I’m still board game free given we’re on the move, but I did spend way too much time on a replay of Death Stranding on my Steam Deck. It’s still absolutely baffling (in a good way) that this game exists. The Director’s Cut is well worth picking up if you’re in the mood for a first or second go around.
]]>