Yeah, if you are describing it accurately this is completely broken, to the point of useless.
The initial AES key is compromised by being in the app, anyone with the app has access to the AES key. If this is global, then it is well and truly screwed, if it is unique to each application, there may be a small sliver of hope.
The SHA-1 is completely replayable. You mention no salt, but even if there is a salt, the attacker can replay it against a legit client as a MitM and then respond validly to appear as the client to the server.
The server would then provide the attacker with the public key, in encrypted form, which isn't particularly useful to the attacker, but it is also the public key... it is supposed to be public. Having it private offers nothing. If the client was ever compromised (or any client if the AES key is global), then the AES key is leaked by the application and the public key is also available to the attacker.
Additionally, if the AES key is compromised, the attacker can send a public key of their choice since the client has no way to verify the RSA public key.
An AES key being generated on the client is a decent enough idea, but so far, there is nothing to prevent the attacker from generating their own AES key. Additionally, they could likely provide the client with their own public key so they can also fool the client.
Why is the data being encrypted with the RSA key? What is the point of the temporary AES key then? Is it really completely unused? Encrypting long data with RSA is generally considered less secure than using symmetric encryption since it is requires more work to process and may have other security implications, the norm is just to exchange a symmetric key and use that for data exchange.
In short, the system is completely useless.
It would actually be far more useful if they simply embedded the public key of the server in the application and used that to have the client generate an AES key and exchange that for session communication. It wouldn't validate anything about the client itself, but that could be done through passwords or other tokens after the session is initialized. At that point you are pretty close to just using a self signed HTTPS though, but it could be used as a custom implementation if HTTPS isn't an option for some reason (such as not being able to add a trusted root certificate on the client devices.)