If you're 100% sure that you don't need any back-end logic, and never, ever will, see Using Google Cloud Storage JSON api in android for direct Android <-> Google Cloud Storage operations.
Usually, in the course of a successful app's lifetime, some logic on the back-end is eventually required (e.g to deal with different versions of clients -- not all update in the same nanosecond:-), so it's normally more prudent and future-proof to have the front-end go to an App Engine back-end that can apply whatever logic is required besides providing access to Cloud Storage.
At version 0.1 the amount of logic required may be very small (though usually at least some kind of authentication) but if the application is successful likely new versions will be required and the back-end will be able to evolve to deal with that.
Then in a comment you ask:
As far as I have understood the appengine, if I need to store data in
NoSQL datastore, then I can make a backend with endpoint support which
will in turn consume my Restful API.
A more common arrangement is to have the back-end supply a restful API for the front-end to consume; and, that's what Cloud Endpoints can do for you (though you could design and implement that restful API in many other different ways, if you'd rather).
I mean, can I/should I consume the cloud storage rest API from within
my backend endpoint, which itself is used to call my own rest API?
One robust architecture is based on separation of concerns. Let the front-end running on Android concern itself essentially with the "human interface" part of your overall application -- presenting data clearly and usefully, interacting with the user.
The front-end can delegate just about every other concern to the back-end, including both storage and most aspects of app-specific logic concerned with what to store where, whether to allow access (of what kind -- read/write or read/only) to certain data depending on authentication of the user, and so on.
This delegation can take advantage of Cloud Endpoints, or, you could choose to design and implement it differently (e.g producing and consuming the app's REST API via different frameworks).
Why do I need backend logic to deal with different versions of
clients?
You'll need that, for example, if and when a new version of the client wants to store and retrieve more data than older versions did -- for example, in some future version you may decide it can be useful to add GPS location data, or optionally multiple photos or an audio snippet, etc, etc, which were not used in previous versions. (It's hard to be specific of course without any idea as to what your app is all about, but in general there's always something that you didn't do in early versions and want to add to some future one:-).
In such cases, the back-end needs to know what bits and pieces of data, exactly, to expect from the client, and conversely which ones to serve back to the client -- and those crucial aspects will then depend on the client's version; and without back-end logic to mediate, smooth seamless transition between old and new clients won't be feasible, particularly during the transitional period when some clients have upgraded to the newer version but others are still stuck on the old one.
