重新打包的话，用户不一定更新应用，所以这个方案不太好
当然，最好是设计之初就将安卓应用请求的域名不定死，那么这样又该怎么解决？也就是能否下载一段代码覆盖本地的代码，这样是否有安全问题？
我们项目目前也遇到了这种情况，只不过我们在登录之前请求了一次API，获取域名，然后之后的所有接口都依赖于这个接口的返回值。
不懂运维，感觉可以试试CNAME。
nginx 反向代理。
location ^~/api/ {
proxy_set_header Host aa.com; # 新域名
proxy_pass http://aa.com/; # 新域名
}可以，你让写接口的人，在a域名发个请求到b域名，拿数据返回给你，哈哈，我想问一下，重新打包很麻烦吗？不懂移动开发
如果你已经有上线的应用出现这个情况。那么基本上只有一个解决方案：那就是让后端的开发人员辛苦一下，把发送到A点的请求都redirect去B点，并返回响应的数据。注意：这些数据的格式最好不要出现不必要的变化。否则，容错不够的话会出现Crash的情况。
当然应用本身也有解决这个问题的方法，但是需要事先已经在架构上做好这样的设计。比如iOS和Android都有热修复的一些实现技术。如果你的APP都已经有这样的架构，那么可以在server端放上开发好的补丁，让APP请求B点数据，APP自动把这些补丁下载并应用到APP本身。那么APP自动就可以请求B点数据了。
两种情况权衡一下的话，你会发现如果B点已经开发完毕。那么第一个方案是最省事，也是最快的。
既然之前就是使用的域名，可以后台处理。
1、服务端角度：让服务端的同学配置好nginx，分分钟的问题
2、App角度：域名的变更应该不会很频繁吧，个人觉得用推送的方式下发，然后app端保存；或者，准备一个借口用于获取域名的
这肯定要做成动态配置的，在App启动的时候，调用下服务器的接口，更新本地的api地址。
重新打包，打个包分分钟，只不过需要用户更新
如果A域名还有用的话做反向代理，301重定向都可以，如果A域名彻底不用的话只能重新打包。。。如果IP足够稳定也可以使用IP做接口地址
可以在启动app的时候请求一次后台数据。设置一个标签，如果为1则加载A地址，如果为0加载B地址。
看样子服务端解决起来更省力