App size too inflated?

[sonora]

I have received several requests now asking if it was on purpose that the app (apk) size has increased by some 30% or so between 4.0.x and higher versions.

I remember we added some AndroidAuto code, and raised our minSDK requirement, but I have to admit that I am a bit surprised myself that the app size increased by 20 or 30 MB?

[pebogufi]

Some details for OsmAnd-android-full.apk 4.1.0#33144. 28/11/2021 123,6MB 4.1.0#33442. 21/01/2022 124,2MB 4.1.0#33465. 25/01/2022 128,3MB

Sorry, I don't have older data.

[sonora]

4.0.9 was around 94MB, see https://download.osmand.net/releases/net.osmand-4.0.9.apk

[vshcherb]

It was expected cause in 4.2 it bundles with opengl engine now.

[vshcherb]

https://download.osmand.net/latest-night-build/OsmAnd-opengl-arm64-nightly.apk it's by 50 MB bigger than Android

[vshcherb]

Also mini basemap is now + 10 MB - https://builder.osmand.net/basemap/release/2022-01/

[vshcherb]

Most significant changes

OsmAnd-default-nb-2021-09-13.apk                   13-Sep-2021 21:27           105993422
OsmAnd-default-nb-2021-09-20.apk                   20-Sep-2021 13:02           127619948

OsmAnd-default-nb-2022-01-24.apk                   24-Jan-2022 17:57           130327835
OsmAnd-default-nb-2022-01-28.apk                   28-Jan-2022 17:57           134575258

---

OsmAnd-master-opengl-nb-2021-09-13.apk             13-Sep-2021 21:04           130661908
OsmAnd-master-opengl-nb-2021-09-20.apk             20-Sep-2021 21:04           148512808

OsmAnd-master-opengl-nb-2021-12-20.apk             20-Dec-2021 22:04           152110663
OsmAnd-master-opengl-nb-2021-12-27.apk             27-Dec-2021 22:10           155429511
OsmAnd-master-opengl-nb-2021-12-31.apk             31-Dec-2021 22:08           162349266

[sonora]

But our default builds are not at all open-gl capable, or are they?

And still, their file size increased from 105 to 135 in recent months?

[vshcherb]

And still, their file size increased from 105 to 135 in recent months? Not recent months, 1.5 year since September 2021

[sonora]

September 2021 is only 8 months ago ... ;)

But to the poinit: If you look at our releases at https://download.osmand.net/releases/, the jump happened between v4.09 in September 2021 and v4.1.1 in December 2021. I was just wondering what the respective increase in functionality was, AA, mini-basemap? Dont't think it was open-gl because these builds don't support it, or am I wrong?

BTW: Users ask me if they should manually de-activate the mini-basemap once they have downloaded the real basemap to avoid the renderer to double-process?

[vshcherb]

I think you are right nightly includes only:

• Android Auto
• Mini Basemap

[sonora]

Must be, Iguess. Unless we included new fonts again by accident, had that issue some years back, I remember.

Any opinion about the question if the mini basemap should be disabled when a real basemap is present, or is that worth a separate issue?

[vshcherb]

Mini basemap is disabled at least last time we tested it works. Didn't see any issue. But the map is present on the file system!

[vshcherb]

With such apk size it's worth to investigate how to update frequently cause 90% stays the same each update:

• icons and graphics
• basemap
• fonts
• quite a big list of native libraries such as qt, gdal, ...

[sonora]

Yes, valid point.

Regarding basemap mini, I guess what triggered users is that under "local maps" we show both maps as active, so if mini is automatically disabled and we don't reflect this, this could be a bug:

[vshcherb]

@sonora we have ongoing same conversations about TTS always copied or files dispalyed and not active. So we need to choose 1) Either display all files present in the folder 2) Start filtering files by some unknown yet strategy. Strategy could be different for different group of files

[sonora]

To implement more 'hygiene' here, could perhaps move the 'mini' file to the backup folder once user downloads the full basemap, then our code would automatically show it it as 'deactivated'?

General update strategy, also for TTS files could be: Place all files prresent in the apk itself in the backup folder (overwriting any predecessors there), except a previous version is present in the active-maps or active-voice folder, in which case we would overwrite it there? This strategy would ensure that any data files deactivated by the user would remain deactivated even if the app is updated and the apk contains some updated data files?

[vshcherb]

New information

