Content Library files location on an Android+ tablet

DA
Dan Andrea
Jack Cooper Transport Company, Inc.

I'm trying to diagnose an issue I'm seeing on some of our deployed tablets related to the Content Library.  In order to figure out what is happening I need to look at where the Content Library files are saved to the tablet, as in the specific folder on the device where they download to.

Where is the specific folder that the MobiControl client puts the Content Library files?

7 years ago
Android
ANSWERS
RC
Raymond Chan Diamond Contributor
7 years ago

Files in the content library are stored in Mobicontrol sandboxed directory tree with their file name modified, and are not meant to be directly manipulated by apps other than MobiControl device agent.  Would you mind giving more details on what issue you have you need to diagnose?  Some indirect way of diagnosing may then be suggested.

DA
Dan Andrea
7 years ago (edited 7 years ago)

I've got some tablets that aren't downloading the content.  I suspect it's the data connection being too slow, but I'm not sure.

When I look on the tablets in Content Library, every time we try to open something it tries to download it, then shows 0 bytes.  And letting it sit overnight (or over a whole weekend) doesn't change anything.  I was hoping to see where it stored the files to see if anything was there.

On several test tablets here with good connections and on other tablets out in the field, these files download and open fine.

RC
Raymond Chan Diamond Contributor
7 years ago (edited 7 years ago)

If what you suspect is really the case, why not implement a possible solution while you try to verify the cause. 

Just duplicate your content library for those devices with poor connections, but change the delivery method from "on demand" to "push".    The device agent will then try more aggressively with more retries to download the whole file content to the device in advance.   ( Note: On-demand delivery only allows limited amount of retry to avoid extremely long delay for the device end-user to wait after the content request, and will likely fail if the connection is really poor.)  You can try out first with content of smaller size.  

This approach, of course, won't work if you don't  have sufficient space on the device to store, or if the connection is expensive paid connection in which unnecessary data traffic has to be avoid at all costs. 

DA
Dan Andrea
7 years ago (edited 7 years ago)

Well, everything in the Content Library is already set to Push.  Previous MobiControl Admin here had found issues and set it to Push on MobiControl Support's recommendation.  And it doesn't matter the size (some are less than 100K bytes, others are megabytes in size), they all do the same.  Even though the data connection is poor, it should  have at least downloaded some of these files over the weekend (some have been on the whole time). Also, these devices are freshly set up, so lots of free space on both the internal and external SDcards.

I was hoping to find the local file, if any, to delete and have it try again as a workaround.

RC
Raymond Chan Diamond Contributor
7 years ago

The device agent will automatically retry for any content that are not successfully pushed.  There is no need to manually delete anything.   How many files do you have in your content library, and how big are they? 

Have you tried adding a new content library with only one small image file ( e.g. png icon or low-resolution jpg photo) of size less than 100 K-bytes?    If even that doesn't work,  the cause of the problem may be something else.

DA
Dan Andrea
7 years ago

I think for now I'll hold off on this and likely just turn in a ticket.  Was hoping for a quick answer for where the files are.

Too many projects this morning so this has to go on the back burner again.

G
GMod@SOTI
7 years ago

Hi Dan,

As mentioned by Raymond, Content Library files are actually stored in its own application sandbox that is only meant to be accessed by MobiControl. 

I would recommend opening a support case to investigate further since this looks like a case we will need to look into the logs for.

Regards,
~G