Good day, everyone. Welcome back.
Everything we've done so far in the course has been using the debug build.
That's great while developing,
as it allows all our debug log entries to appear in the logcat.
You wouldn't normally want to take up space on the user's phone
with huge log files,
and the debug log entries are stripped out of the release build.
As I mentioned, any code that's dependent on
buildConfig.DEBUG being true
also won't be compiled into the release version of the app.
It gets better than that.
Any classes you put into that debug folder,
the one we created, and that's showing with (debug) in parentheses
after the package name in the project pane
those classes won't be compiled into the release version either.
We can check that to make sure.
From the build menu,
choose the option build bundles/apks
and then build apks.
When the build is finished, a dialog pops up at the bottom
of the android studio window.
Click the link to analyze the apk. The apk,
by the way, is the file that's used to deploy your package.
You may have noticed messages about apk
when running your apps from android studio.
An apk file is just a zip file,
containing everything that the app needs in order to run.
All your classes and resources are included in the apk file.
In earlier versions of android studio,
you had to extract the contents of the apk zip file
and examine it using your computer's file manager
or a terminal session. Now things are much easier.
Android studio has an apk analyzer.
This gives a neat summary of the sizes of the various parts.
You can see, for example,
if your res folder is making up a large percentage of the overall size.
The raw file size of this app is around 2.5 megabytes
with our resources, icons, images and so forth
making up nearly 400 kilobytes of that.
If you've got a lot of images, that value might be a lot higher.
We'll look at reducing the value a bit later.
When we use vector graphics for our icons instead of png files.
Okay. Most of the app size
is the classes.dex.
So click on that to get a more detailed breakdown in the bottom part of the window.
That shows the various packages that make up the app.
Android x makes up a lot of the total space used
and that's things like the new support libraries that we're using in our app,
the recyclerview, for example.
Google are working on ways to share things like android x amongst apps.
At the moment, those libraries are compiled into each app that uses them.
Obviously that's not very efficient,
but there are problems with allowing them to be shared.
When google sorts it out, app sizes will shrink substantially.
Expand the android x entry.
And you'll see that appcompat is a substantial amount of the total.
That will be support in the android package
if you haven't converted your app to use android x.
These figures don't add up by the way.
So don't try to balance the sizes in the bottom part of the screen
with those in the top part.
There's all sorts of clever compression techniques going on here.
Use the sizes as a relative measure of the various packages
and don't try to equate those bottom figures with the top ones.
What we're really interested in are the entries for our packages.
I called my package learnprogramming.academy.doxtimer.
So I have to expand that to see more details about it.
If you used a different domain, expand the relevant entry in the list.
The entry we're interested in at the moment under
learnprogramming.academy.doxtimer is a debug entry.
In there, we can see our testData class.
So in the debug build that class is included.
Close the window then go to build,
select build variant.
You may need to click in an editor window
to enable that entry in the menu.
Although it doesn't look like it, the build variant box on the left is a drop down.
Click it, then select release.
We can now create a release apk, using build,
build bundles build apks again.
All we could do if we didn't have an error in main activity.
The test data class is no longer available.
When you create a release build, anything in the debug directory
doesn't get included.
That means the release build
has no knowledge of our testData class.
In fact, if you check the project pane,
the debug package isn't even showing up.
Main activity is showing two errors.
There's one when we try to use the testData class in the
on options item selected,
and the others in the import section
when the program tries to import that class.
In a release build, anything in debug
just doesn't exist effectively.
So there's no chance of us accidentally, including these debug classes,
testData and test timing in the release version of our app.
The app just won't compile.
This isn't the most sophisticated way of handling this.
If you work for a company developing android apps,
you'll probably find they have more advanced processes in place.
But as a developer, this technique is a good start
to make sure you don't include debug classes
in the apps that you deploy.
Create a debug package as we've done here,
and there's no chance of messing up by giving users things
they really shouldn't be seeing.
When you want to deploy your app, comment out the code that's giving the error.
You may also have an error whenever buildConfig is used.
If that happens, rebuild the project from the build menu.
To check what's in our release apk, go to the build menu again
and choose build bundles,
build apks.
Then click the analyze link in the dialog.
It may take a while to create a release build.
Keep an eye on the progress at the bottom of the screen.
Click classes.dex.
Then expand your package name
learnprogramming.academy.doxtimer.
Learnprogramming.academy.doxtimer in my case.
Notice that the debug entry isn't present.
That class just doesn't exist in build.
The raw file size is also smaller than it was.
A lot of other debug stuff has been stripped out of the release version,
including all our log.d calls.
Okya. Close the analyzer.
Then make sure you set the build type back to debug.
Build,
select build variant,
debug.
That's important because you can't run a release build without signing it
and we'll be covering that in a later video.
I better uncomment those two lines as well.
We've now got a way to generate test data in our app,
and we've seen how to avoid accidentally giving users access to the testData class.
Even if we somehow ship a version with that generate menu item enabled,
it won't work for our users.
That's a good thing
because trying to unscramble test data from their live data
would be far from trivial.
If you make a mistake and ship a version of the app
with that menu option enabled, it'll crash when they tap it.
That's not good.
What all you have to do is deploy a fixed version.
If you left the testData class in, the app wouldn't crash.
Instead, it would add a load of rogue records to their database,
explaining to your users that the data they've collected over the last
year is useless isn't something you want to have to do.
In the next video, we'll make a start on displaying reports about the data that we've got.
I'll see you there.