• Big increase of native libraries: 3.45 MB -> 18.8 MB (nothing we could do here very likely - that's GDAL + OpenGL lib)
• Increase other 8.55 MB -> 10.5 MB (negligible for now)
• Code 10.8 MB -> 11.5 MB (expected)
• Resources (icons) 13.9 MB -> 14.6 MB (expected)
• Assets 32.8 MB -> 61.8 MB (To investigate) - something very strange if it's a new size of basemap we need to make it smaller in any case than.

[vshcherb]

Assets should be decreased obviously:

• 71M OsmAndCore_ResourcesBundle (35 MB zip) - not needed at all
• 12M fonts (6.4 MB zip) - download later?
• 45M World_basemap_mini.obf (28.6 MB zip) - make smaller? download later?
• 2.3M Default_wikivoyage.travel.obf (1.8 MB zip)

[vshcherb]

As a side comment for world basemap mini: Tiles of 1-6 zoom - 53 MB Tiles of 1-7 zoom - 150 MB World basemap mini - 30 MB World basemap - 267 MB

[ivanPyrohivskyi]

/assets/OsmAndCore_ResourcesBundle

Can be optimized: map/fonts - 6.1Mb, need add external initializating in EmbeddedTypefaceFinder (Android/iOS) map/styles/default.render.xml.gz - 88Kb, need add external initializating in ResourcesManager (Android/iOS) routing/routing.xml.qz - 22Kb, need external initializating in RoutingConfiguration (iOS only?)

Difficult to optimize: [ddf=x.x]/map/icons [ddf=x.x]/map/shields [ddf=x.x]/map/shaders [ddf=x.x]/map/stubs Total size 10.6Mb. For Android need to create special provider that provide icons from Android (throw Swig) to core library. In Android for legacy code present method getIconRawData in RenderingContext (RenderingIcons) class. And divide icons initialization iOS and Android.

Can not be optimized: misc/icu4c/icu-data-l.dat.gz - 7.1Mb, using in core library only

Technical moment: All resources for OsmAndCore_ResourcesBundle describe in core/warappers/android/build.gradle

[sonora]

I just notice that the analysis in @vshcherb 's picture of December 10 above compares v4.1.1 with v4.2.4, which in deed shows a big increase. But there was an additional not plausible increase of the order of 30%(!) immediately before that from v4.0.9 to v4.1.1. Maybe including that in the above analysis picture would give additional hints?

In general, I think our 'First app start' handling has progressed enough lately so we could place some tasks there, like not only recommending to download the regional full map for the user's location, but also offering to download a mini or full basemap, plus perhaps special fonts. Then these could be taken out of the app. Their maintenance cycle is separate from the app's, anyway.

[vshcherb]

@sonora I don't see any increase except releasing opengl version

[sonora]

Here is our release apk size development over time, sorted by time: apksizes-over-time.txt (as taken from https://download.osmand.net/releases/).

The bump I talk about is in line 436:

[vshcherb]

That doesn't explain cause it could be x86-64 version for example which doesn't affect download size on google play

[sonora]

I think the apks listed there are all "fat" builds...

[sonora]

So what do you think, shall we at least move the mini-basemap and the special fonts out of the apk to separate in-app downloads, plus offer them on our 'First app start' screen?

[vshcherb]

Nope, that's non-sense it only saves disk space for updates which is not needed cause google play already does it automatically. Solution is only

1. Reduce size of mini basemap
2. Double check that fonts are download with specific maps not for all apps if possible
3. Reduce resources usage by letting opengl engine reuse vector drawables from android resources

It could save up to 50-60 MB

[sonora]

My thinking is that as long as we include it in the apk, even if users delete the basemap or special fonts, this data will continue to occupy system storage like everything which is part of an apk. If instead it was a separate download (like that standard basemap is), it will not consume system storage, but only internal or external storage (wherever your OsmAnd data folder is), and only while present.

[Arian03dc]

My thinking is that as long as we include it in the apk, even if users delete the basemap or special fonts, this data will continue to occupy system storage like everything which is part of an apk. If instead it was a separate download (like that standard basemap is), it will not consume system storage, but only internal or external storage (wherever your OsmAnd data folder is), and only while present.

Good idea, by example, I don't want world basemap, only Cuba map, and the fonts files can be deleted if isn't neccesary

[ivanPyrohivskyi]

Need add logs of initializating fonts in core, like this (core-legacy): 2023-03-17 15:50:07.060 21792-21847/net.osmand.plus I/net.osmand:native: Font path /storage/emulated/0/Android/data/net.osmand.plus/files/fonts/05_NotoSans-Regular.ttf index 0

[sonora]

So whatc do we think, can I re-table the following idea for perhaps our v4.5 milestone?

...shall we at least move the mini-basemap and the special fonts out of the apk to separate in-app downloads, plus offer them on our 'First app start' screen?

Perhaps just for the basemap mini, which few people may actively use as a lasting map, but it (if part of the apk) remains to reside in your internal device memory forever even if user-disabled in the app or user-updated to the full basemap?

Google Play mechanisms will foreseeably never fix this one, because the basemap mini is neither device achtecture nor locale specific.

[vshcherb]

@sonora Google Play don't have that issue that's why it's a low priority. Last update was only 5 MB because Google Play updates only parts that were changed so it doesn't update Mini basemap if it's not needed.

However for new users it's critical to download basemap cause user will anyway need other much bigger maps to be downloaded, so it's lesser issue.

Though we need to think about testing where it's much more critical issue.

[sonora]

Quite possibly we have two types of users:

• the ones who will download a full basemap anyway, from which point on them having a basemap-mini is dead freight
• and the ones who never care about basemap using OsmAnd purely on a regional level. Would our telemetry-data give any insight into how the actual numbers are?

[vshcherb]

With downloads it's still 10% download full map but it's not perfect data cause iOS requires to download full map we still need to reiterate

[sonora]

I have tested that excluding the basemap_mini from the apk

• reduces the apk size by 30MB (for all flavors),
• and updating with that apk permanently reduces the "App storage" Android reports as "used by OsmAnd in Internal storage" also by 30 MB. (This Internal storage saving can only be achieved if the basemap mini is not part pf the apk - if it is, it will after aop installation pemanently occupy 30 MB here even after in the app the user deletes the basemap_mini, e.g. after downloading a full basemap).