Monthly Archives: October 2018

I have spent the past few weeks improving major parts of this app and I am finally at the point of releasing the new and shiny interface.

My ultimate goal for this app is to pull in all of the views into 3D and outshine other similar apps in beauty and create the best app for the job ( as usual ). This is a new beginning for the app and I will likely spend the next few months improving it.

HUD

I love iron Man like HUD interfaces. As such I am building a library with multiple interfaces for different visualization purposes. The interface above is a switch-board with a connected gyroscope and the Earth centered in it.

After the initial release I want to create a terminal emulation which I can scale at will in 3D space, followed by an audio interface which coverts input from the microphone into a nice 3D visual.

There are many more possibilities and I am having fun creating these playful widgets.

Shader

Another area which I want to invest some time in is to work with some custom shaders to bring out some glowing special effects and other goodies.

OpenGL ES 2.0 is a strange beast and not necessarily the easiest environment to learn but it offers some great flexibility in what you can accomplish. The ES, which stands for Embedded Systems, introduces a few changes as compared to the desktop OpenGL implementation.

OpenGL ES 2.0 Programming guide

I am currently going through the “OpenGL ES 2.0 programming guide”, which is a real good book to learn OpenGL. It will help me to realize the remaining widgets and animations to convert the complete app into the 3D realm.

Please give it a try and let me know what you think of it. Also I would love to hear if you have any ideas for a widget which I could implement.

If you have ever tried your hand on coding for Android you certainly have found google’s JAVA based API to be somewhat of a incoherent mess in certain areas, which over time has evolved into an even larger incoherent mess in even more areas.

One of those messy areas is that of the android secondary storage API. All phones have a primary storage area, where you can store images, videos, apps, and application data, and some phones come with a secondary storage option. The API to gain access to the primary storage has evolved over time but allows you to seamlessly integrate proper functionality into your app.

Now you may assume that the Android secondary storage would follow the same paradigm, and grant the same access as the primary storage to your app. However you would be wrong making this assumption. The reason you have apps like the “ES File Manager” handling this for you seamlessly is purely through tricky code in the background which circumvent googles protective scheme for secondary storage, Aka a hack.

Let’s start with a small bit of terminology. Since the dawn of Android, nearly every type of storage has been considered “external storage” even the non-removable flash memory that comes in every device. To distinguish, the non-removable flash memory is called “primary storage”“secondary storage”. In the early Android versions, an app merely needed permission to WRITE_EXTERNAL_STORAGE to be able to fully access both primary and secondary storage.

In March, 2011, a drastic change to Android was made which changed how secondary storage mediums (external SD cards) were mounted by the Android OS. Specifically, the commit read like this: “Mount secondary external storage writable by AID_MEDIA_RW rather than AID_SDCARD_RW.” This meant that the media would now have to belong to the “media_rw” group to modify the contents of the SD card. As a result, a new permission, called WRITE_MEDIA_STORAGE, was added to the source code. Basically, WRITE_MEDIA_STORAGE replaced the original WRITE_EXTERNAL_STORAGE.

This change has a devastating effect on apps trying to utilize secondary storage because from now on forward only system apps could request the permission to read/write to the external storage ( I.e. sdcard ).

Android secondary storage

Since the WRITE_EXTERNAL_STORAGE permission could be used by any normal app and thus any app can write to the primary storage but not to the secondary storage (external micro SD cards). The WRITE_MEDIA_STORAGE permission could write to the external micro SD card, but regular user apps could not request the permission. This change took place on Android 3.2 Honeycomb, but due to the logistics of hardware and storage mediums at that time, it was barely noticed.

Quote: “Starting around the time of Android 4.4 4 KitKat, and even a little earlier, the implementation of the userspace FUSE filesystem, in conjunction with changes to the open source code, resolved this problem. Yet, still to today, even with Android 8.x.x Oreo, third party apps must explicitly get the user’s permission for both primary and secondary storage before the app can alter either storage medium in any way. And of course, the newer concepts of adoptable storage have alleviated problems in this regard.” — end quote.

Bottom line

Thanks to google the way that most apps now handle android secondary storage heavily depends on the Android version being used. Unfortunately at this time most phones will have a hard time working with the secondary storage, but some phones do. I have updated the file browser integration into my apps and have fixed the issue of secondary storage on some Android versions and not on others.

This whole debacle has not only cost me weeks of effort and research, it has negatively affected all apps with file system access and is the main reason that almost all apps only storing their data on the primary storage, which in most cases is much smaller than the external storage. At this tmie you can get a cheap microSD card with up to 512 GB. However what good is this in your phone if most apps can only use the built-in 16GB ?